Choonster

Container#inventoryItemStacks is just a cache that stores a copy of the container's contents. To modify the inventory itself you need to iterate through the container's slots ( Container#inventorySlots ), copy the stack in each slot ( Slot#getStack , ItemStack#copy ), modify the copy and then replace the slot's stack with the copy ( Slot#putStack ). Don't directly modify the stack returned from Slot#getStack as the slot may be backed by an IItemHandler , which specifically forbids modifying the stack returned from IItemHandler#getStackInSlot . I don't think that documentation is accurate, since the vanilla Skull item uses NBT to store the skull owner (for player skulls) and can be stacked. If you're modifying the NBT of items not added by your mod, make sure you include your mod ID in the tag names so you don't overwrite other people's data. Storing the infusion count could be a potential use-case for the new capability system.

No, it's only for 1.8 and earlier. Just Enough Items (JEI) is the 1.8.9 replacement for its item list and recipe viewing functionality.

It looks like CodeChickenLib is missing. CodeChickenCore usually downloads it automatically, but you may need to add it as a dependency manually in the development environment.

Subscribe to ItemTooltipEvent and add lines to the list. If NEI is running, this event won't be fired; so you need to implement IContainerTooltipHandler and register it using GuiContainerManager.addTooltipHandler . I don't think JEI messes with this event, so you don't need to work around it like you do with NEI.

Like the error says, your blockstates JSON is malformed. You're missing the closing quotes for the variant keys.

You created a WorldGenMinable with a null Block on line 47 of OreGenerator .

I can see that you're calling setInventorySlotContents , but is the if condition actually met at the time the packet is received? Is the handler being called? Set a breakpoint in Handler#onMessage , run Minecraft in debug mode and step through the code.

You passed a non-positive number to Random#nextInt in OreGenerator#oreGen (line 44). The code in your original post uses 100 as the minimum y position and 60 as the maximum y position, so maxY - minY is negative.

No, you need to send the coordinates so you can modify the TileEntity that already exists there. Is your handler being called? Is the handler calling setInventorySlotContents ?

You don't call the handler yourself, FML should be calling it when the message is received on the server. Have you registered your message and handler using SimpleNetworkWrapper#registerMessage ?

Is your handler being called? Is the handler calling setInventorySlotContents ?

The jar task builds a deobfuscated JAR, which can be used in the development environment of another mod (1.8.9 can load obfuscated mods in the development environment, so it's not as necessary any more).

Your message can have multiple constructors, as long as one of them takes no arguments.

Move your mod to a directory without an ampersand ( & ) in its name or install Gradle locally. The Gradle Wrapper doesn't work if there's an ampersand in the path.

You need to build your mod using the build Gradle task (either from the command line or IDEA's Gradle widow) so ForgeGradle reobfuscates your mod, replacing all method/field names with their equivalent SRG names (e.g. func_0002_a , field_0003_c ).

Then I'm not sure what's wrong. All I can suggest is cleaning up your code as per my suggestions in this thread and using ModelLoader.setCustomModelResourceLocation in preInit instead of ItemModelMesher#register in init (though both should work).

Ah, I just figured out what's wrong. You didn't specify the variant in the item model's ModelResourceLocation , so it defaulted to normal (which isn't defined for regular item models). You need to specify the inventory variant using the second argument of the ModelResourceLocation constructor (like in my examples).

Definitely no errors in that log. Could you try removing your resource pack? It shouldn't be causing issues, but it's best to rule it out completely.

I'm not too sure what's going wrong. Could you post the log anyway so I can confirm that there's no errors in it? You should be registering blocks in the preInit phase, not the init phase. You should only be registering models from your client proxy so you don't crash the dedicated server. Don't use the block's unlocalised name for the model, use its registry name ( block.getRegistryName() in 1.8.9 or Block.blockRegistry.getNameForObject(block).toString() in [nobbc]1..[/nobbc] Edit: Damn smileys.

I'm not sure what you've done wrong. Are there any other errors in the log? I just made a simple mod that adds a single block here and the model works without issue. If you post your latest code (specifically the class where you register the block and the class where you register the block's model) and the FML log (logs/fml-client-latest.log), I may be able to help you further. Please use Gist or Pastebin to post the log and code with syntax highlighting. To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). To get syntax highlighting on Pastebin, select the language from the dropdown at the bottom of the page.

Your item model has the wrong parent model ( craftattack:blocks/testblock instead of craftattack:block/testblock ). You can't register models directly in your main @Mod class, you'll crash the server. Use the sided proxy system and register models in your client proxy or a class that's called from it. Don't catch an exception if you're just going to ignore it. That will only make it harder to figure out where the error is when something goes wrong.

The ModelResourceLocation is your resource domain (lowercase mod ID), the model's path excluding the .json extension (relative to models/item) and the variant ( inventory for a standard item model). For the assets/craftattack/models/item/testblock.json model, use new ModelResourceLocation("craftattack:testblock", "inventory") .

That method should register the model, but it will crash the dedicated server. GameRegistry.registerBlock needs to be called on both sides, but Minecraft is client-only so it doesn't exist on the dedicated server. I'd recommend creating a class to register your block/item models and calling ModelLoader.setCustomModelResourceLocation for each item (including the item forms of your blocks). You can see an example of this in my mod here. This is called from my client proxy, which is called from my main class. You shouldn't be using Item.getIdFromItem or the LanguageRegistry class. Item IDs are automatically managed and translations should be handled through lang files.

You need to tell Minecraft which model to use for the item form of your block by calling ModelLoader.setCustomModelResourceLocation or ModelLoader.setCustomMeshDefinition from your client proxy in the preInit phase.

PowerConnectable doesn't call the super methods from its overrides of writeToNBT / readFromNBT .