Draco18s

Override boolean canApplyAtEnchantingTable(ItemStack stack, Enchantment enchantment) in your item class.

Blocks and items are singletons, this value is shared across all "instances" of your item. You have to store this data in an ItemStack's capability.

Solved public static final DeferredRegister<LootItemFunctionType> FUNCS = DeferredRegister.create(Registries.LOOT_FUNCTION_TYPE, MODID); I hadn't been able to find Registries.LOOT_FUNCTION_TYPE

I have a custom loot function that I want to have run when my own loot tables for my own blocks runs (it sets the number of drops based on a blockstate value). Things that did not work: Using Forge registries Forge does not provide a replacement for BuiltInRegistries.LOOT_FUNCTION_TYPE Forge also does not appear to need or provide a replacement for BuiltInRegistries.LOOT_CONDITION CanToolPerformAction just creates a new LootItemConditionType and runs with it, no registration needed Using an existing LootItemFunctionType in LootItemFunctionType getType() De/serializer attempts to cast my function to an unrelated function Using a new LootItemFunctionType() De/serializer gets a null serializer to serialize with Cannot invoke "net.minecraft.resources.ResourceLocation.toString()" because the return value of "net.minecraft.core.Registry.getKey(Object)" is null Attempting to make the same calls LootFunctions.register does Fail with fml.modloading.failedtoloadmod Attempting to make the same calls as LootFunctions.register at different points during the init/setup process (tried numerous events) Most fail with an Optional.get() returning no value (in this case, trying to get the built in registry's ResourceKey as a ResourceKey<E> not a ResourceKey<? extends Registry<E>>) Others fail with fml.modloading.failedtoloadmod Things I will not do, but which would probably work: Individually test against 16 different values and individually compute the resulting fixed value count This is so dumb I'm not even going to pretend that I should consider it

Just so you know, that's not the only way items can end up inside block inventories. I know there's a way for the inventory to determine if an item is valid for its slot, but I'm not sure there's a reciprocal call asking the item if it can be placed in the slot.

Because the when the game is compiled by Mojang, those names cease to exist. So when Forge decompiles it, it has to give them new ones. Those new ones are what's called SRG names, which are unique for every field, variable, method, and class, but are stable from one minor version to another (eg. 16.1 and 16.2 will decompile to the same SRG names). A second pass is then done to convert those into human readable names...which doesn't have a human readable name for everything, so the leftovers are left with SRG names, because someone has to go figure out what the human readable name should be and update the mapping.

Long answer short: No, there is no documentation. Longer answer: The code changes so often and so dramatically that any attempt to document it is impossible (there are a few people who've tried, the last time I saw them update was 1.7). As such your only recourse is to read the code.

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.