Draco18s

It also leads to everyone writing their own API addons that duplicate efforts and makes things incompatible with each other because everyone creates a patch that does what they need and only what they need. It also means that when Minecraft updates if you have a mod that relies on one of these additional specialized APIs, you have to wait on that author to update it, even though Fabric's main API is already current. Neither Waila nor JEI require additional source patches to work with Forge. They have their own APIs, yes, but that's not what I'm referring to when I say that Fabric requires modders create additional hooks inside vanilla code. Forge makes sure that every mod stays well out of vanilla code so that mods don't conflict with each other and crash the game. I'm referring to this: https://fabricmc.net/wiki/start#mixins_asm Fabric pushes modders towards ASM. ASM is dangerous, complex, and highly fragile. It can lead to code that crashes code that isn't your code with the resulting stack trace having no evidence as to which mod caused the issue! It can DO anything, but it doesn't do it safely.

AH HAHAHAHAHA! 🤣 No seriously though, the two ecosystems are so wildly different that it wouldn't be so much a "port" as "rewritten from scratch." Forge: make everything compatible because no one touches vanilla code directly. If Forge doesn't make what you need possible, make a PR. Fabric: we can update to new versions quickly because we only have the basics. So if you need something special, you're going to have to patch the vanilla code yourself, have fun~!

A Double (with a capital D) absolutely can be null, because it's an Object that boxes a double (lower case d).

Nope, that class looks fine. Did you register the serializer? Did you add it to the forge/global_loot_modifiers.json list?

You have an error on line 85 of CopperKilnGuiMenu

Correct. Look at how vanilla handles the lectern.

BlockState#GetBlock()

This is client side only.

BlockPos.GetAllInBox, or whatever mojang called it. It literally gives you an iterable that solves this.

That only gets you LOGS and PLANKS, he doesn't want to know if the item is wood, he wants to know if it's made of wood. Example: jungle door. Jungle Door is made of wood, but is neither a log nor a plank. Doing it with tags, and not creating a new tag, you'd have to check: logs planks wooden_buttons wooden_doors wooden_fences wooden_pressure_plates wooden_slabs wooden_stairs wooden_trapdoors And possibly still have to check for other blocks like ladders. I'd even go so far as to say the tag mineable/axe would cover it, but it's more like "everything in mineable/axe except..."

You can use the block's Material

"Exit Code -1" is just the "application closed with an error" message, it is not itself the error. Post the whole log.

Need more context

Well. Yes. Blocks aren't meant to take up visual space outside their 1x1x1 cube. Two vanilla blocks have this issue as well. https://bugs.mojang.com/browse/MC-158827?filter=-2

Kinda sorta. Don't catch fatal errors. Don't create boneheaded errors in the first place so you don't need to catch them. Exogenous you must catch, while vexing are...well, vexing: the product of unfortunate design decisions that may (or may not) have a Try alternative that doesn't throw an exception when there's a problem, but if not, the exception must be caught. https://ericlippert.com/2008/09/10/vexing-exceptions/