Draco18s

No one cares, this isn't a chat room. Anyway, ok, that looks less awful than I'd originally thought. ModelRegistryEvent is client-side only. It can't live here. IHasModel is a fucking stupid convention. Seriously. ALL ITEMS HAVE MODELS Your IHasModel does nothing to insure that your block class registers an ItemBlock for itself, leading to a possible crash if you forget. The method your IHasModel interface supplies just redirects to your client proxy with no additional information from the block/item. proxy.registerModel(item, item.getRegistryName(), "inventory") will work just fine (or if the code is already in the client proxy--see #1--then you don't need the proxy. part...or really, you just just call ModelLoader directly).

You shouldn't be accessing that line at all. Use the registry registration events like you're supposed to.

Did it ever occur to you to post it and let us look at it?

So, I'm curious, why have hasCapability at all then? i.e. what's the usecase where you wouldn't be calling getCapability?

extend ItemAxe? And use the correct constructor (the one with two floats) You don't need Set<Block> EFFECTIVE_ON, that's handled by setHarvestLevel()

OH GOD, THIS WOULD BE WHY YOU HAVE PROBLEMS. FUCK ME. Use the RegistryEvent.Register<Block> event to register your blocks. It's called "you extended a block with declared properties that you don't want and don't need, stop doing that." That or "you added a property that doesn't exist in your block to your blockstate file and did so in a way that is fucking retarded because you made it contain your other properties and that is Wrong." One or the other, I don't know which, maybe both. I can't be arsed to look at Vanilla's code right now.

Then you have something somewhere telling Minecraft to fetch the wrong thing. Also, you should do something about having a Facing property and a Sunflower property you aren't even using

Lets start with this chunk: And boil it down to only the important bits: Three lines. The first one tells us what variant failed to load. Not very important, but this is where to start. Then we find the next "Caused by" line, line two. "Encounter an exception when loading the model definition" this tells us something is wrong with the model, not the blockstate file. The next "Caused by" line tells us what went wrong: NoSuchElementException. Something is wrong with your realfoods:tomato_plant.json model, which you have not posted.

Post your log. There's delicious information in the log. You should learn to read it.

Is north the only direction your block can face? I suspect not.

WRONGLY DONE, SIR. Look at my example again. Notice how "shape" and "powered" are at the same level of indentation. At no point was one of them inside the other.

You have more states than just an upper/lower half. You also have a facing. Here's an example of a two-property blockstate file in the Forge format: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/expindustry/blockstates/rail_bridge_powered.json#L19-L39

list.clear

That's because you should, in most cases, be contacting the creator of the mod causing the problem, which you can do by posting in their thread on the official forums or on Curse where you likely downloaded it from.

You're in the wrong place. This board is to help people making mods. But as I like to try and educate people on how to read a stack trace so that they can go complain to the right people and/or correct their own stupidity: java.lang.UnsupportedClassVersionError: thaumicenergistics/fml/ThECore : Unsupported major.minor version 52.0 ThaumicEnergistics is complaining about an unsupported version of something else.

"Hey, give me a new UUID, here's the current one that I want you to construct the new one from" And then you complain in surprise when they match.

VanillaInventoryCodeHooks.getItemHandler() is the compatibility patch from vanilla style inventory to the Forge Capability system.

All container blocks require Tile Entities to store those items. All of them. Every single one. So: 1) Get the tile entity 2) Get the tile entity's item handler capability (CapabilityItemHandler.ITEM_HANDLER_CAPABILITY) 3) Done

Ah, you are right. I saw the class BlockWhatever implements IWrenchable at the top of a code block and didn't see that it was an empty class with an item definition right after it.

Makes sense. It was just an event I'd never used and hadn't looked into, so I wasn't sure where in the ordering of things it was.

I am not entirely sure that you can. That "tag" is added by a chunk of vanilla code that runs after an item's addInformation() method is called. There is a tootip information event, but I don't know if it runs before or after that chunk of vanilla code.

Vanilla format: "half=lower" { "texture" :"some/texture" } Forge format: "facing": { "north": { "texture":"some/texture" } } http://mcforge.readthedocs.io/en/latest/models/blockstates/introduction/ http://mcforge.readthedocs.io/en/latest/models/blockstates/forgeBlockstates/

This is not a valid blockstate json. You've smashed together the Forge format and the Vanilla format without thinking about what you're doing.

The model mesher is incredibly finicky, that Thing You Don't Like. The Model Loader just works.