Draco18s

Irrelevant to the problem. You cannot create public anything inside a method. This has nothing to do with sides. This is a Java syntax problem.

Custom clients and direct-MCP coding are not supported by Forge, ergo don't ask on the Forge forums how to do it.

You need to create your own IRecipe implementation.

Do not make custom clients.

Create a modifier that says "I want to listen for entities." Modify the generated drops when your code runs. Your code has 100% modifiable access to the drops array and 100% accurate looting context. Its like an event. But is datapack manageable.

No. Do not do this.

Why not dig into the World and Chunk classes to find out what happens when you call setBlockState(). They don't have indexes at all.

Sure can.

Nope, only one. The double slab block is just a state. https://minecraft.gamepedia.com/Slab#Block_states Ok, see all that stuff in your constructor? It doesn't need to go in your constructor. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L119

What? Why? Clearly there's some fundamental property of a slab that makes it a slab (probably SlabBlock) and some mere data that differentiates one slab from another.

Doesn't exist any more. Has been replaced by Global Loot Modifiers If you don't want to use them then do it this way: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderfarming/EventHandlers.java#L49-L53 https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/resources/data/harderfarming/loot_tables/blocks/grass.json

You can still static-create things before registering them with the event. DeferredRegistry precludes that entirely.

Go find the vanilla Items class, its in the net.minecraft.item package (remember Items, with an s, not Item). In the giant list of items, find any vanilla item that behaves the way you want. Cake, redstone dust, etc. Find out what class it uses.

Don't use BlockItem. Look at vanilla's items that work this way.

Your object holder annotation is bad.

Yes there is. It solves the issue of people registering their blocks and items in a static (UNCONTROLLED) location. Forge can't control/verify the domain paths when ResourceLocations are created statically.

Use @ObjectHolder

The JSON system is IRecipe, you just don't see it because you don't have to touch it.

Nothing, because Minecraft does not make the check for blocks the player is rubbing their face on.

You have to install Java. If you have Java installed, google "how do I set a path variable?" and set the JAVA_HOME variable.

You know how torches and glowstone....glow? getLightValue() returns the amount of light that a block emits. Its a result of Forge trying to supply state-full versions of the method where vanilla does not, so that one block with multiple states can have a different light value for each state (if it so chooses).

Well. You still have this one. But you're right, you have another too: Your json file has invalid syntax. https://jsonlint.com/

Yes. That's what a ResourceLocation represents, a domain ("mod ID") and location. You ask for new ResourceLocation("NotMyMod","SomeAsset") and you'll get it. Of course, if you're writing a json loading system for a type of asset, I recommend looking into the JsonReloadListener system. As an example, https://github.com/MinecraftForge/MinecraftForge/blob/d4b6540746ce5676a9a2efe24b87debb3f79dfe7/src/main/java/net/minecraftforge/common/loot/LootModifierManager.java#L38 Note that you need to register it with the MinecraftServer instance, which will require some reflection.

In the extremely unlikely case that you can't read simple regex, a-z and A-Z are different things.

Yes. Because it wooden_katana as a variable name doesn't exist. The method accepts a string, pass it a string.