Choonster

Fluid textures go in src/main/resources/assets/<modid>/textures/<path>, where <modid> is your mod ID and <path> is the path component of the texture ResourceLocation. The UniversalBucket instance is stored in the ForgeModContainer#universalBucket field. Use ForgeModContainer.getInstance to get the ForgeModContainer instance. In 1.11.2, use UniversalBucket.getFilledBucket to get an ItemStack of the UniversalBucket filled with the specified Fluid. In 1.12+, this has been deprecated in favour of FluidUtil.getFilledBucket. Keep in mind that vanilla recipes don't support ingredients with NBT in 1.11.2, you'll need to create your own recipe classes (you'll probably want to extend an existing recipe class). In 1.12+, use a minecraft:item_nbt ingredient in a JSON recipe to create an NBT-sensitive ingredient. Edit: Fluid textures go in src/main/resources/assets/<modid>/textures/<path>, not src/main/resources/assets/<modid>/textures/blocks/<path>.

Forge doesn't allow you to use checkboxes or radio buttons by default, it uses buttons that cycle between the valid values when clicked instead. A boolean field will be converted to a boolean property and use a button that cycles between true and false in the config GUI. This is equivalent to a checkbox. An enum field will be converted to a string property that only accepts the enum's values and use a button that cycles between these values in the config GUI. This is equivalent to a set of radio buttons. What would you want a non-radio button for?

If you mean the tiled dirt background, that's assets/minecraft/textures/gui/options_background.png (Gui.OPTIONS_BACKGROUND).

I'm not too sure what the problem is, then. Try setting a breakpoint in ItemSlab#onItemUse, clicking a top slab while holding a slab and stepping through the code to see why it's not combing the slabs. Side note: ModelLoader is a client-only class, referencing it in common code will crash the dedicated server. Model registration must be handled in a dedicated, client-only class. Registration of Blocks, Items and other IForgeRegistryEntry implementations should be done in the corresponding registry events. Registration of models should be done in ModelRegistryEvent. Pass Side.CLIENT to the @Mod.EventBusSubscriber annotation to prevent the model registration class being loaded on the dedicated server.

What class are you using for the Item form of the slab? Vanilla uses ItemSlab, which handles combining single slabs into double slabs.

What you've created is an item predicate, not a criterion trigger. You need to use an existing criterion trigger like inventory_changed but use your custom item predicate instead of the vanilla one. As I said before, each object in the items array for the inventory_changed criterion is an item predicate. You need to set the type element of an item predicate object to the registry name of your custom item predicate.

RegistryEvent.Register is only for types that are in a Forge registry (i.e. types that implement IForgeRegistryEntry). There's no IWorldGenerator registry (IWorldGenerator doesn't extend IForgeRegistryEntry), so IWorldGenerators should still be registered in preInit/init. Recipe files in your mod's assets/<modid>/recipes directory are automatically loaded and registered by Forge. IRecipeFactory, IIngredientFactory and IConditionFactory classes should be specified in assets/<modid>/recipes/_factories.json rather than being registered in code. If you do register recipes in code (which you should avoid doing where possible), do it in RegistryEvent.Register<IRecipe>.

You need to build your mod with the build Gradle task, which reobfuscates your code to SRG names after compiling it. These are the names used by Minecraft outside of the development environment.

It needs a Function<JsonObject, ItemPredicate>, i.e. a function that takes a JsonObject and deserialises it into an ItemPredicate. You can implement this with a lambda, method reference (e.g. a constructor method reference) or an anonymous class. Look at the static initialiser block in ItemPredicates and the OredictItemPredicate constructor it references for an example of this.

I don't know the answer to that myself. Have you tried looking at the difference between AbstractHorse in 1.12 and EntityHorse in 1.10.2 to see how the vertical parameter has changed the motion calculations?

Highlight the text and click the Link button in the editor.

I answered this in your other thread 45 minutes ago.

EntityLivingBase#moveEntityWithHeading was replaced by EntityLivingBase#travel.

You're looking at 1.12 (the current recommended version), you need to go to the 1.12.1 page.

The ItemPredicates class was added in commit ee449e4 (version 1.12.1-14.22.0.2452). Make sure you're using the latest version of Forge.

Item predicates are used by advancement criteria like inventory_changed to determine whether or not the item matches the requirements. The inventory_changed criterion will be met when all of the specified item predicates match the item in any slot of the player's inventory (i.e. the player has every required item). The vanilla JSON format is documented on the wiki. For the inventory_changed criterion, each object in the items array is an item predicate. If you set the type element of an item predicate to a string, Forge will use the custom ItemPredicate factory that was registered with that name (via ItemPredicates.register) instead of creating a vanilla ItemPredicate instance.

Was there one part in particular that you didn't understand?

You should be able to extend ItemPredicate, override ItemPredicate#test and then register it with ItemPredicates.register. You can then use this anywhere an item predicate is expected (e.g. in the inventory_changed trigger).

assets/minecraft/recipes in the forgeSrc-<forgeVersion>.jar referenced library. I don't fully understand what you're asking here. One JSON file is one recipe. You can have any number of recipes that output the same item. No, recipes and items are in completely separate registries; you can name your recipe whatever you want. Minecraft uses the registry name of the output item for most of its recipes, it only uses a longer name when there are multiple recipes for the same item.

Which version of Minecraft are you using? In 1.11+, ItemStacks can no longer be null; the default value is now the empty ItemStack (ItemStack#isEmpty). The ItemStack.EMPTY field contains an ItemStack that's always empty.

You can add your own recipe and ingredient types to the JSON system, I explain this here.

It looks like FML wasn't launched properly, so FMLSanityChecker.fmlLocation was null. How did you set up your workspace and run the game? If you follow these instructions, the workspace should be set up properly and your IDE run configurations should use GradleStart and GradleStartServer, which ensure that FML is launched properly.

Recipes are in a Forge registry, so use the corresponding registry event to register them. Ideally, recipes should be added through the JSON system where possible rather than being added in code.

I'm not sure what's going on in your workspace. Try setting some breakpoints and stepping through ForgeHooks.loadAdvancements and AdvancementList#loadAdvancements in the debugger to see what's happening with your mod's advancements.

These are the errors I get when both advancements are missing the description element: