Hey, coming from this issue which is caused by my Illager Invasion mod loading the RaiderType enum too early on NeoForge, so your Mixin accessing registry values leads to a crash:

Fuzss/illagerinvasion#77

I'll defer the check to verify my own RaiderTypeconstants registered properly, but to prevent this in the future it'd be maybe a good idea to switch to a better way for adding the custom enum constants.

NeoForge actually has a pretty cool system for that: https://docs.neoforged.net/docs/advanced/extensibleenums/
And Fabric has FabricASM: https://github.com/Chocohead/Fabric-ASM

You can simply copy my implementation from Illager Invasion where I add my own constants, it's pretty straight forward once figured out.

NeoForge:
https://github.com/Fuzss/illagerinvasion/blob/main/1.21.5/NeoForge/src/main/resources/enumextensions.json
https://github.com/Fuzss/illagerinvasion/blob/main/1.21.5/NeoForge/src/main/java/fuzs/illagerinvasion/neoforge/init/NeoForgeModEnumConstants.java
https://github.com/Fuzss/illagerinvasion/blob/5e5854622dfdc27b9b4a2c354b91407f84ffcb27/1.21.5/NeoForge/src/main/resources/META-INF/neoforge.mods.toml#L18

Fabric:
https://github.com/Fuzss/illagerinvasion/blob/main/1.21.5/Fabric/src/main/java/fuzs/illagerinvasion/fabric/asm/IllagerInvasionFabricCore.java
https://github.com/Fuzss/illagerinvasion/blob/5e5854622dfdc27b9b4a2c354b91407f84ffcb27/1.21.5/Fabric/src/main/resources/fabric.mod.json#L31

This is not necessary, but useful for checking that the values did indeed apply. I check this during content registration (which is what is currently causing the crash in your mod lol):
https://github.com/Fuzss/illagerinvasion/blob/main/1.21.5/Common/src/main/java/fuzs/illagerinvasion/init/ModEnumConstants.java

Hello there, first of all thanks for the explanation of what is happening, and also the solution (deferred checks on your side)

In the early days i also used forge "special" way to add the enum values and on Fabric i basically did what are you doing now.
The reason why i dont want to use anything like that ever again (not only with enums, but in general, for me its the more common code the better) is that you need to have two separate codes with very different flows, which are platform dependent.

Also i am not and was not fan of forge in any way, but extending enum was pretty easy then, now the "new" neoforge way seems just like a terrible idea, combination of json, where you need to refer to the actual java definitions, i dont want to touch that system :D.

I get that, I was using a common solution before 1.21.4 as well.
The advantage of the dedicated mod loader systems of having proper value indexing and a synchronized order with clients and of course proper mod compatibility for such cases simply outweighs that for me though.

If you don't want to switch maybe still take a look at the custom Supplier NeoForge patches in, which will also avoid this issue in the future if you use the corresponding constructor:

I will add this to my backlog then and will check the options later.

@Fuzss Thanks for the fast solution on your side, its really appreciated!