Draco18s

Capabilities. Yes.

The server would have to do all the same calculations the client did in order to approve.

Note that it counts up towards ItemStack#getMaxDamage, so an undamaged item will return 0 out of X and a fully damaged item will be X out of X (next use breaks it).

Seems pretty self explanatory to me.

Cheating. Player says "let me just modify my recipe files so that cobblestone makes diamonds." Normal server goes "what, no stupid, you can't make diamonds out of cobblestone." You: "OK, diamonds for you! That is a totally legitimate result I believe you're being honest."

So much has changed from 1.12 to 1.16 that very little of your code is going to be usable. You can try importing it and fixing errors, but you're going to have hundreds.

For mods that are yours: Pretty much start from scratch. For mods that aren't yours: Get permission first.

You should probably also use orElseThrow instead of orElse(null).

There isn't one. Documentation (such as there is) is all inside the code itself.

Why the fauk does your renderer change what blocks are in the world? That's not the job of a renderer.

Gasp, you're not on the server.

Why did you create two lazy optionals, then unbox them to pass into the CombinedInvWrapper? (Not to mention using an array to store the local results? Why!?) return LazyOptional.of(() -> (T)new CombinedInvWrapper(getHandler(), new EntityArmorInvWrapper(entity)));

I don't think this gives you water as a below block but rather a block that is waterlogged. Check how lily pads work.

Post your code. My guess is that you're registering an event handler to the wrong bus.

Linked resources are not in your src folder, they're stored elsewhere and referenced in your Project Explorer tab of your IDE.

Yeah I looked at your comments (there were all of about five). Nothing stood out. Start with the mods here, I guess.

In poking around my guess is that you were added as a blocked user. Why? Don't know.

GUIs aren't that difficult. There's dozens of tutorials for them and they haven't really changed all that much in ten years.

Yeah, because you're passing in a height value that's 2.5 times taller than the vanilla Button renderer expects. It expects that all UI buttons are only 20 pixels tall and the sprite sheet reflects that. So what you're seeing is other areas of the UI sprite sheet. (Is the vanilla code broken? Yes. Does Mojang care? No)

Still don't know why you added the 1 if you didn't want block updates.

Cough.

Really high level nonsense, all modifiers are invoked any time any loot is dropped by anything. The LootConditions result in most of those modifiers effects being skipped (because the conditions were false, and that includes things like "a zombie died? Well that wasn't iron ore..."), but they're still checked. The point was to create a system that replaced HarvestDropsEvent in a way that was as data driven as possible and would layer properly so that multiple mods could modify the same loot table without conflict (eg. adding a new crop seed to tall grass). As such its complicated to create, but it is more better than any other approach for all the reasons that those other approaches are broken.

I didn't say it was. I was asking why you did it because its stupid.

Maybe use a rng.Next instead of 0?

Why is this a class property and not a local variable?