Choonster

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.

You'll need to read this variable from the crafting player (ForgeHooks.getCraftingPlayer) in the appropriate methods to determine the return value. You can either hardcode the variable, value and result or allow them to be specified via the JSON recipe file (possibly via the existing recipe conditions system, like I do in the class Draco18s linked). For a dynamic input item, you'll need to create your own Ingredient implementation and override Ingredient#apply to check the variable and return true or false depending on its value and the ItemStack argument. For a dynamic output item, you'll need to create your own IRecipe implementation (probably extending an existing one like ShapedOreRecipe/ShapelessOreRecipe) and implement IRecipe#getCraftingResult to check the variable and return the appropriate item. For a dynamically unlocked recipe, you'll need to create your own IRecipe implementation and implement IRecipe#matches to check the variable and return false if it's not the right value. That class allows for load-time conditions to enable/disable an Ingredient, which isn't quite what the OP wants.

For vanilla liquid blocks (which extend BlockLiquid), use BlockLiquid.getFlowingBlock and BlockLiquid.getStaticBlock to get the flowing and static Blocks for the specified Material. For modded fluid blocks (which usually implement IFluidBlock and extend BlockFluidBase), there's only one Block.

You'd have to make your own Item like the spawn egg that only spawns one entity type rather than whatever's specified in the NBT. I'd recommend reworking your code to use an ItemStack rather than just an Item.

The Item is just "Spawn Egg". If you want "Spawn Egg of Mini Zombie", you need an ItemStack.

@Mod.EventBusSubscriber registers the Class with the event bus, so only static @SubscribeEvent methods will be called. Your RegistryEvent.Register handlers in CommonProxy and ClientProxy are non-static, so they will never be called. There's no need to handle Block/Item registration in your proxies, do it in common classes (e.g. DMBlocks/DMItems). There's no reason to have a common proxy class, since proxies are for sided code. Common code belongs in your @Mod class or other common classes. Always annotate override methods with @Override so you get a compilation error if they don't actually override/implement a super method.

An Item instance only represents an item type, in this case the spawn egg. To store any more data (e.g. the entity spawned by the egg), you need the metadata/NBT of an ItemStack. You create an ItemStack with the NBT data required to spawn a "thewizardmod.MiniZombie" entity but then immediately discard it by returning the Item from the method rather than the ItemStack. Which version of Minecraft are you using? If you're using 1.9-1.11.2, ItemMonsterPlacer.applyEntityIdToItemStack is a client-only method that can't be used from common code. If you're using 1.11+, "thewizardmod.MiniZombie" is in the wrong format for a mod entity's registry name; it's a ResourceLocation so it should be lowercase and in the format "modid:entity_name".

The Forge documentation is community maintained and so far nobody has suggested or written any documentation on reflection. If you create an issue or PR in the documentation repository, this may be added. You're still only checking the MCP name, you need to supply both the MCP and SRG names for reflection to work inside and outside of the development environment.

You need to use the forge:fluid model. Use Forge's blockstates format to set the "fluid" custom property to the name of your Fluid. I use this blockstates file to define the models for my mod's fluid Blocks/ItemBlocks and these methods to register them.