Choonster

ContainerWorkbench (the Crafting Table's Container) does this in its onContainerClosed method. If you're using IItemHandler for your inventories (which you should be), you'll need to replicate the logic in Container#clearContainer rather than calling it directly.

You need to create an IItemColor implementation that gets the colour from BlockColors and then register that with ItemColors. You can see an example of this here.

It's probably worth noting that you can use LootEntryTable to generate loot from another loot table.

RenderingRegistry is just temporary storage for mod entity renderers/factories during the startup process, RenderManager#entityRenderMap stores the actual instances used to render entities during gameplay.

The code you posted doesn't compile, because entry1 is declared inside the if statement but referenced outside of it (because it doesn't have braces). Please post a working Git repository of your mod so I can debug this. See my mod and its .gitignore file for an example of the repository structure to use and which files to include. This .gitingore file tells Git to ignore everything (the first line) except the files that are actually required (the lines starting with an exclamation mark).

The first paragraph ("None of these three method actually do anything") was describing what your code currently does, the second paragraph ("The field initialisers should only create the ResourceLocations") was describing what your code should do. What you need to do is as follows: In the field initialisers: Create the ResourceLocation for each loot table In a method called from your @Mod class in preInit: Call LootTableList.register for each ResourceLocation You seem to have two classes (LootTableRegistry and GlistreLootTables) that store and register your loot tables, you should only have one.

You didn't post the full error. Those are the loot pools. The loot table I want to see is glistremod:glistre_chest_gold. None of these three methods actually do anything. It's only the initialiser of the Custom_Chest_Loot field that registers the loot table. The field initialisers should only create the ResourceLocations, the actual registration of the loot table names should be done in preInit. There's no need to have separate init and register methods.

Post your latest loot table file (the one you're adding this entry to), loot table event handler and the full error.

As I said before, you never add p1 to the event's LootTable; so LootTable#getPool will return null when called with "p1". You're already adding entry1 to p1 in the LootPool constructor, so there's no need to add it again on the next line. You need to call LootTable#addPool to add p1 to the event's LootTable. That said, are you sure you want to have the same entry for the ancient book in both the "main" pool and the "p1" pool?

How did you build your mod? You need to build it using the build Gradle task, which reobfuscates your mod to SRG names (the names used by Forge outside of the development environment) after building it.

You're adding entry1 to the event's LootTable twice, both times to the "main" LootPool. You never add p1 to the event's LootTable. No two loot entries in a loot pool can have the same name (and any loot entry will always have the same name as itself), so this is what causes the error.

Post the GlistreModEventHooks class, the class where you register your items and the class of the ancient book item.

There's no Item registered with this name, are you sure you typed it correctly? Forge requires that each LootEntry in a LootPool has a unique entry name. The entry name defaults to the name of entry's item or loot table, but you can specify a custom entry name through JSON or the LootEntry subclass constructor if you want to have multiple entries for the same item/loot table.

When writing to NBT, iterate through the HashSet and add a tag for each entry to the NBTTagList. When reading from NBT, iterate through the NBTTagList and add an entry for each tag to the HashSet. Note that you don't need to store the NBTTagList in a field or use it at runtime in any way, just read it from/write it to the NBTTagCompound argument of the TileEntity#readFromNBT/writeToNBT methods. Forge patches NBTTagList to implement Iterable<NBTTagBase>, but you can't really do much with an NBTTagBase without casting it to the appropriate subtype so it's not all that useful. Instead, you'll probably want to use a numeric for loop with NBTTagList#tagCount and NBTTagList#getStringTagAt.

Use your IDE's Find Usages/Find References tool on the NetworkManager class to look for fields that store an instance of it.

NetHandlerPlayClient#handleCustomPayload is the method called when the client receives a custom payload packet from the server, it doesn't send the packet to the server. Use NetworkManager#sendPacket to send a packet to the server. S3FPacketCustomPayload is the custom payload packet sent from the server to the client, hence the S at the start of its name. You need to send the client-to-server custom payload packet that has a C at the start of its name (called CPacketCustomPayload in modern versions).

A HashSet is just a collection of values, so you can save it to an NBTTagList. If all you're storing in the HashSet is the enchantment types (i.e. Enchantment instances), you can save the registry names to the NBTTagList.

Running Minecraft through IDEA doesn't use the runClient task, you need to add the arguments to the IDEA run configuration.

I'm not too sure, that looks right to me. Are you getting any errors in the log? Try stepping through ForgeBlockStateV1.Variant.Deserializer#deserialize to see if it's recognising your transforms.

You can use your own recipe classes with the JSON system by creating an IRecipeFactory and specifying it in your _factories.json file. You can see some example IRecipe and IRecipeFactory implementations here and the corresponding _factories.json file here.

No, unlocalised names should only be used for display/translation purposes. They're not unique and can change at any time. Instead, compare the Item instances directly (e.g. stack.getItem() == MyModItems.FOO_BAR) or check if the Item is an instance of the appropriate class (e.g. stack.getItem() instanceof ItemFooBar). This also applies to other registry entries like Blocks and Enchantments. Don't use numeric IDs, they can be different in every save. Use EnchantmentHelper.getEnchantments to get the Enchantments on an ItemStack. The Vanilla Enchantment instances are stored in the Enchantments class. Recipes are managed by a Forge registry, register them in the appropriate registry event; just like you do for Blocks, Items, etc. The name argument of addShapelessRecipe is the registry name of the recipe and the group argument is the recipe's group name. Recipes with the same group name are displayed in the same button in the recipe book. You should move your recipes to the JSON system rather than hardcoding them.

You've got your fromBytes and toBytes implementations around the wrong way. fromBytes needs to read the data from the byte buffer into the fields of the packet; toBytes needs to write the data from the fields of the packet into the byte buffer.

You can specify display transformations in Forge's blockstates format, but not in the Vanilla model format like you're doing. I explain how to do this here.

This is an issue with Blood Magic, it was fixed in version 1.12.2-2.2.1-83 of the mod. Update to the latest version.

Are there any errors in the log? Try setting breakpoints in EntityLiving#dropLoot, LootTableManager#getLootTableFromLocation and LootTableManager.Loader#load and stepping through them when a Shulker dies.