I have a large 1.16.5 (more than 500 mods) private modpack that I play with my friends and brothers. I update the individual mods in the modpack in batches. Everytime I update, I have to do extensive testing because some or even just one of the mods had changed their way of referencing their (or other mods') items/blocks. This then causes a datapack load error on world load. The amount that could have been spent on gameplay is now being taken by just isolating what specific mod causes the datapack load error. It is just annoying that I have to deal with such issues just by maintaining my modpack by updating it to fix bugs we encounter in our gameplay.

Thanks for the reply anyways. The latest.log only shows that it is about a mekanism block tag, But in an isolated test running only mekanism, the error does not show up. From what I can infer is that there must be some mod that modified the tag used by mekanism. This is where my problem begins. Here is a snippet latest.log anyway: https://pastebin.com/CYLg4QJw

I stopped supporting 1.16.5 so there won’t be anymore updates for blame. But why don’t you share your latest.log with blame on about one of those datapack errors as typically, the log should already have info about it.

Sorry for delay. Yeah these tag stuff is not something I can really detect easy. It seems like a mod screwed up their tag and made it require a block that doesn’t exist. And that caused that tag to fail to load which causes other tags that reference that tag to also fail. So it cascades the error throughout.

My guesses as to what mods are responsible are Ore+Grow+EX, Dimensional_Ores-1.16.5-1.0.0.7, ExpandedCombat-1.16.3-1.0.3.3, Clythez's+Tech+Mod+1.16.5+Forge+v1.3.3

Note, some of these might not be these mods but another mod trying to use stuff from the other mods by typoed. There’s also someone trying to shove “minecraft:glow_berries” in a tag even though that’s only a 1.17 item and not in 1.16