Draco18s

Sounds like you haven't correctly overridden the method. That is, the original has an annotation that is IMPORTANT that you have not annotated your override with.

Cough, 1.16

That's basically what Ingredient.fromTag is. It doesn't make sense to query the item registry, the item registry doesn't know or care about tags. Try also: new ItemTags.Wrapper(new ResourceLocation(...));

Yep, definitely changed and a lot. Didn't really expect that, but I knew the process that I'd use to locate the relevant bit of code. That is, I knew BlockColors was involved and that something got registered.

Of course it doesn't exist, buffer.write__ methods only write primitive data types and some helpers for ItemStacks and BlockStates (both of which can be decomposed to primitives, but Forge/Vanilla was kind enough to supply those for you). You need to decompose your Steps down into primitives.

Aren't you the one who wrote the recipe -> packetbuffer code in the first place? Yes, yes you are. Your buffer doesn't contain that information. The only thing you write are the ingredients and the output.

Don't search the whole project for that string, search in RedstoneWireBlock. Or go to BlockColors and look at how RedstoneWire's color gets registered and work backwards.

Don't put your mod's tags in the Minecraft domain, put them in yours. Its your mod's tag it belongs with YOUR mod, doesn't matter that they're vanilla items.

Forge overrides vanilla. Any override you create therefor must override Forge. Note this is not a "I would like to override Forge" conscious decision. It is forced upon you by the very nature of the system's design.

That's very strange.

This and this and this : All do the same thing. Pick one. (Ok, the last one registers another class, but all three are "I would like to register something with the event bus please")

Nothing I can see in the Coral block class indicates that it should bypass that method. Its called directly from the LootTable class

Whatever recipe you're using to replace the vanilla recipe needs to be named the same and placed in the same location (so, you have the location correct, I assume you've named it correctly). I am aware of, but thought it got fixed, that any recipe forge overrides from vanilla could not, itself, be overridden.

Go into the ForgeHooks class (net.minecraftforge.common) and drop a breakpoint all the way down towards the bottom inside the modifyLoot method and use the debugger to see what's going on.

The forge version overrides the vanilla version already.

Did you register this class?

Use the debugger, check what object is coming back as the TrueSource and why its triggering your boolean check incorrectly.

What's the vanilla file named?

I don't have a 1.16 workspace, but its a method that returns an int and has a line that looks like "return -16777216 | i << 16 | j << 8 | k;" (the "-16777216" part is just FF for alpha, already bit-shifted). Alternatively, dig into where BlockColors gets referenced and how.

Not sure.

This makes no sense.

Textures are client side only. You will not find any server code related to colorization. For redstone wire, the math is in RedstoneWire#colorMultiplier(). All it does is return a color (255 RGB as a single unsigned integer) that is then multiplied against the texture when it is rendered. As for where OpenGL gets involved? Dunno, its buried inside the ModelBakery.

I have no idea what the problem even was. Glad you figured it out though.

Don't. There is no reason to. The only registry that matters in the Registry.Register<Item> event is the items registry, which is given to you by the event. A simpler way to do what? You don't do anything with that variable.

No, it makes the advancement that unlocks the bone -> bonemeal recipe impossible to get. Its not a new advancement at all, notice where it lives. If you create a similar advancement for the grindstone, then picking up a slab won't give you the grindstone recipe. Or you can alter the condition, unlock reward, etc.