Draco18s

Caused by: java.lang.RuntimeException: Encountered an exception when loading model definition of model blockstatetraining:blockstates/lighted_glass_block.json Caused by: java.io.FileNotFoundException: blockstatetraining:blockstates/lighted_glass_block.json Your modID is "blockstatetraining", but your assets folder is named "bst"

Inserting a list into itself seems like a good plan.

Not neccessarily. The error is only the surface error: - It can be caused by a missing block state file (the game still fails to find the variant) - It can be caused by a malformed json file (the game still fails to find the variant) - It can be caused by an incomplete json file (as you suggest, the game still fails to find the variant) - It can be caused by a missing or bad model file (e.g. something the blockstate file says to load, but the game fails to find, the game still fails to find the variant) The surface level error "variant failed to load" is meaningless until you dig deeper to find the "Caused By" line following it.

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.