Draco18s

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/farming/block/BlockTanner.java#L89-L103

Of course you "join world A" and then "join world B" won't carry a value with the player. They aren't the same player. It's the same player account, but World A and World B are two completely unrelated save files. Data does not carry over between them.

This question is either backwards (JSON files point to IRecipe implemenations) or confused (slots don't "look for" json files). If you want to locate recipes, look at the list of recipes.

Hardcore is not hard coded. Hard coded mean that the data is made up of magic numbers (strings, whatever) in the source code. This has nothing to do with "hard core" meaning very hard or advanced play.

"Packets" are a conversion between runtime data and a binary serialization format. That's all. Look at this example: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/networking/ToClientMessageOreParticles.java The only "code" that is there is writing to, and reading from, a ByteBuffer. Your MessageRestoreFatigue does fuckall: it writes no data and it reads no data and instead...gets the capability on the client and directly modifies the values there. What you should be doing, is sending a packet from the server to the client containing the fatigue value. Your packet also does that on the networking thread, which is a major no-no.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/OresBase.java#L386-L394

You can get the same effect by overriding the methods that call it and using a different implementation.

You can't override static members. https://stackoverflow.com/questions/2223386/why-doesnt-java-allow-overriding-of-static-methods

You don't need a tile entity for this. All that happens when you insert an eye of ender into an end portal frame is that the block changes state. As a result, it changes models. This can all be done with the JSON blockstate system. { "variants": { "eye=false,facing=south": { "model": "end_portal_frame_empty" }, "eye=false,facing=west": { "model": "end_portal_frame_empty", "y": 90 }, "eye=false,facing=north": { "model": "end_portal_frame_empty", "y": 180 }, "eye=false,facing=east": { "model": "end_portal_frame_empty", "y": 270 }, "eye=true,facing=south": { "model": "end_portal_frame_filled" }, "eye=true,facing=west": { "model": "end_portal_frame_filled", "y": 90 }, "eye=true,facing=north": { "model": "end_portal_frame_filled", "y": 180 }, "eye=true,facing=east": { "model": "end_portal_frame_filled", "y": 270 } } }

Think it is woodLog.

(And register item models for all variants, as normal)

Also, scrap IHasModel. All items need models. ALL OF THEM. ALL OF THEM. And none of the data needed to register one is private.

You need an entirely different system for nbt. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/industry/item/ItemCastingMold.java#L87-118 https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L185-195

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L147

Are you trying to do something like I did here? https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/item/ItemRawOre.java https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderores/blockstates/orechunks.json

Also familiarize yourself with Minecraft's existing mechanics. Not just what it does, but how it does it. Many of the "I want X but Y" questions can be answered just by cribbing from vanilla.

Gist updated. Fixes: Backspace and delete now function at line boundaries (collapsing 2 lines into 1). Enter now functions as expected when in the middle of a line (splitting at the cursor).

OTG shouldn't have to, its called by world.setBlockState() automatically. Ooh, never mind, Forge did things that make it not called. You could make your block declare that it has a tile entity (hasTileEntity returns true) but never actually supply one (returns from getTileEntity are null checked). That'd make onBlockAdded get called for your blocks.

This class is not marked with @EventBusSubscriber https://github.com/Colton-Slayden/Solis/blob/master/src/main/java/com/royalreject/solis/proxy/ClientProxy.java#L14

Might've changed, I might've remembered wrong. public void onBlockAdded(World worldIn, BlockPos pos, IBlockState state)

I believe that OnBlockPlacedIntoWorld is called after its placed by worldgen.

That's because world models are registered automatically. The block's registry name points to the blockstate file, the blockstate points to the model, everything's good. Items you have to register manually. Fortunately you're doing that with your ModelRegistryEvent. But there could still be any number of things going wrong. You have to read your log to find out what.

We still need the crash log. We don't know what's wrong. All you've told us is that "it crashed." Which is about as helpful as calling up your doctor and saying, "it hurts" and hanging up.