Data loading error when Thermal Expansion tries to load fuel values too early

[IchigoGames]

Versions of Minecraft, Forge and Adorn

• Adorn: Adorn-1.13.1+1.16.4-forge
• Minecraft:1.16.5
• Forge: 36.0.42

Describe the bug

a isssue with data packs in adhorn idk much about data packs my self i try to avoid them but this issue happens when you create a world and then close out of mc then try to load same world it does not load only way to load it is to create another new world then you can load the world you where unable to load before.

To Reproduce

Steps to reproduce the behavior:

1. load pack with mod installed create new world in singleplayer join it.
2. close out of world close minecraft and restart minecraft.
3. try to load back into the world you had just created.
4. See error data pack failed to load gives you the option to back out or continue in safemode if you click continue it will never load and minecraft stops responding

Expected behavior

to be able to create world and load back in after a restart.

Additional context (Optional)

this is not a full crash so there is no crash report minecraft simple freezes and windows ends task after a long wait

the issue does not happen with only kotlinforforge-1.9.0-obf installed but does if you also have adorn installed of course there is no way to test Adorn without kotlinforforge but im assuming the issue is with adorn.

Logs https://www.dropbox.com/s/yxw1a2xzxfsl58e/latest.log?dl=0

edit.after doing more testing it seems to not happen if i only have the two mods installed so it must be a mod conflict with other mods in my pack The Final Frontier 2

[IchigoGames]

[Juuxel]

java.lang.IllegalStateException: Tag adorn:chairs used before it was bound
	at net.minecraft.tags.TagRegistry$NamedTag.func_232944_c_(TagRegistry.java:131)
	at net.minecraft.tags.TagRegistry$NamedTag.func_230235_a_(TagRegistry.java:142)
	at juuxel.adorn.item.BaseBlockItem.getBurnTime(BaseBlockItem.java:14)
	at net.minecraftforge.common.extensions.IForgeItemStack.getBurnTime(IForgeItemStack.java:90)
	at net.minecraftforge.common.ForgeHooks.getBurnTime(ForgeHooks.java:1259)
	at cofh.thermal.expansion.util.managers.dynamo.StirlingFuelManager.getEnergyFurnaceFuel(StirlingFuelManager.java:73)

Looks like a compatibility issue with Thermal Expansion.

[PixusPanic]

I'm having the same exact issue; I brought this up in the TeamCoFH Discord server and one of the moderators says that the team didn't "think [they] ever figured out why it's happening" and that the moderator is "confident it's on adorn's end".

While I don't expect it to get updated soon and/or for 1.16, especially with the release of vanilla 1.17 being imminent, an update to fix this for future versions would be appreciated.

[KingLemming]

So this is a tricky one because there shouldn't be such a thing as "too early" for fuel values. However, it's entirely possible to be setting them up too late which I suspect is happening here.

Fuel values can and should be set 100% at compile time to allow for proper value caching on datapack reload.

[Juuxel]

@KingLemming That approach sort of breaks when fuel values depend on tags. (Which is also what vanilla does, but not getting to that here)

The original Adorn (on Fabric) used Fabric API's FuelRegistry to register tag-based fuels (so that Adorn blocks, such as sofas, could burn in furnaces). My port of that to Forge is pretty hacky, though. I think the issue here is that TE is loading the fuel values before the tag JSON files are loaded, which would cause the tags to still be unbound and crash.

I suppose I can fix this by just doing it on a class basis instead (for example, instanceof SofaBlock/is SofaBlock instead of #adorn:sofas).

[KingLemming]

That's fair enough, though if it's the case then the issue is when tags process vs recipes, and recipes happen to go first.

[Juuxel]

Yeah, I suspect Mojang just hasn't run across this issue themselves since they lazy-load tags in recipes with ingredients.

[Juuxel]

This has finally been fixed for 1.16.5! The fuel loading will be based on the block class instead if the tags aren't ready for use.