Draco18s

You haven't simulated anything. You created a new ender pearl entity and then....did nothing with it. You didn't even set its position (so the default values of 0,0,0 apply) and then ask the game "can this location see the sky?" No, no it cannot.

Remove the "display" attributes and change the parent to "item/generated" instead of "builtin/generated" item/generated sets up all of the display tags you'd ever want (for tools/weapons, use item/handheld).

Just be aware that every time you run your mod and the recipe stuff is enabled, it will generate a bunch of files. It makes no attempt to delete any and will just use new names for the same recipes/advancements.

See also my reply post at the bottom which also supplies some code to generate the advancements (although the trigger conditions still need to be adjusted manually).

When?

Yes

RegistryEvent.Register<IRecipe>

Not sure, I've not encountered this problem before.

As long as the "modid" part of the path matches your mod ID (remember that everything is enforced lower case!) you should be fine.

The recipe book is handled by an advancement, which is a separate JSON file. Additionally if you have the gamerule enabled that any unlearned recipes are uncraftable, that could also be blocking you from crafting your new recipe until you have that advancement.

Gotcha

You already had an mc variable, you don't need to do Minecraft.getMinecraft() again.

You bound a texture. When you're done, you need to rebind the texture vanilla was using.

The client and server are picking different random values. The client's value updates the GUI immediately (because it's already right there) but the server has to send a packet informing the client of the current (and correct) stack size.

Well...you'd need a custom sword class, you can't do this with just the tool material enum.

No, you need to specify all variants.

Oh god no. That would take billions of bytes of RAM to store even the smallest of worlds. No no, Block classes are a model, this is why all of the methods are passed a World and BlockPos value. Also, by making that field static, you forced it to be the same value for all instances of your class anyway, so even if you were right, you still singleton-ized the value. If you need per-position storage, you must use a TileEntity.

Show your code. mcmod.info files are useless, they are barely even used by Forge.

You're probably missing: public boolean isFullCube(IBlockState state) { return false; }

We should probably get Forge to find a way to adjust that.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/OreEventHandler.java#L40 https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/RecipesUtils.java#L100

Creative Tab != Recipe Tab The creative tab is where the item appears in the creative mode inventory and has dick to do with the recipe book.

You can but it's easier to just check for null.

For reference, that is an error that is trapped with a try...catch block. As there is a sensible thing to do in the event of failure, the error is printed to the console and the game moves on with its life.