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.

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/

Compare a stored worldtime to the last-checked world time. If different, you know it hasn't ticked any times, if it has, it's ticked at least once.

My info* I looked at the code for it back in 2013, which was in the linked bug report. Warjort just rephrased it. That's what I thought, but I wasn't sure if you meant like carpets or like snow layers where you can make the block thicker, but still take up less than a full block.

https://bugs.mojang.com/browse/MC-1127 Resolved as "working as intended" Clarification required.