Draco18s

There's a reason our FAQ is actually an EAQ

What on earth is going on here.

withVariant() and getBlock() are counter to each other. withVariant() defines which variant (and thus metadata) to use. getBlock() strips metadata information. If you want to register a variant block as a recipe, you need to get the item stack of that variant. Presumably you have a getDrops() or getPickBlock() method overridden in your block class that will do that. Also, this button is for inline code:

You replace GameRegistry.registerRecipe(...) with a call to Foo.registerRecipe(...) where Foo is whatever you named the class with that code in it. Then, when you run the game, it will generate a bunch of json files in the config/recipes folder. You then copy these files to your assets and disable the Foo.registerRecipe(...) calls.

Show more of your code.

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; }