Choonster

ItemStack#getTooltip checks for its existence using the type ID 99, which is "any numeric". This means you can use any numeric data type for the tag, including integer and short.

There's a JAR and EXE version of the installer available for every version of Forge, including the versions for Minecraft 1.12.x.

It looks like you create your recipes before you create and store the filled bucket ItemStack, so the field hasn't yet been populated when they reference it. Where and when do you create your recipes? It should be done in RegistryEvent.Register<IRecipe>.

You can hide the attribute modifiers from the tooltip completely by setting the "HideFlags" key of the ItemStack's compound tag to a number with bit 2 set to 1 (e.g. 2). You can also subscribe to ItemTooltipEvent and modify the list of tooltip lines as you want.

You need to register an implementation of IBlockColor for your Block to recolour the greyscale grass texture when the model is rendered. Do this by calling BlockColors#registerBlockColorHandler in init from a client-only class. You can get the BlockColors instance using Minecraft#getBlockColors. Look the BlockColors class for the vanilla IBlockColor implementations.

Override Item#getAttributeModifiers, the ItemStack-sensitive version of Item#getItemAttributeModifiers. It has an ItemStack argument that you can access the NBT of.

Create a directory for each version, then create a launcher profile for each version (in the Launch options tab) with its game directory set to the directory you created.

You need to implement IRecipe#getCraftingResult to iterate through the InventoryCrafting and find the input ItemStack(s) that will determine the output NBT, then create and return the output ItemStack with the appropriate NBT. As Draco said, I do this for item damage in the ShapedArmourUpgradeRecipe class.

The ForgeModContainer#universalBucket field was null when you called FluidUtil.getFilledBucket, this is because it's not populated until RegistryEvent.Register<Item> (which is fired between preInit and init). You should create the bucket ItemStack during RegistryEvent.Register<IRecipe>, or ideally use a JSON recipe instead. I have an IIngredientFactory implementation that produces a filled universal bucket here; I use it in this constant, which I use in this recipe.

If you set a breakpoint in the method, is it called when you equip/unequip the tool? By calling super.getItemAttributeModifiers, you're creating a Multimap that already has AttributeModifiers with the ATTACK_DAMAGE_MODIFIER/ATTACK_SPEED_MODIFIER UUIDs. You then add your own AttributeModifiers with these UUIDs, which could be the cause of your issue. Try creating an empty Multimap instead. That code is from 1.8, before dual-wielding was added along with slot-specific AttributeModifiers and the attack speed attribute. You can see the 1.12.2 version of that code here.

I try to keep TestMod3 up to date with the latest Forge/Minecraft changes, so you can reference it to see how to adapt to recent changes or how to implement various features. You can also search this forum to see if anyone has asked about the topic before.

Create an instance of an anonymous class that extends StateMapperBase and implements StateMapperBase#getModelResourceLocation to return a dummy ModelResourceLocation (e.g. new ModelResourceLocation("minecraft:air")). You can then use StateMapperBase#getPropertyString to get a property string to use as the variant of a ModelResourceLocation. You can see how I do this in my mod here and here.

That's the path of a file on your computer, which we can't access. Follow the directions here to upload the FML log to Gist.

Make sure you installed it in the right directory (i.e. the mods directory of the launcher profile's game directory). Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

Blocks (and other registry entries) should be registered in the appropriate registry event (i.e. RegistryEvent.Register<Block>). You can control when your Blocks are registered in relation to the other mod using the EventPriority property of the @SubscribeEvent annotation.

I don't think the 256 limit exists at all in modern versions. It looks like EntitySpawnMessage (the packet sent by FML to spawn mod entities) sends the entity type ID as a 32-bit integer, so the limit is 232 entities per mod.

You can register an IStateMapper with ModelLoader.setCustomStateMapper in ModelRegistryEvent to change how each state is mapped to a blockstates file variant. To ignore one or more properties, create a StateMap.Builder, call StateMap.Builder#ignore with the properties you want to ignore, then call StateMap.Builder#build to create the IStateMapper. You can also use Forge's blockstates format to specify how each property value affects the model instead of specifying the model for each combination of property values.

The vanilla ItemPredicate class (used by the inventory_changed trigger) supports NBT, as documented on the wiki. You can also register your own ItemPredicate implementations, as I explain in this thread.

You'll need your own recipe class and factory for this. In the factory, read the ingredients, shape (if it's shaped) and output ore name and create the recipe. In the factory or recipe constructor, use OreDictionary.getOres(String) to get the list of items for that name and store it in a field of the recipe. Implement IRecipe#getRecipeOutput and IRecipe#getCraftingResult to return either the first item in the item list if there is one or ItemStack.EMPTY if it's empty. You might want to cache this in case the order of the list changes (though this shouldn't happen unless a mod messes with the Ore Dictionary internals).

This has been fixed in Forge 1.12.2-14.23.0.2490.

This happens because IngredientNBT#apply uses ItemStack.areItemStacksEqualUsingNBTShareTag to check if the ItemStack argument matches the ingredient's ItemStack, but this also checks that the two ItemStacks have the same stack size. This prevents the ingredient from matching when there's a stack of two ore more of the ingredient's item in the crafting grid. I've reported this on GitHub here.

1.7.10 is no longer supported on this forum. Update if you want help.

Entities should only be spawned on the logical server (i.e. when World#isRemote is false), which will automatically notify all clients in the area that the entity has spawned. Spawning entities on both sides will create a ghost entity.

ItemBlock always places the IBlockState corresponding to block metadata 0 because it doesn't override Item#getMetadata(int). You need to use a class that extends ItemBlock and overrides this to return the appropriate block metadata for the given item metadata, e.g. ItemColored, ItemMultiTexture or ItemCloth. ItemMultiTexture and ItemColored are general-purpose classes for blocks with subtypes, ItemCloth is specialised for blocks that use their metadata to store a dye colour.

It's a class added by my mod to allow the use of lambdas as ItemMeshDefinitions. I'm pretty sure the ForgeGradle reobfuscation bug that prevented that was fixed a while ago, so it's probably not needed anymore.