Choonster

Create the ItemStack , call ItemStack#setTagCompound then pass the ItemStack to GameRegistry.addRecipe .

Please post the whole log like I asked you to. It looks like you may have cut off part of the error.

The FML log should tell you exactly what went wrong. If you don't know what to make of it, upload it to Gist and link it here.

You can't just ask for example code every time you get an answer. Try to figure out the implementation yourself.

I don't have a 1.9.4 workspace set up yet, but if the code is similar to 1.9 I suspect the crash is caused by it calling Item#showDurabilityBar on a null value. This will happen if it tries to render an ItemStack with a null Item .

Either create a separate class for each item with a tooltip (if you only have a few different ones) or create a class that accepts a tooltip (either a single string or a collection of strings) as a constructor argument, stores it in a field and uses it in its override of Item#addInformation .

If an entity (e.g. a player) isn't holding anything in their main hand, EntityLivingBase#getHeldItemMainhand will return null . Calling ItemStack#getItem on this null value causes the crash.

Something on line 79 of BlockFiller is null . Yes.

Post the crash report. For future reference, entities must be spawned on the server, not the client.

After clearing the browser and Gradle caches, I'm now getting the incorrect data every time. I've tried downloading through the browser on both my computer and phone (on both wi-fi and mobile internet), every attempt returns the incorrect data. As a wild guess, could the part of the CDN I'm accessing be caching the old file?

Look at pretty much any vanilla item model, e.g. the spawn egg. Almost all of them extend builtin/generated . Use Minecraft#getBlockColors / getItemColors to get the BlockColors / ItemColors instances and BlockColors#registerBlockColorHandler / ItemColors#registerItemColorHandler to register an IBlockColor / IItemColor . This must be done in the init phase from your client proxy. You can see an example of this here.

If your item model extends builtin/generated (either directly or indirectly through a model like item/generated ), you can simply specify the layer0 to layerN textures (where N is some non-negative number) and the model will be generated using those textures. If you register an IItemColor for the Item , the tintIndex argument will be the layer number.

I cleared Chrome's cache several times before posting, each time the file was downloaded with the incorrect data. A few hours later, it's now downloading with the correct data. Gradle is still obtaining the incorrect data somehow. I've run cleanCache from a different ForgeGradle workspace and re-run setupDecompWorkspace in the 1.9.4 workspace and it still fails with the same error. I've even tried deleting ~/.gradle/caches/modules-2/files-2.1/net.minecraftforge.gradle/ForgeGradle/2.2-SNAPSHOT and ~/.gradle/caches/modules-2/metadata-2.16/descriptors/net.minecraftforge.gradle/ForgeGradle/2.2-SNAPSHOT after running cleanCache , but it doesn't make a difference. Even renaming ~/.gradle/caches so it's recreated doesn't work. I'm not sure why Gradle is still downloading the old file.

Your world's level.dat file is corrupted. You'll need to restore from a backup.

Both http://files.minecraftforge.net/maven/net/minecraftforge/forge/json and the local copy (~/.gradle/caches/minecraftForgeVersion.json) think that builds 1908 and 1909 are part of the 12.16.1.X series rather than 12.17.0.X. I've cleared the browser cache and deleted ForgeVersion.json and everything related to Minecraft 1.9.4 and ForgeGradle 2.2 from the Gradle cache just to make sure, but the issue persists.

Upload the FML log (logs/fml-client-latest.log) to Gist and link it here.

I suggest looking at how ItemMonsterPlacer (the spawn egg) spawns its entity.

That's correct. ModelLoader methods must be called in preInit.

I'm glad you managed to get it working.

ModelLoader.setCustomModelResourceLocation will call ModelBakery.registerItemVariants for you, so you don't have to call it yourself in this case. You also don't need to call it to load Item 's default model (the one with the Item 's registry name). Is your Item 's registry name worldrift:riftwand (with that exact capitalisation)? Could you please do the following to help me narrow down your issue? Remove all model registration code for the wand Call the following code from your client proxy in preInit Run Minecraft Upload the FML log to Gist and post it here Item wand = WorldRift.instance.itemRiftWand; ModelLoader.setCustomModelResourceLocation(wand, 0, new ModelResourceLocation(wand.getRegistryName(), "inventory")); Edit: Fixed the formatting.

This page explains how to set up a development environment and IDE project.

What are you trying to achieve?

Call Entity#getName or EntityPlayer#getGameProfile and GameProfile#getName .

No. Minecraft will automatically load the model with the Item 's registry name if you don't call ModelBakery.registerItemVariants for it, but it won't use that model unless you tell it to. You must call ModelLoader.setCustomModelResourceLocation or ModelLoader.setCustomMeshDefinition to tell Minecraft which model to use for an Item . There should be errors in the log telling you what went wrong. If you don't understand them, upload the FML log (logs/fml-client-latest.log) to Gist and link it here.

Yes. Anything marked as @SideOnly(Side.CLIENT) can only be used from client-only code. This page explains sides in more detail. This thread explains why not to use @SideOnly in your own code.