Choonster

Static textures need to be square (i.e. equal width and height). Animated textures need to have a height equal to N times their width (where N is the number of frames). Animated textures require an mcmeta file with the same name as the texture (e.g. liquidessence_still.png.mcmeta) that specifies the animation data. See the wiki for the full format or the vanilla liquid mcmeta files for examples.

thin_block doesn't specify any elements (it only specifies some display transformations) and neither does your model, so nothing is rendered. If you look at the models that extend thin_block (e.g. carpet, daylight_detector), you'll see that they specify an element themselves.

I answered this in the OP's Minecraft Forum thread.

There should be an error in the log telling you why the recipe failed to load. I suspect it's because you didn't include the minecraft domain in the recipe type, so Forge used your mod ID as the domain and couldn't find any recipe factory with that name.

My previous post was incorrect, fluid textures actually go in assets/<modid>/textures/<path>. I forgot that I automatically add a prefix to my fluid textures so that the textures can go in the assets/<modid>/textures/blocks directory. new ResourceLocation(Magic.MOD_ID, "liquidessence.flow") is expanded to assets/<modid>/textures/liquidessence.flow.png. new ResourceLocation(Magic.MOD_ID, "fluids/liquidessence_still") is expanded to assets/<modid>/textures/fluids/liquidessence_still.png.

The player's inventory is stored in the EntityPlayer#inventory field, which is an instance of InventoryPlayer (an implementation of vanilla's IInventory interface). Forge patches EntityPlayer to add the EntityPlayer#getCapability method, which exposes various IItemHandler wrappers of the InventoryPlayer (main, equipment or joined depending on the EnumFacing). These don't store the inventory contents themselves, they simply provide access to the underlying InventoryPlayer through the IItemHandler interface. You can use a SlotItemHandler with one of these IItemHandler wrappers instead of a regular Slot with the InventoryPlayer to achieve the same result (access a player inventory slot in a GUI).

It's important to distinguish between physical sides and logical sides. Proxies handle physical sides, but they don't handle logical sides. Client-only classes like GUIs, models and renderers can only be accessed on the physical client, but sending messages to players should happen on the logical server (not just the physical server). Forge's documentation explains this in more detail here. The common type of your proxies (the type of the @SidedProxy field) should be an interface rather than a class. There's no need for a common proxy class because proxies are only for sided code; common code belongs in your @Mod class and other common classes.

EntityPlayer already provides CapabilityItemHandler.ITEM_HANDLER_CAPABILITY itself, so it never delegates this to the attached ICapabilityProviders. You need to create your own interface that extends IItemHandler, register a capability for it and provide that from AbilityProvider instead. AbilityProvider.handler is a static field, which means it's shared between all instances of AbilityProvider (and thus all instances of EntityPlayer you attach it to). It needs to be an instance field instead. Your IDE should warn you about accessing a static field through this.

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?