mirrors
/
CC-Tweaked
mirror of https://github.com/SquidDev-CC/CC-Tweaked
1
0
Fork 0
Code Issues Releases Wiki Activity
CC-Tweaked/projects/common/src/main/java/dan200/computercraft/data/RecipeProvider.java

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

514 lines
23 KiB
Java
Raw Normal View History

License CC:T according to the REUSE specification (#1351) This adds SPDX license headers to all source code files, following the REUSE[1] specification. This does not include any asset files (such as generated JSON files, or textures). While REUSE does support doing so with ".license" files, for now we define these licences using the .reuse/dep5 file. [1]: https://reuse.software/
2023-03-15 21:52:13 +00:00
// SPDX-FileCopyrightText: 2020 The CC: Tweaked Developers
//
// SPDX-License-Identifier: MPL-2.0
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
package dan200.computercraft.data;
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
import com.google.gson.JsonObject;
Try to make recipe serialisers more reusable This attempts to reduce some duplication in recipe serialisation (and deserialisation) by moving the structure of a recipe (group, category, ingredients, result) into seprate types. - Add ShapedRecipeSpec and ShapelessRecipeSpec, which store the core properties of shaped and shapeless recipes. There's a couple of additional classes here for handling some of the other shared or complex logic. - These classes are now used by two new Custom{Shaped,Shapeless}Recipe classes, which are (mostly) equivalent to Minecraft's shaped/shapeless recipes, just with support for nbt in results. - All the other similar recipes now inherit from these base classes, which allows us to reuse a lot of this serialisation code. Alas, the total code size has still gone up - maybe there's too much abstraction here :). - Mostly unrelated, but fix the skull recipes using the wrong UUID format. This allows us to remove our mixin for nbt in recipes (as we just use our custom recipe now) and simplify serialisation a bit - hopefully making the switch to codecs a little easier.
2023-09-23 17:24:02 +00:00
import com.mojang.authlib.GameProfile;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import com.mojang.serialization.JsonOps;
Remove all references to the ComputerCraft class Another ugly commit, not thrilled about it: - Move all config values to a separate Config class. - Replace ComputerCraft.log with class-specific loggers. - Replace ComputerCraft.MOD_ID with ComputerCraftAPI.MOD_ID
2022-11-09 20:10:24 +00:00
import dan200.computercraft.api.ComputerCraftAPI;
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
import dan200.computercraft.api.pocket.PocketUpgradeDataProvider;
import dan200.computercraft.api.turtle.TurtleUpgradeDataProvider;
Allow upgrades to read/write upgrade data from ItemStacks (#1465)
2023-07-02 09:55:55 +00:00
import dan200.computercraft.api.upgrades.UpgradeData;
Flesh out our registry abstraction layer - Replace our usages of DeferredRegistry with a custom RegistrationHelper. This effectively behaves the same, just without any references to Forge code! - Replace any references to ForgeRegistries with a home-grown Registries class. This just fetches the underlying registry and proxies the method calls. - Change recipe serialisers and loot item conditions to be registered the same way as other entries. - Move any Forge specific registration code off to the main ComputerCraft class.
2022-11-06 18:27:21 +00:00
import dan200.computercraft.core.util.Colour;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import dan200.computercraft.data.recipe.ShapedSpecBuilder;
import dan200.computercraft.data.recipe.ShapelessSpecBuilder;
import dan200.computercraft.impl.RegistryHelper;
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
import dan200.computercraft.shared.ModRegistry;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import dan200.computercraft.shared.common.ClearColourRecipe;
import dan200.computercraft.shared.common.ColourableRecipe;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import dan200.computercraft.shared.computer.recipe.ComputerConvertRecipe;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import dan200.computercraft.shared.media.recipes.DiskRecipe;
import dan200.computercraft.shared.media.recipes.PrintoutRecipe;
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
import dan200.computercraft.shared.platform.PlatformHelper;
import dan200.computercraft.shared.platform.RecipeIngredients;
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
import dan200.computercraft.shared.pocket.items.PocketComputerItem;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import dan200.computercraft.shared.pocket.recipes.PocketComputerUpgradeRecipe;
import dan200.computercraft.shared.recipe.ImpostorShapedRecipe;
import dan200.computercraft.shared.recipe.ImpostorShapelessRecipe;
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
import dan200.computercraft.shared.turtle.items.TurtleItem;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import dan200.computercraft.shared.turtle.recipes.TurtleOverlayRecipe;
import dan200.computercraft.shared.turtle.recipes.TurtleUpgradeRecipe;
Turtle flags - Add a new recipe type for turtle overlays, and recipe generator support for this recipe. - Add trans and rainbow flags. - Exclude .license files from the generated jar. I'm not thrilled on the whole .license file system, but it's kinda the easiest way. - Regenerate data. Yes, this is 90% of the commit :D.
2023-03-31 17:14:44 +00:00
import dan200.computercraft.shared.util.ColourUtils;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import dan200.computercraft.shared.util.DataComponentUtil;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import net.minecraft.advancements.Criterion;
Update to Minecraft 1.17.1 - Remap everything to use MojMap class names too. This is what Forge uses, so \o/. This does NOT currently rename any classes to use suffix notation or BlockEntity. That will come in a later change. We do however rename references of "World" to "Level". - Move the test mod into a separate "cctest" source set. As Forge now works using Jigsaw we cannot have multiple mods defining the same package, which causes problems with our JUnit test classes. - Remove our custom test framework and replace it with vanilla's (this is no longer stripped from the jar). RIP kotlin coroutines. It's still worth using Kotlin here though, just for extension methods. - Other 1.17-related changes: - Use separate tile/block entity tick methods for server and client side, often avoiding ticking at all on the client. - Switch much of the monitor rendering code to use vanilla's built-in shader system. It's still an incredibly ugly hack, so not really expecting this to work with any rendering mods, but we'll cross that bridge when we come to it.
2021-08-03 20:46:53 +00:00
import net.minecraft.advancements.critereon.InventoryChangeTrigger;
import net.minecraft.advancements.critereon.ItemPredicate;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import net.minecraft.core.HolderLookup;
import net.minecraft.core.component.DataComponents;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import net.minecraft.core.registries.BuiltInRegistries;
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
import net.minecraft.core.registries.Registries;
import net.minecraft.data.PackOutput;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import net.minecraft.data.recipes.RecipeCategory;
import net.minecraft.data.recipes.RecipeOutput;
import net.minecraft.data.recipes.ShapedRecipeBuilder;
import net.minecraft.data.recipes.ShapelessRecipeBuilder;
Update to Minecraft 1.17.1 - Remap everything to use MojMap class names too. This is what Forge uses, so \o/. This does NOT currently rename any classes to use suffix notation or BlockEntity. That will come in a later change. We do however rename references of "World" to "Level". - Move the test mod into a separate "cctest" source set. As Forge now works using Jigsaw we cannot have multiple mods defining the same package, which causes problems with our JUnit test classes. - Remove our custom test framework and replace it with vanilla's (this is no longer stripped from the jar). RIP kotlin coroutines. It's still worth using Kotlin here though, just for extension methods. - Other 1.17-related changes: - Use separate tile/block entity tick methods for server and client side, often avoiding ticking at all on the client. - Switch much of the monitor rendering code to use vanilla's built-in shader system. It's still an incredibly ugly hack, so not really expecting this to work with any rendering mods, but we'll cross that bridge when we come to it.
2021-08-03 20:46:53 +00:00
import net.minecraft.resources.ResourceLocation;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import net.minecraft.tags.ItemTags;
Update to 1.18.2 Did not enjoy, would not recommend.
2022-03-03 09:17:18 +00:00
import net.minecraft.tags.TagKey;
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
import net.minecraft.util.GsonHelper;
Try to make recipe serialisers more reusable This attempts to reduce some duplication in recipe serialisation (and deserialisation) by moving the structure of a recipe (group, category, ingredients, result) into seprate types. - Add ShapedRecipeSpec and ShapelessRecipeSpec, which store the core properties of shaped and shapeless recipes. There's a couple of additional classes here for handling some of the other shared or complex logic. - These classes are now used by two new Custom{Shaped,Shapeless}Recipe classes, which are (mostly) equivalent to Minecraft's shaped/shapeless recipes, just with support for nbt in results. - All the other similar recipes now inherit from these base classes, which allows us to reuse a lot of this serialisation code. Alas, the total code size has still gone up - maybe there's too much abstraction here :). - Mostly unrelated, but fix the skull recipes using the wrong UUID format. This allows us to remove our mixin for nbt in recipes (as we just use our custom recipe now) and simplify serialisation a bit - hopefully making the switch to codecs a little easier.
2023-09-23 17:24:02 +00:00
import net.minecraft.world.item.*;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import net.minecraft.world.item.component.DyedItemColor;
import net.minecraft.world.item.component.ResolvableProfile;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import net.minecraft.world.item.crafting.CraftingBookCategory;
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
import net.minecraft.world.item.crafting.Ingredient;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import net.minecraft.world.item.crafting.Recipe;
Update to Minecraft 1.17.1 - Remap everything to use MojMap class names too. This is what Forge uses, so \o/. This does NOT currently rename any classes to use suffix notation or BlockEntity. That will come in a later change. We do however rename references of "World" to "Level". - Move the test mod into a separate "cctest" source set. As Forge now works using Jigsaw we cannot have multiple mods defining the same package, which causes problems with our JUnit test classes. - Remove our custom test framework and replace it with vanilla's (this is no longer stripped from the jar). RIP kotlin coroutines. It's still worth using Kotlin here though, just for extension methods. - Other 1.17-related changes: - Use separate tile/block entity tick methods for server and client side, often avoiding ticking at all on the client. - Switch much of the monitor rendering code to use vanilla's built-in shader system. It's still an incredibly ugly hack, so not really expecting this to work with any rendering mods, but we'll cross that bridge when we come to it.
2021-08-03 20:46:53 +00:00
import net.minecraft.world.level.ItemLike;
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
import net.minecraft.world.level.block.Blocks;
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
import java.util.List;
Try to make recipe serialisers more reusable This attempts to reduce some duplication in recipe serialisation (and deserialisation) by moving the structure of a recipe (group, category, ingredients, result) into seprate types. - Add ShapedRecipeSpec and ShapelessRecipeSpec, which store the core properties of shaped and shapeless recipes. There's a couple of additional classes here for handling some of the other shared or complex logic. - These classes are now used by two new Custom{Shaped,Shapeless}Recipe classes, which are (mostly) equivalent to Minecraft's shaped/shapeless recipes, just with support for nbt in results. - All the other similar recipes now inherit from these base classes, which allows us to reuse a lot of this serialisation code. Alas, the total code size has still gone up - maybe there's too much abstraction here :). - Mostly unrelated, but fix the skull recipes using the wrong UUID format. This allows us to remove our mixin for nbt in recipes (as we just use our custom recipe now) and simplify serialisation a bit - hopefully making the switch to codecs a little easier.
2023-09-23 17:24:02 +00:00
import java.util.UUID;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import java.util.concurrent.CompletableFuture;
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
import java.util.function.Consumer;
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
import static dan200.computercraft.api.ComputerCraftTags.Items.COMPUTER;
import static dan200.computercraft.api.ComputerCraftTags.Items.WIRED_MODEM;
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
final class RecipeProvider extends net.minecraft.data.recipes.RecipeProvider {
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
private final RecipeIngredients ingredients = PlatformHelper.get().getRecipeIngredients();
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
private final TurtleUpgradeDataProvider turtleUpgrades;
private final PocketUpgradeDataProvider pocketUpgrades;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
RecipeProvider(PackOutput output, CompletableFuture<HolderLookup.Provider> registries, TurtleUpgradeDataProvider turtleUpgrades, PocketUpgradeDataProvider pocketUpgrades) {
super(output, registries);
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
this.turtleUpgrades = turtleUpgrades;
this.pocketUpgrades = pocketUpgrades;
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
}
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
@Override
Update to 1.20.4
2024-01-31 20:55:14 +00:00
public void buildRecipes(RecipeOutput add) {
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
basicRecipes(add);
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
diskColours(add);
pocketUpgrades(add);
turtleUpgrades(add);
Turtle flags - Add a new recipe type for turtle overlays, and recipe generator support for this recipe. - Add trans and rainbow flags. - Exclude .license files from the generated jar. I'm not thrilled on the whole .license file system, but it's kinda the easiest way. - Regenerate data. Yes, this is 90% of the commit :D.
2023-03-31 17:14:44 +00:00
turtleOverlays(add);
Reformat everything - Switch to a fairly standard code format. This is largely based on IntelliJ defaults, with some minor tweaks applied via editor config. Should mean people don't need to import a config! - Use "var" everywhere instead of explicit types. Type inference is a joy, and I intend to use it to its fullest. - Start using switch expressions: we couldn't use them before because IntelliJ does silly things with our previous brace style, but now we have the luxury of them!
2022-11-03 23:43:14 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
addSpecial(add, new PrintoutRecipe(CraftingBookCategory.MISC));
addSpecial(add, new DiskRecipe(CraftingBookCategory.MISC));
addSpecial(add, new ColourableRecipe(CraftingBookCategory.MISC));
addSpecial(add, new ClearColourRecipe(CraftingBookCategory.MISC));
addSpecial(add, new TurtleUpgradeRecipe(CraftingBookCategory.MISC));
addSpecial(add, new PocketComputerUpgradeRecipe(CraftingBookCategory.MISC));
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
}
/**
* Register a crafting recipe for a disk of every dye colour.
*
Update to 1.20.4
2024-01-31 20:55:14 +00:00
* @param output The callback to add recipes.
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
*/
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private void diskColours(RecipeOutput output) {
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
for (var colour : Colour.VALUES) {
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapelessSpecBuilder
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.shapeless(RecipeCategory.REDSTONE, DataComponentUtil.createStack(ModRegistry.Items.DISK.get(), DataComponents.DYED_COLOR, new DyedItemColor(colour.getHex(), false)))
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.requires(ingredients.redstone())
.requires(Items.PAPER)
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.requires(DyeItem.byColor(ofColour(colour)))
.group("computercraft:disk")
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.unlockedBy("has_drive", inventoryChange(ModRegistry.Blocks.DISK_DRIVE.get()))
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.build(ImpostorShapelessRecipe::new)
.save(output, new ResourceLocation(ComputerCraftAPI.MOD_ID, "disk_" + (colour.ordinal() + 1)));
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
}
}
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
private static List<TurtleItem> turtleItems() {
return List.of(ModRegistry.Items.TURTLE_NORMAL.get(), ModRegistry.Items.TURTLE_ADVANCED.get());
}
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
/**
* Register a crafting recipe for each turtle upgrade.
*
* @param add The callback to add recipes.
*/
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private void turtleUpgrades(RecipeOutput add) {
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
for (var turtleItem : turtleItems()) {
Update to 1.20.4
2024-01-31 20:55:14 +00:00
var name = RegistryHelper.getKeyOrThrow(BuiltInRegistries.ITEM, turtleItem);
Reformat everything - Switch to a fairly standard code format. This is largely based on IntelliJ defaults, with some minor tweaks applied via editor config. Should mean people don't need to import a config! - Use "var" everywhere instead of explicit types. Type inference is a joy, and I intend to use it to its fullest. - Start using switch expressions: we couldn't use them before because IntelliJ does silly things with our previous brace style, but now we have the luxury of them!
2022-11-03 23:43:14 +00:00
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
for (var upgrade : turtleUpgrades.getGeneratedUpgrades()) {
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapedSpecBuilder
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.shaped(RecipeCategory.REDSTONE, DataComponentUtil.createStack(turtleItem, ModRegistry.DataComponents.RIGHT_TURTLE_UPGRADE.get(), UpgradeData.ofDefault(upgrade)))
Remove several usages of ComputerFamily While ComputerFamily is still useful, there's definitely some places where it adds an extra layer of indirection. This commit attempts to clean up some places where we no longer need it. - Remove ComputerFamily from AbstractComputerBlock. The only place this was needed is in TurtleBlock, and that can be replaced with normal Minecraft explosion resistence! - Pass in the fuel limit to the turtle block entity, rather than deriving it from current family. - The turtle BERs now derive their model from the turtle's item, rather than the turtle's family. - When creating upgrade/overlay recipes, use the item's name, rather than {pocket,turtle}_family. This means we can drop getFamily() from IComputerItem (it is still needed on to handle the UI). - We replace IComputerItem.withFamily with a method to change to a different item of the same type. ComputerUpgradeRecipe no longer takes a family, and instead just uses the result's item. - Computer blocks now use the normal Block.asItem() to find their corresponding item, rather than looking it up via family. The above means we can remove all the family-based XyzItem.create(...) methods, which have always felt a little ugly. We still need ComputerFamily for a couple of things: - Permission checks for command computers. - Checks for mouse/colour support in ServerComputer. - UI textures.
2023-12-20 14:16:56 +00:00
.group(name.toString())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("#T")
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.define('T', turtleItem)
Fix recipe book upgrade recipes - Flip turtle/pocket and upgrade item. - Correctly set NBT on pocket upgrade recipe output.
2021-10-11 11:17:45 +00:00
.define('#', upgrade.getCraftingItem().getItem())
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.unlockedBy("has_items", inventoryChange(turtleItem, upgrade.getCraftingItem().getItem()))
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.build(ImpostorShapedRecipe::new)
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(
Update to 1.20.4
2024-01-31 20:55:14 +00:00
add,
Remove several usages of ComputerFamily While ComputerFamily is still useful, there's definitely some places where it adds an extra layer of indirection. This commit attempts to clean up some places where we no longer need it. - Remove ComputerFamily from AbstractComputerBlock. The only place this was needed is in TurtleBlock, and that can be replaced with normal Minecraft explosion resistence! - Pass in the fuel limit to the turtle block entity, rather than deriving it from current family. - The turtle BERs now derive their model from the turtle's item, rather than the turtle's family. - When creating upgrade/overlay recipes, use the item's name, rather than {pocket,turtle}_family. This means we can drop getFamily() from IComputerItem (it is still needed on to handle the UI). - We replace IComputerItem.withFamily with a method to change to a different item of the same type. ComputerUpgradeRecipe no longer takes a family, and instead just uses the result's item. - Computer blocks now use the normal Block.asItem() to find their corresponding item, rather than looking it up via family. The above means we can remove all the family-based XyzItem.create(...) methods, which have always felt a little ugly. We still need ComputerFamily for a couple of things: - Permission checks for command computers. - Checks for mouse/colour support in ServerComputer. - UI textures.
2023-12-20 14:16:56 +00:00
name.withSuffix(String.format("/%s/%s", upgrade.getUpgradeID().getNamespace(), upgrade.getUpgradeID().getPath()))
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
);
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
}
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
}
}
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
private static List<PocketComputerItem> pocketComputerItems() {
return List.of(ModRegistry.Items.POCKET_COMPUTER_NORMAL.get(), ModRegistry.Items.POCKET_COMPUTER_ADVANCED.get());
}
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
/**
* Register a crafting recipe for each pocket upgrade.
*
* @param add The callback to add recipes.
*/
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private void pocketUpgrades(RecipeOutput add) {
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
for (var pocket : pocketComputerItems()) {
Update to 1.20.4
2024-01-31 20:55:14 +00:00
var name = RegistryHelper.getKeyOrThrow(BuiltInRegistries.ITEM, pocket).withPath(x -> x.replace("pocket_computer_", "pocket_"));
Reformat everything - Switch to a fairly standard code format. This is largely based on IntelliJ defaults, with some minor tweaks applied via editor config. Should mean people don't need to import a config! - Use "var" everywhere instead of explicit types. Type inference is a joy, and I intend to use it to its fullest. - Start using switch expressions: we couldn't use them before because IntelliJ does silly things with our previous brace style, but now we have the luxury of them!
2022-11-03 23:43:14 +00:00
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
for (var upgrade : pocketUpgrades.getGeneratedUpgrades()) {
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapedSpecBuilder
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.shaped(RecipeCategory.REDSTONE, DataComponentUtil.createStack(pocket, ModRegistry.DataComponents.POCKET_UPGRADE.get(), UpgradeData.ofDefault(upgrade)))
Remove several usages of ComputerFamily While ComputerFamily is still useful, there's definitely some places where it adds an extra layer of indirection. This commit attempts to clean up some places where we no longer need it. - Remove ComputerFamily from AbstractComputerBlock. The only place this was needed is in TurtleBlock, and that can be replaced with normal Minecraft explosion resistence! - Pass in the fuel limit to the turtle block entity, rather than deriving it from current family. - The turtle BERs now derive their model from the turtle's item, rather than the turtle's family. - When creating upgrade/overlay recipes, use the item's name, rather than {pocket,turtle}_family. This means we can drop getFamily() from IComputerItem (it is still needed on to handle the UI). - We replace IComputerItem.withFamily with a method to change to a different item of the same type. ComputerUpgradeRecipe no longer takes a family, and instead just uses the result's item. - Computer blocks now use the normal Block.asItem() to find their corresponding item, rather than looking it up via family. The above means we can remove all the family-based XyzItem.create(...) methods, which have always felt a little ugly. We still need ComputerFamily for a couple of things: - Permission checks for command computers. - Checks for mouse/colour support in ServerComputer. - UI textures.
2023-12-20 14:16:56 +00:00
.group(name.toString())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("#")
.pattern("P")
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.define('P', pocket)
Fix recipe book upgrade recipes - Flip turtle/pocket and upgrade item. - Correctly set NBT on pocket upgrade recipe output.
2021-10-11 11:17:45 +00:00
.define('#', upgrade.getCraftingItem().getItem())
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.unlockedBy("has_items", inventoryChange(pocket, upgrade.getCraftingItem().getItem()))
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.build(ImpostorShapedRecipe::new)
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(
Update to 1.20.4
2024-01-31 20:55:14 +00:00
add,
Remove several usages of ComputerFamily While ComputerFamily is still useful, there's definitely some places where it adds an extra layer of indirection. This commit attempts to clean up some places where we no longer need it. - Remove ComputerFamily from AbstractComputerBlock. The only place this was needed is in TurtleBlock, and that can be replaced with normal Minecraft explosion resistence! - Pass in the fuel limit to the turtle block entity, rather than deriving it from current family. - The turtle BERs now derive their model from the turtle's item, rather than the turtle's family. - When creating upgrade/overlay recipes, use the item's name, rather than {pocket,turtle}_family. This means we can drop getFamily() from IComputerItem (it is still needed on to handle the UI). - We replace IComputerItem.withFamily with a method to change to a different item of the same type. ComputerUpgradeRecipe no longer takes a family, and instead just uses the result's item. - Computer blocks now use the normal Block.asItem() to find their corresponding item, rather than looking it up via family. The above means we can remove all the family-based XyzItem.create(...) methods, which have always felt a little ugly. We still need ComputerFamily for a couple of things: - Permission checks for command computers. - Checks for mouse/colour support in ServerComputer. - UI textures.
2023-12-20 14:16:56 +00:00
name.withSuffix(String.format("/%s/%s", upgrade.getUpgradeID().getNamespace(), upgrade.getUpgradeID().getPath()))
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
);
Rewrite turtle upgrade registration to be more data driven (#967) The feature nobody asked for, but we're getting anyway. Old way to register a turtle/pocket computer upgrade: ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade"))); New way to register a turtle/pocket computer upgrade: First, define a serialiser for your turtle upgrade type: static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" ); public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE = SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) ); SERIALISERS.register(bus); // Call in your mod constructor. Now either create a JSON string or use a data generator to register your upgrades: class TurtleDataGenerator extends TurtleUpgradeDataProvider { @Override protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade ) simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade); } } See much better! In all seriousness, this does offer some benefits, namely that it's now possible to overwrite or create upgrades via datapacks. Actual changes: - Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions. - Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used to load upgrades from JSON files in datapacks, and then read/write them to network packets (much like recipe serialisers). - The upgrade registries now subscribe to datapack reload events. They find all JSON files in the data/$mod_id/computercraft/{turtle,pocket}_upgrades directories, parse them, and then register them as upgrades. Once datapacks have fully reloaded, these upgrades are then sent over the network to the client. - Add data generators for turtle and pocket computer upgrades, to make the creation of JSON files a bit easier. - Port all of CC:T's upgrades over to use the new system.
2021-11-26 23:36:02 +00:00
}
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
}
}
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private void turtleOverlays(RecipeOutput add) {
Turtle flags - Add a new recipe type for turtle overlays, and recipe generator support for this recipe. - Add trans and rainbow flags. - Exclude .license files from the generated jar. I'm not thrilled on the whole .license file system, but it's kinda the easiest way. - Regenerate data. Yes, this is 90% of the commit :D.
2023-03-31 17:14:44 +00:00
turtleOverlay(add, "turtle_trans_overlay", x -> x
.unlockedBy("has_dye", inventoryChange(itemPredicate(ingredients.dye())))
.requires(ColourUtils.getDyeTag(DyeColor.LIGHT_BLUE))
.requires(ColourUtils.getDyeTag(DyeColor.PINK))
.requires(ColourUtils.getDyeTag(DyeColor.WHITE))
.requires(Items.STICK)
);
turtleOverlay(add, "turtle_rainbow_overlay", x -> x
.unlockedBy("has_dye", inventoryChange(itemPredicate(ingredients.dye())))
.requires(ColourUtils.getDyeTag(DyeColor.RED))
.requires(ColourUtils.getDyeTag(DyeColor.ORANGE))
.requires(ColourUtils.getDyeTag(DyeColor.YELLOW))
.requires(ColourUtils.getDyeTag(DyeColor.GREEN))
.requires(ColourUtils.getDyeTag(DyeColor.BLUE))
.requires(ColourUtils.getDyeTag(DyeColor.PURPLE))
.requires(Items.STICK)
);
}
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private void turtleOverlay(RecipeOutput add, String overlay, Consumer<ShapelessSpecBuilder> build) {
Clean up turtle/pocket computer item creation - Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly a relic of the pre-1.13 code where we had multiple turtle items. I do like the theory of abstracting everything out behind an interface, but given there's only one concrete implementation, I'm not convinced it's worth it right now. - Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer calling the instance .create(...) method where we have the item available (for instance upgrade recipes). In the cases we don't (creating an item the first time round), we now move the static .create(...) method to the actual item class.
2023-06-04 10:24:04 +00:00
for (var turtleItem : turtleItems()) {
Update to 1.20.4
2024-01-31 20:55:14 +00:00
var name = RegistryHelper.getKeyOrThrow(BuiltInRegistries.ITEM, turtleItem);
Turtle flags - Add a new recipe type for turtle overlays, and recipe generator support for this recipe. - Add trans and rainbow flags. - Exclude .license files from the generated jar. I'm not thrilled on the whole .license file system, but it's kinda the easiest way. - Regenerate data. Yes, this is 90% of the commit :D.
2023-03-31 17:14:44 +00:00
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
var builder = ShapelessSpecBuilder.shapeless(RecipeCategory.REDSTONE, new ItemStack(turtleItem))
Remove several usages of ComputerFamily While ComputerFamily is still useful, there's definitely some places where it adds an extra layer of indirection. This commit attempts to clean up some places where we no longer need it. - Remove ComputerFamily from AbstractComputerBlock. The only place this was needed is in TurtleBlock, and that can be replaced with normal Minecraft explosion resistence! - Pass in the fuel limit to the turtle block entity, rather than deriving it from current family. - The turtle BERs now derive their model from the turtle's item, rather than the turtle's family. - When creating upgrade/overlay recipes, use the item's name, rather than {pocket,turtle}_family. This means we can drop getFamily() from IComputerItem (it is still needed on to handle the UI). - We replace IComputerItem.withFamily with a method to change to a different item of the same type. ComputerUpgradeRecipe no longer takes a family, and instead just uses the result's item. - Computer blocks now use the normal Block.asItem() to find their corresponding item, rather than looking it up via family. The above means we can remove all the family-based XyzItem.create(...) methods, which have always felt a little ugly. We still need ComputerFamily for a couple of things: - Permission checks for command computers. - Checks for mouse/colour support in ServerComputer. - UI textures.
2023-12-20 14:16:56 +00:00
.group(name.withSuffix("_overlay").toString())
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.unlockedBy("has_turtle", inventoryChange(turtleItem));
Turtle flags - Add a new recipe type for turtle overlays, and recipe generator support for this recipe. - Add trans and rainbow flags. - Exclude .license files from the generated jar. I'm not thrilled on the whole .license file system, but it's kinda the easiest way. - Regenerate data. Yes, this is 90% of the commit :D.
2023-03-31 17:14:44 +00:00
build.accept(builder);
builder
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.requires(turtleItem)
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.build(s -> new TurtleOverlayRecipe(s, new ResourceLocation(ComputerCraftAPI.MOD_ID, "block/" + overlay)))
.save(add, name.withSuffix("_overlays/" + overlay));
Turtle flags - Add a new recipe type for turtle overlays, and recipe generator support for this recipe. - Add trans and rainbow flags. - Exclude .license files from the generated jar. I'm not thrilled on the whole .license file system, but it's kinda the easiest way. - Regenerate data. Yes, this is 90% of the commit :D.
2023-03-31 17:14:44 +00:00
}
}
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private void basicRecipes(RecipeOutput add) {
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Items.CABLE.get(), 6)
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern(" # ")
.pattern("#R#")
.pattern(" # ")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('R', ingredients.redstone())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
.unlockedBy("has_modem", inventoryChange(WIRED_MODEM))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.COMPUTER_NORMAL.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#R#")
.pattern("#G#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('R', ingredients.redstone())
.define('G', ingredients.glassPane())
.unlockedBy("has_redstone", inventoryChange(itemPredicate(ingredients.redstone())))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.COMPUTER_ADVANCED.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#R#")
.pattern("#G#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
.define('R', ingredients.redstone())
.define('G', ingredients.glassPane())
.unlockedBy("has_components", inventoryChange(itemPredicate(ingredients.redstone()), itemPredicate(ingredients.goldIngot())))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapedSpecBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Items.COMPUTER_ADVANCED.get())
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
.pattern("###")
.pattern("#C#")
.pattern("# #")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
Fix computer upgrade recipes
2022-11-21 19:08:23 +00:00
.define('C', ModRegistry.Items.COMPUTER_NORMAL.get())
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.unlockedBy("has_components", inventoryChange(itemPredicate(ModRegistry.Items.COMPUTER_NORMAL.get()), itemPredicate(ingredients.goldIngot())))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.build(ComputerConvertRecipe::new)
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.save(add, new ResourceLocation(ComputerCraftAPI.MOD_ID, "computer_advanced_upgrade"));
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.COMPUTER_COMMAND.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#R#")
.pattern("#G#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
.define('R', Blocks.COMMAND_BLOCK)
.define('G', ingredients.glassPane())
.unlockedBy("has_components", inventoryChange(Blocks.COMMAND_BLOCK))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapedSpecBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.TURTLE_NORMAL.get())
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
.pattern("###")
.pattern("#C#")
.pattern("#I#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.ironIngot())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.define('C', ModRegistry.Items.COMPUTER_NORMAL.get())
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('I', ingredients.woodenChest())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.unlockedBy("has_computer", inventoryChange(ModRegistry.Items.COMPUTER_NORMAL.get()))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.build(ComputerConvertRecipe::new)
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.save(add);
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapedSpecBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.TURTLE_ADVANCED.get())
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
.pattern("###")
.pattern("#C#")
.pattern("#I#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.define('C', ModRegistry.Items.COMPUTER_ADVANCED.get())
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('I', ingredients.woodenChest())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.unlockedBy("has_computer", inventoryChange(ModRegistry.Items.COMPUTER_NORMAL.get()))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.build(ComputerConvertRecipe::new)
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.save(add);
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapedSpecBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.TURTLE_ADVANCED.get())
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
.pattern("###")
.pattern("#C#")
.pattern(" B ")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
Fix computer upgrade recipes
2022-11-21 19:08:23 +00:00
.define('C', ModRegistry.Items.TURTLE_NORMAL.get())
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('B', ingredients.goldBlock())
.unlockedBy("has_components", inventoryChange(itemPredicate(ModRegistry.Items.TURTLE_NORMAL.get()), itemPredicate(ingredients.goldIngot())))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.build(ComputerConvertRecipe::new)
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.save(add, new ResourceLocation(ComputerCraftAPI.MOD_ID, "turtle_advanced_upgrade"));
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.DISK_DRIVE.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#R#")
.pattern("#R#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('R', ingredients.redstone())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.MONITOR_NORMAL.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#G#")
.pattern("###")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('G', ingredients.glassPane())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.MONITOR_ADVANCED.get(), 4)
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#G#")
.pattern("###")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
.define('G', ingredients.glassPane())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Items.POCKET_COMPUTER_NORMAL.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#A#")
.pattern("#G#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('A', Items.GOLDEN_APPLE)
.define('G', ingredients.glassPane())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.unlockedBy("has_apple", inventoryChange(Items.GOLDEN_APPLE))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Items.POCKET_COMPUTER_ADVANCED.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#A#")
.pattern("#G#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
.define('A', Items.GOLDEN_APPLE)
.define('G', ingredients.glassPane())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.unlockedBy("has_apple", inventoryChange(Items.GOLDEN_APPLE))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapedSpecBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Items.POCKET_COMPUTER_ADVANCED.get())
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
.pattern("###")
.pattern("#C#")
.pattern("# #")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.define('C', ModRegistry.Items.POCKET_COMPUTER_NORMAL.get())
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.unlockedBy("has_components", inventoryChange(itemPredicate(ModRegistry.Items.POCKET_COMPUTER_NORMAL.get()), itemPredicate(ingredients.goldIngot())))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.build(ComputerConvertRecipe::new)
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.save(add, new ResourceLocation(ComputerCraftAPI.MOD_ID, "pocket_computer_advanced_upgrade"));
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.PRINTER.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#R#")
.pattern("#D#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('R', ingredients.redstone())
.define('D', ingredients.dye())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.SPEAKER.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#N#")
.pattern("#R#")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('N', Blocks.NOTE_BLOCK)
.define('R', ingredients.redstone())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Items.WIRED_MODEM.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#R#")
.pattern("###")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('R', ingredients.redstone())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.unlockedBy("has_cable", inventoryChange(ModRegistry.Items.CABLE.get()))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapelessRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shapeless(RecipeCategory.REDSTONE, ModRegistry.Blocks.WIRED_MODEM_FULL.get())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.requires(ModRegistry.Items.WIRED_MODEM.get())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_modem", inventoryChange(WIRED_MODEM))
Remove all references to the ComputerCraft class Another ugly commit, not thrilled about it: - Move all config values to a separate Config class. - Replace ComputerCraft.log with class-specific loggers. - Replace ComputerCraft.MOD_ID with ComputerCraftAPI.MOD_ID
2022-11-09 20:10:24 +00:00
.save(add, new ResourceLocation(ComputerCraftAPI.MOD_ID, "wired_modem_full_from"));
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapelessRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shapeless(RecipeCategory.REDSTONE, ModRegistry.Items.WIRED_MODEM.get())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.requires(ModRegistry.Blocks.WIRED_MODEM_FULL.get())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_modem", inventoryChange(WIRED_MODEM))
Remove all references to the ComputerCraft class Another ugly commit, not thrilled about it: - Move all config values to a separate Config class. - Replace ComputerCraft.log with class-specific loggers. - Replace ComputerCraft.MOD_ID with ComputerCraftAPI.MOD_ID
2022-11-09 20:10:24 +00:00
.save(add, new ResourceLocation(ComputerCraftAPI.MOD_ID, "wired_modem_full_to"));
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.WIRELESS_MODEM_NORMAL.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#E#")
.pattern("###")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.stone())
.define('E', ingredients.enderPearl())
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
ShapedRecipeBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shaped(RecipeCategory.REDSTONE, ModRegistry.Blocks.WIRELESS_MODEM_ADVANCED.get())
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.pattern("###")
.pattern("#E#")
.pattern("###")
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.define('#', ingredients.goldIngot())
.define('E', Items.ENDER_EYE)
Make turtle breaking a little more data driven - Allow any tool to break an "instabreak" block (saplings, plants, TNT). Oddly this doesn't include bamboo or bamboo sapings (they're marked as instabreak, only to have their strength overridden again!), so we also provide a tag for additional blocks to allow. - Hoes and shovels now allow breaking any block for which this tool is effective. - Use block tags to drive any other block breaking capabilities. For instance, hoes can break pumpkins and cactuses despite not being effective. This should get a little nicer in 1.17, as we can just use block tags for everything.
2021-10-27 18:16:32 +00:00
.unlockedBy("has_computer", inventoryChange(COMPUTER))
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.unlockedBy("has_wireless", inventoryChange(ModRegistry.Blocks.WIRELESS_MODEM_NORMAL.get()))
Switch to Mojang mappings ForgeGradle (probably sensibly) yells at me about doing this. However: - There's a reasonable number of mods doing this, which establishes some optimistic precedent. - The licence update in Aug 2020 now allows you to use them for "development purposes". I guess source code counts?? - I'm fairly sure this is also compatible with the CCPL - there's an exception for Minecraft code. The main motivation for this is to make the Fabric port a little easier. Hopefully folks (maybe me in the future, we'll see) will no longer have to deal with mapping hell when merging - only mod loader hell.
2021-01-09 19:22:58 +00:00
.save(add);
Use data generators in a few more places As always, a massive diff which is largely just moving files between projects. This does fix a couple of issues with advancements, but otherwise should behave the same. Speaking of which, should probably go and test some of these recipes...
2021-08-21 14:50:01 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapelessSpecBuilder
.shapeless(RecipeCategory.DECORATIONS, playerHead("Cloudhunter", "6d074736-b1e9-4378-a99b-bd8777821c9c"))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.requires(ItemTags.SKULLS)
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.requires(ModRegistry.Items.MONITOR_NORMAL.get())
.unlockedBy("has_monitor", inventoryChange(ModRegistry.Items.MONITOR_NORMAL.get()))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.build()
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.save(add, new ResourceLocation(ComputerCraftAPI.MOD_ID, "skull_cloudy"));
Use data generators in a few more places As always, a massive diff which is largely just moving files between projects. This does fix a couple of issues with advancements, but otherwise should behave the same. Speaking of which, should probably go and test some of these recipes...
2021-08-21 14:50:01 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapelessSpecBuilder
.shapeless(RecipeCategory.DECORATIONS, playerHead("dan200", "f3c8d69b-0776-4512-8434-d1b2165909eb"))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.requires(ItemTags.SKULLS)
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.requires(ModRegistry.Items.COMPUTER_ADVANCED.get())
.unlockedBy("has_computer", inventoryChange(ModRegistry.Items.COMPUTER_ADVANCED.get()))
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
.build()
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.save(add, new ResourceLocation(ComputerCraftAPI.MOD_ID, "skull_dan200"));
Use data generators in a few more places As always, a massive diff which is largely just moving files between projects. This does fix a couple of issues with advancements, but otherwise should behave the same. Speaking of which, should probably go and test some of these recipes...
2021-08-21 14:50:01 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapelessSpecBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shapeless(RecipeCategory.REDSTONE, ModRegistry.Items.PRINTED_PAGES.get())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.requires(ModRegistry.Items.PRINTED_PAGE.get(), 2)
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.requires(ingredients.string())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.unlockedBy("has_printer", inventoryChange(ModRegistry.Blocks.PRINTER.get()))
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.build(ImpostorShapelessRecipe::new)
.save(add);
Use data generators in a few more places As always, a massive diff which is largely just moving files between projects. This does fix a couple of issues with advancements, but otherwise should behave the same. Speaking of which, should probably go and test some of these recipes...
2021-08-21 14:50:01 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
ShapelessSpecBuilder
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
.shapeless(RecipeCategory.REDSTONE, ModRegistry.Items.PRINTED_BOOK.get())
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.requires(ingredients.leather())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.requires(ModRegistry.Items.PRINTED_PAGE.get(), 1)
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
.requires(ingredients.string())
Rename Registry to ModRegistry Avoids the conflict with Minecraft's built-in registry class
2022-11-06 17:14:53 +00:00
.unlockedBy("has_printer", inventoryChange(ModRegistry.Blocks.PRINTER.get()))
Update to 1.20.4
2024-01-31 20:55:14 +00:00
.build(ImpostorShapelessRecipe::new)
.save(add);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
}
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
private static DyeColor ofColour(Colour colour) {
return DyeColor.byId(15 - colour.ordinal());
}
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private static Criterion<InventoryChangeTrigger.TriggerInstance> inventoryChange(TagKey<Item> stack) {
Merge branch 'mc-1.16.x' into mc-1.18.x I dare say there's going to be some bugs with this. I was as careful as I could be, but yikes it was nasty.
2022-10-25 21:36:21 +00:00
return InventoryChangeTrigger.TriggerInstance.hasItems(itemPredicate(stack));
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
}
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private static Criterion<InventoryChangeTrigger.TriggerInstance> inventoryChange(ItemLike... stack) {
Update to Minecraft 1.17.1 - Remap everything to use MojMap class names too. This is what Forge uses, so \o/. This does NOT currently rename any classes to use suffix notation or BlockEntity. That will come in a later change. We do however rename references of "World" to "Level". - Move the test mod into a separate "cctest" source set. As Forge now works using Jigsaw we cannot have multiple mods defining the same package, which causes problems with our JUnit test classes. - Remove our custom test framework and replace it with vanilla's (this is no longer stripped from the jar). RIP kotlin coroutines. It's still worth using Kotlin here though, just for extension methods. - Other 1.17-related changes: - Use separate tile/block entity tick methods for server and client side, often avoiding ticking at all on the client. - Switch much of the monitor rendering code to use vanilla's built-in shader system. It's still an incredibly ugly hack, so not really expecting this to work with any rendering mods, but we'll cross that bridge when we come to it.
2021-08-03 20:46:53 +00:00
return InventoryChangeTrigger.TriggerInstance.hasItems(stack);
Port most recipes to use generators Closes #354
2020-02-08 23:26:05 +00:00
}
Use data generators in a few more places As always, a massive diff which is largely just moving files between projects. This does fix a couple of issues with advancements, but otherwise should behave the same. Speaking of which, should probably go and test some of these recipes...
2021-08-21 14:50:01 +00:00
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private static Criterion<InventoryChangeTrigger.TriggerInstance> inventoryChange(ItemPredicate... items) {
Merge branch 'mc-1.16.x' into mc-1.18.x I dare say there's going to be some bugs with this. I was as careful as I could be, but yikes it was nasty.
2022-10-25 21:36:21 +00:00
return InventoryChangeTrigger.TriggerInstance.hasItems(items);
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
}
Merge branch 'mc-1.16.x' into mc-1.18.x I dare say there's going to be some bugs with this. I was as careful as I could be, but yikes it was nasty.
2022-10-25 21:36:21 +00:00
private static ItemPredicate itemPredicate(ItemLike item) {
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
return ItemPredicate.Builder.item().of(item).build();
}
Merge branch 'mc-1.16.x' into mc-1.18.x I dare say there's going to be some bugs with this. I was as careful as I could be, but yikes it was nasty.
2022-10-25 21:36:21 +00:00
private static ItemPredicate itemPredicate(TagKey<Item> item) {
Some datagen improvements - Convert remaining recipes over to datagen. - Switch loot tables to use vanilla's loot table generator. It's honestly not too different, just the earlier system confused me too much :). Alas, a positive diff because the JSON is so verbose. I've got a really nice patch which makes the JSON more compact, but alas the Mixin doesn't apply on 1.16 :(.
2022-10-22 09:48:30 +00:00
return ItemPredicate.Builder.item().of(item).build();
}
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
private static ItemPredicate itemPredicate(Ingredient ingredient) {
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
var json = Ingredient.CODEC_NONEMPTY.encodeStart(JsonOps.INSTANCE, ingredient).getOrThrow();
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
if (!(json instanceof JsonObject object)) throw new IllegalStateException("Unknown ingredient " + json);
if (object.has("item")) {
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
var item = ItemStack.SIMPLE_ITEM_CODEC.parse(JsonOps.INSTANCE, object).getOrThrow();
Update to 1.20.4
2024-01-31 20:55:14 +00:00
return itemPredicate(item.getItem());
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
} else if (object.has("tag")) {
Update to Minecraft 1.19.3 Lots of minor changes, but nothing too nasty - just tedious. Known bugs/issues: - REI and JEI haven't been updated at the time of writing, so our usage of their APIs may be incompatible. - Crash when opening the config UI in Fabric, as forgeconfigapi-port hasn't been updated yet. Will hold off on doing a release until those mods have updated.
2022-12-08 19:45:02 +00:00
return itemPredicate(TagKey.create(Registries.ITEM, new ResourceLocation(GsonHelper.getAsString(object, "tag"))));
Abstract our our use of Forge's tags
2022-11-09 10:59:05 +00:00
} else {
throw new IllegalArgumentException("Unknown ingredient " + json);
}
}
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private static ItemStack playerHead(String name, String uuid) {
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
return DataComponentUtil.createStack(Items.PLAYER_HEAD, DataComponents.PROFILE, new ResolvableProfile(new GameProfile(UUID.fromString(uuid), name)));
Use data generators in a few more places As always, a massive diff which is largely just moving files between projects. This does fix a couple of issues with advancements, but otherwise should behave the same. Speaking of which, should probably go and test some of these recipes...
2021-08-21 14:50:01 +00:00
}
Update to 1.20.4
2024-01-31 20:55:14 +00:00
private static void addSpecial(RecipeOutput add, Recipe<?> recipe) {
add.accept(RegistryHelper.getKeyOrThrow(BuiltInRegistries.RECIPE_SERIALIZER, recipe.getSerializer()), recipe, null);
Use data generators in a few more places As always, a massive diff which is largely just moving files between projects. This does fix a couple of issues with advancements, but otherwise should behave the same. Speaking of which, should probably go and test some of these recipes...
2021-08-21 14:50:01 +00:00
}
Switch generation of resources over to data generators See #354 - Remove Lua script to generate recipes/advancements for coloured disks, turtle upgrades and pocket upgrades. Replacing them with Lua ones. - Generate most block drops via the data generator system. Aside from cables, they all follow one of two templates.
2020-01-29 16:41:26 +00:00
}