Draco18s

"supposed to propagate downwards" -> lets sky light through it. This is clearly not the effect you want. The point wasn't to follow the existing logic to see what the default method returns for your block (because duh, the default logic doesn't work for you), it was to figure out how opaque blocks block skylight.

There are functions that define this. The default checks what kind of item things are and allows or denies various enchantments. TieredItem only allows Unbreaking (because that's the default).

Lets check the original function. "If the block is opaque, return the maximum light value. Otherwise if sky light is supposed to propagate downwards, return 0. Otherwise return 1." 🤔

You do know what that returned int does, right?

Well darn. What is it for, then? I know that the various functions don't do what one expects half the time, looks like I messed that one up again.

Yes, use Capabilities. The NBT system is what vanilla uses and half the functions available don't do what you think they do. getTileData() for instance doesn't let you store data in the tile entity, it is the NBT representation of the tile entity so it can be stored in an ItemStack. NBT is a serialized data format meant to store the (whatever) on disk. Its not meant to be run-time modified left and right. Vanilla uses it for arbitrary data storage on ItemStacks because Mojang doesn't have a better method.

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)