Sonnebahn

Tracked it down. Taiga 2 v 0.0.1.1 for MC1.16.5 All of the tag json files have the replace field set to true. I suspect this is accidental, but it means I will have to pull it from my pack till its fixed. I will be notifying them so it can hit their fix list. Thanks again for the assist in getting to the bottom of this issue.

Thank you. I will test the mod combinations and try to track down what is causing it. When I find out what it is I will come back and report so future people running into the problem can see a resolution. 😃

I will attempt to clarify. In the mod Tinker's Construct (TConstruct-1.16.5-3.1.2.265.jar), a new tag forge:ingots/cobalt (cobalt.json) is added, placing tconstruct:cobalt_ingot as a value of the tag. Likewise, a tag not originating with tconstruct is added to forge:ingots (ingots.json). As can be seen in ingots.json, a value of #forge:ingots/cobalt is used to reference the items tagged under forge:ingots/cobalt (i.e. tconstruct:cobalt_ingot). The expected behavior is that tconstruct:cobalt_ingot will have 2 tags - forge:ingots and forge:ingots/cobalt. The actual behavior, viewable in JEI, is only the forge:ingots/cobalt without the forge:ingots tag. With Kubejs installed, when ingots.json is copied to [profile]\kubejs\data\forge\tags\items\ the behavior changes to the expected behavior. This behavior extends to all listed values in the ingots.json file, whether is is explicit (i.e. tconstruct:seared_brick) or tag referenced (i.e. #forge:ingots/cobalt). such behavior points to the ingots.json file within the mod jar being ignored in tag processing, perhaps being flagged as invalid, and being accepted in the datapack directory applied by the Kubejs mod. And while I understand that the tags are collected and processed together, nothing in programming is truly simultaneous, so the ingots.json file inside the mod is somehow being processed before the cobalt.json file and the copied ingots.json is being processed after the cobalt.json file. One order of processing failing to register the items listed and the other order of processing succeeding in processing the items listed. Further, I have observed the same behavior in other mods: create, atum 2, etc. Tinker's Construct came to my attention because the recipe for an ingot cast calls on the tag forge:ingots in the ingredients but fails to show most of the ingots and bricks that can ordinarily be used.

to be thorough I tried this on forge version 36.2.5 with the same results.

Minecraft Version: 1.16.5 Forge Version: 36.2.0 Description of issue: A loaded mod containing data pack tag registries, which creates new tags and references the new tags to further register the items in existing tags fails to register anything in the existing tags. Example: Tinkers Construct v3.1.2.265 contains Json files to register: forge:ingots/cobalt as a new tag containing cobalt_ingot and add to previously registered tag forge:ingots. In the file for forge:ingots, values of "tconstruct:seared_brick", "tconstruct:scorched_brick", "#forge:ingots/copper", "#forge:ingots/cobalt", etc. are indicated. In-game, none of the items listed as values are tagged under forge:ingots, however the new tags including forge:ingots/cobalt include the items tagged in those files. Further, copying the json file for forge:ingots and placing in a later applied datapack, such as Kubejs, and reloading, properly registers the forge:ingots tags. This would appear to be an issue with timing of registering the new tags. Before copying the json file to a datapack, the existing tag (forge:ingots) appears to be handled first, which containing references to new tags that are not yet processed (forge:ingots/cobalt) fails and does not register any of the appended values. But in the second instance because the copied json file is processed after the mod jar file as a whole, the new tags exist and the appending of the new values succeeds. While I have given Tinkers construct as an example I have viewed the same issue with multiple mods, each of which uses references to new tags in an appending of an existing tag. Likewise, mods that do not exhibit this behavior use explicit item listings rather than referencing a new tag. I looked through the log files and did not identify any error or other message relating to the registration of tags in general or specifically these exemplar tags.