Draco18s

The name is irrelevant, it just needs to be unique within the Table. It's so other mods can fetch the table/pool by name. If the name is the same, you will get that message Register what how?

http://mcforge.readthedocs.io/en/latest/forgedev/#making-changes-and-pull-requests

Mixins don't modify classes. They let you perform weird inheritance, essentially using a class as if it was an interface.

This is the Forge modder support. If you are not using Forge to mod.... We do not support.

Green carpets use metadata.

"data" in the recipe json files is metadata. Aka "damage value." It is not NBT Data, which is what is needed for spawners.

Here, use this. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/LootUtils.java I already worked everything out for you. Example usage: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/farming/FarmingEventHandler.java#L374

Also, wrong board. Should be Support & Bug Reports.

All the Forge supplied registries. Modders can add their own registries too, if they desire.

You've done something horribly wrong if you're attempting to register a model for Air. (By the way, hint: you do not need an IHasModel interface: all items need a model and they're all done the exact same* way: proxy.registerRenderer(item,0,new ResourceLocation(item.getReigstryName().toString(), "inventory") and any block that has an item renderer will already register its item renderer due to the loop over the ModItems.ITEMS list, which contains the item form of the block already, if you don't cast to IHasModel). https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L197-L199 The array there is just a custom object to hold an Item, Metadata, and String resource location, created during preInit and held until the ModelRegistryEvent. There's nothing special there. *Except when they don't, in which case your IHasModel hasn't really saved you anything.

You mean, by name?

You can also use the LootTableLoadEvent to modify the loot table.

Capabilities.

The only thing that could be null there is I would try and trace this back, but you fill the value with an @ObjectHolder annotation, but your main mod class defines itself via public static final Strings That said, why does your @ObjectHolder annotation not also use these strings? You also haven't included your Block class, which is presumably where you've called setRegistryName on it, so I can't verify that it matches your annotation..

Look at how the overworld handles it.

You have Forge v10.13.3.1403 installed. SecurityCraft wants v10.13.3.1420. 1420 > 1403

There's like....four different meanings of the word "container" in the context of Minecraft ContainerItem ("buckets hold milk / water / lava" and that buckets-of-X need to return an empty bucket to the player when crafted with) "Container" as a generic term for a block or item that has an inventory. Container (the class) for interacting with "containers" GuiContainer for the client-side aspect of Containers It's confusing and I really would like to change the name of Container and GuiContainer to be...less confusing. But I don't have a suggested alternative.

Like milk buckets? It's called a Container Item. The container can be the same item or something else. Even the same item, but with damage.

And this is why I think the IHasModel interface is stupid. EVERYTHING NEEDS A MODEL.

No, that's what Block States are for. They're easy. In fact, color is already done for you. There's a class called BlockColor you can extend.

Not just every tick, every render frame! And you do this with OpenGL commands. Look at how Vanilla handles the fishing rod.

Use less GLManager and more VertexBuffer / Tessellator The VertexBuffer (or Tessellator, if you're familiar with it, it got renamed) is essentially just a wrapper around the GL code, but it makes things easier.

Run in debug mode. Code changes that are trivial are recompiled and injected into the still-running JVM.

Hahahaha, nope. Not unless you feel like rewriting massive parts of the Minecraft lighting engine.

"Do X: It will break everything." What. No. Christ. That is not a solution. Never do anything that comes with the phrase "will break things."