Draco18s

No. And you don't need to. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/block/BlockOreFlowerDesert1.java#L56

Have you tried looking at the vanilla blocks that work like this?

This is equivalent to input.getItem() == Item.getFromBlock(Blocks.OBSIDIAN) and uses less memory by not creating an item stack that has to be cleaned up.

Its called a race condition, and its effects are entirely non-deterministic due to outside factors like the hypervisor thread scheduling.

The # here means you need an instance of the Minecraft object in order to access the player field.

Hoppers work just fine. It's mod added machines that won't interface properly.

Not enough code here for us to solve your problem. Post the entire class at a minimum.

Eclipse Quick-Fixes are rarely the correct answer. ESPECIALLY if you don't know WTF you're doing. Which entity living base do you want to effect? Because EntityLivingBase is a class. "I'm not using Forge and I don't know what's wrong, maybe I should ask on the Forge forums for help!"

In between turns of fighting OblivAeon? I'm sure it was fine. (Also, we won. Took 8 freaking hours)

I think its behavior he doesn't have and wants. Not behavior that he has and doesn't want. But either way, in order to change it, it has to be custom code.

The game does not do this. You need to save your data somewhere else, manually.

Yeah, that. Was on tablet at a party.

And your code will crash the desiccated server.

Capabilities are not set up to work this way.

Without seeing them I can only speculate. Note that missing model errors are a general error that's Caused By an other error (which will actually tell you what's wrong).

No. Worst idea. Because you never update the values. All of them are air, will always be air, and will never be anything BUT air, as you never assign a value to them except during class construction.

Not enough code supplied to adequately diagnose the problem. But it's probably here:

Why are these class level properties? Why are these determined when the class instantiated and not when the class gets an update tick? You probably want some parentheses here. Quick, will this entire statement be true or false for the following values: true, true, true, false (note that I have not performed a ! on any of these). How about for false, false, true, false?

Its called "reading your damn errors." Its literally right there, in the error. Good news: I'm a strong proponent of teaching people to read their damn errors.

I'm almost certain that Loremaster didn't start the IHasModel fiasco. Either way, I've commented on his video about IHasModel. He's literally the last person that should be teaching others how to mod because he, himself, is still learning. Blind leading the blind, much?

You're missing a data value in the result.

Stop using IHasModel. All items have models. All of them. Yes, ALL of them. And they all need the same registration code for the most part and none of the information required to register a model is private. Stop uisng BlockBase. There's already a "base" block class, its called Block. Using a super class to avoid repeating yourself is not what the class hierarchy is for. You want to stay DRY? Do things right and put the code that registers your models inside the ModelRegistryEvent and stop using IHasModel. Get rid of the need for IMetaName. With 1.13 around the corner you shouldn't be using metadata to define completely different blocks (aka The Flattening), so there's no reason to go around doing that now, there's no longer a (functionally relevant) block limit any more, as everything is referenced by the registry name (a string). Anyway, this is how I registered blocks that had variant states: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L63 (or the version on L75 if you have a custom state mapper) I didn't bother constructing the variant string manually (like you're doing), but used the exact same method calls that the game uses.

Less "bad" and more "completely pointless." The only bad thing about it is that it violates the DRY principle ("don't repeat yourself") making you type the same 3 lines over and over again, as well as obfuscating how/if your models are being registered. Its not that it doesn't work, but that when it fails, its harder to figure out why (as well as serving no purpose: all items need models and none of the information needed to register one is private (but this CAN change in some circumstances--eg custom mesh definitions--and THAT'S what an interface is good for)). (Note that I'm the one that started the crusade against IHasModel and I'm pretty sure you're echoing what someone else said about it, and not what I've said. ) Other than that, pretty accurate post

1.7.10 is no longer supported here and your problem isn't one we support anyway (you're USING mods, we support mod MAKERS).

Sounds like someone needs to make a Forge PR to fix this.