Draco18s

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."

https://en.wikipedia.org/wiki/Multithreading_(computer_architecture)

Personally I'm interested in knowing what will change: what will newly be possible and what will no longer be possible. It's going to be a mountain. Deal with it.

I mean, probably. Stan might also be dead too, though. If you use the rules from the game of shiritori from No Game No Life (where their spoken objects will either materialize or disappear), notably when it ends (the first person to be incapacitated or killed as a result of a move) Meruem would still be the "winner." (Think about the fight between Meruem and Netero: Meruem won that fight, even though Netero was the one with the bomb: Netero's goal wasn't to win, it was to insure that Meruem died).