Draco18s

Its handled by this method: @Override protected BlockStateContainer createBlockState() { return new BlockStateContainer(this, new IProperty[] { /*The properties you want*/ }); } BlockColored already declares this method and the color property.

MessageContext has everything you need and want. Additionally, you have ignored the GIANT WARNING on the documentation page about networking:

This will always be true. Minecraft, the class, does not exist on the server.

getMetaFromState is only used by Minecraft to save the world to disk. "How you've always done it" is in the form of metadata: magic integers ("why does 1 mean north for ladders, but south for furnaces? And white for dye and black for wool?" because magic numbers, that's why). In any case, the enum you have in your class file there is useless, get rid of it. All it is is a duplicate of the EnumColor supplied by vanilla minecraft (and used by BlockColored). This is likely the source of your issues.

Caused by: java.io.FileNotFoundException: dl:blockstates/coal_compressed.json Why is your blockstates folder not inside your assets folder? https://github.com/modles/Dronelander/tree/master/resources

Ok so, here's what you need to know: 1) Metadata is an implementation detail dealing with how the block serializes to disk as well as the metadata of the item form (however these two values may not be the same: modders use the same values for simplicity's sake, but nothing in the code requires it). That's it. 2) The properties handle how the block is dealt with at run time, including its blockstate.json file (represented by strings) 3) The blockstate,json file dictates what model to use (and any state-based overrides) 4) The model dictates what texture(s) to use. 5) The blockstate state based overrides can alter the texture

I'm sure one of the methods in ItemArmor will be of use. There aren't that many, so give them a look, then override it in your own armor class.

Yeah, there's not really a Good Way To Be Sure. :\

You'd want to make sure that the food stats isn't your own before replacing it. Of course, this means that if another mod overrides yours in the same way after you do, and then the JoinWorld happens later without resetting it to the vanilla copy, your code would then wrap the other mod's in another copy of yours....

*cough* 32766. 32767 is the Wildcard Value ("match any").

You should not use ternary operators for getCapability, it makes it pointlessly hard to read. Second, the default case should not be null, you should call super.

Burn everything to the ground and start over from scratch. It'll be easier.

Show your createBlockState method.

Or save the data to the world. ..

So wait, you made a change, it "didn't work" so you undid that change? Also, why are you setting your item's registry name prefix for the Journey mod's items to the API mod's modid?

Yeah, there's a reason I have this class: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/internal/CommonContainer.java

Note that statemappers are client side only. (Your ModelRegistryEvent handler should already be client side, of course)

I can understand why people might want it, but I do fall into the "no, just save stuff" camp.

*Coughs and notes that Eclipse asks you first and one of the options in that dialog is "always save"*

No. We should not be telling people to do this. Especially people like jredfox.

By the way, if your slayer.api package is meant to ship separately so that other mod authors can write plugin mods, your API will crash: https://github.com/TheSlayerMC/Journey-1.12/blob/master/main/java/net/slayer/api/item/ItemMod.java#L36 It has a hard reference to your journey package. What is this even used for? https://github.com/TheSlayerMC/Journey-1.12/blob/master/main/java/net/journey/JourneyItems.java#L153 You should setup and use a gitignore file, these files: https://github.com/TheSlayerMC/Journey-1.12/blob/master/main/java/net/journey/._JITL.java are useless and not necessary to include in your repo.

Do you know what events are? No? Do you know what a newsletter email is? Ok, good, that's an event. SubscribeEvent is how you tell the newsletter organizer that you want to receive the email. Now you know how events work.

You need to first know Java and type inheritance.

Make sure that you've overridden getActualState to get the fullness level from the TE

If you're on the server thread (remember: single player still has a logical server), I think it should be fine.