Fuzss

I came across another feature of `FMLConstructModEvent` the constructor method does not provide. There is no work queue for sequential code execution. This would be useful when accessing non-synchronized collections...

I'm not convinced patching all the `stillValid` methods is the right approach for this. It's very likely for modders to forget to call the NeoForge `menuValidity` method instead of vanilla....

I'm not sure this is still an issue since the vanilla implementation has changed in 1.21.2+. But generally this can be tested by simply trying to access tag values from...

`EnchantmentHelper::processEquipmentDropChance` also would need a patch specifically checking for looting. This is the method responsible for the chances for dropping e.g. armor worn by monsters.

That might be worth looking into for a separate event. The entity in `LootingLevelEvent` is the attacked entity, not the attacker which is passed to `getEnchantmentLevel(Holder holder, LivingEntity livingEntity)`. Also...

So I just implemented a replacement for `LootingLevelEvent` in my own library renamed as [ComputeEnchantedLootBonusEvent](https://github.com/Fuzss/puzzleslib/blob/main/1.21/NeoForge/src/main/java/fuzs/puzzleslib/neoforge/api/event/v1/entity/living/ComputeEnchantedLootBonusEvent.java). I'd much appreciate if someone could just copy / adapt my code to NeoForge, I'm...

The NeoForge config implementation has changed, and FCAP has been updated to reflect those changes. In that particular case `ModConfig::getFullPath` throwing an exception is indeed an oversight on my end...

I've now implemented a workaround for `ModConfig::save` in v21.0.5. Can you please test if that version works again on servers?

https://github.com/architectury/architectury-loom/issues/191

https://docs.architectury.dev/plugin/gradle_configurations