Draco18s

The reason block container doesn't work is because it overrides getBlockModelType() to make the block invisible.

Well, the problem here is that you blindly pick a block below the surface. If that block isn't air, you don't generate.

*cough* 1.12 *cough*

You just need to tell the oredictionary about your block, vanilla items (like wooden axes) already have oredict recipes.

"Subworlds" is not in the code as anything. It's a notion.

registry.registerAll( oreSapphire, oreSapphire.setRegistryName(oreSapphire.getRegistryName()) ); This is equal to block.setRegistryName(block.getRegistryName()) and wrong. You should be doing item.setRegistryName(block.getRegistryName())

It doesn't work that way. There's an older mod that does what you're looking for and it uses subworlds (essentially a second World). Worlds don't collide with other Worlds though. And no, I don't know how to do it.

*cough*

Then look for ONE air block.

Or as I like to think about it, canInteractWithThisEntity If you can't interact, then you can't view, viewing is interaction.

And specifically, the LivingHurtEvent only runs server-side.

user action -> entity on server gets awake -> send packet -> packet handler sets the same value on the client entity -> renderer reads the data in the entity when rendering the model

You aren't registering am item model anywhere that I can see

Size isn't important. Capabilities is about compatibility and accessibility.

Random question: why do uou pass both message (which you use to pull message.awake) and message.id?

Height had nothing to do with the stated problem. It is X and Z that need to be offset.

Dunno then.

Your packet doesn't do anything when it arrives. void proccessMessage(PacketReturnAwaken message) { try { }catch(Exception e) { Utils.getLogger().catching(e); } } So blank, much void, many noop. Wow. Additionally, your packet doesn't have any way of finding the entity it needs to awaken.

Aaannnddd...The "old"system still exists. Capabilities are the replacements for the massive interface list, implements IPowerUser, IMechanicalPower, IRedPowerConsumer, IInventory, ISidedInventory, IButterworthPillbox, IForestryFishnet, IRotaryBanana.... It isn't a replacement for data storage.

If you ACTUALLY register models on the server it will crash, yes.

Probably because ModelLoader itself (while in a client package) isn't marked SideOnly, but its parent class is. This means the JVM can find ModelLoader and the server is fine. But! There's no guarantee that that won't change suddenly and unexpectedly in the future. You're safest assuming that client stuff only happens on the client than saying "works for me." Because at some point, it suddenly won't, and you won't know why.

How equal are item stacks? Item: yes Metadata: maybe (tools vs. dye) Stack size: unlikely (but maybe you do care, eg. recipes) NBT data: sometimes (depends on the item and the NBT tag) Ergo you need more than one way to compare.

That has nothing to do with it. Pretend you are the JVM. When you load a class you need to check that the class contains valid code. Ie that every referenced class with its already loaded or can be found and loaded if it is needed. The JVM cannot predict whether or not a given method will execute, so it assumes that all of them will at some point. The JVM scans through your class, finds a reference to a ModelRegistryEvent, attempts to locate this class, and fails to do so.

Probably create a custom IRecipe implementation (you can subclass the existing ones).

The magic of packets