Smelting/blasting recipes use Forge tags instead of mod tags
SatDog92 opened this issue ยท 5 comments
General Information
Describe the bug:
There seems to be a conflict with SimpleOres mod (but it might be with other mods as well, not sure), where smelting an ore from the latter will result in obtaining an ingot from MysticalWorld. It looks like the MysticalWorld's tin and copper ingots can't differentiate between the two ores from their respective ores, it's also shown from the Recipe of these ingots, resulting in either ore of the "same" type being smelted into the same ingot from Mystical World. Viewing the recipe files, it looks like that the line ""tag": "forge:ores/copper" is equal to the one found in SimpleOres, so i just feel appropriate to report that these two tags go in conflict with mods with the same tags, maybe, for example, renaming "ores/copper". with "ores/my_copper" and applying the same thing to other mods might do it?
Edit: Now that i think about it, the Amethyst has the same issue with mods that uses the same tag for recipes.
To Reproduce:
- Smelt a tin or copper ore from either mods.
- Result will always be ore from MysticalWorld
Expected behavior:
I expect the different ores to smelt their respective ingots.
Environment Versions
1.14.4 Forge 28.1.90, Optifine HD U F4
Mystic Mods Versions
- MysticalLib: 1.14.4 1.7.0
- MysticalWorld: 1.14.4 1.6.9
Other Versions:
- Conflicting mod: SimpleOres 1.14.4 2.0.6.0
- Other mods you think could cause issues:
Logging Information
None
Additional Information
https://i.imgur.com/nZH8I9l.png
Additional context (optional):
None
Edits: some corrections and specifications.
You can use a datapack to change the smelting recipes to be mod-specific if you so desire, but the standard pattern for adding smelting and blasting recipes is to use the relevant Forge tag (as far as I can tell), and this was the standard for 1.12.2 also, so I believe that's what we did.
I'll have a think and consult with EpicSquid about this on which approach to go with here...
im not certain how this is a problem or unintended.
do any problems arise from the ores coming up with the same kind of ingot?
im not certain how this is a problem or unintended.
do any problems arise from the ores coming up with the same kind of ingot?
Not sure but might be possible if these mods use the same tags from Mystical Lib: for example, i don't have another mod with another Lead ore, but if i did then there might be the same problem. As i reported in my OP edit, the Amethyst has the same issue with ExtraGems.
Definitely unintended, though. I think it would be great if every mod had its own tags.
Well, i've quite learned a few things about forge tags now. But not sure how they're any practical. Maybe they sound handy but it seems it can cause conflicts, but that's just my opinion.
I'm ashamed to say that i have barely an idea of how to make datapacks that edit certain mods so i edited the recipes file directly in order to fix this (there seems to be a conflict with other mods as well but since the recipes of this one uses mod tags instead of forge ones, and it's the other mods that use the latter, i had to edit the recipes of these latter mods in order to remove conflicts. Regarding these other conflicts i might contact the other modders since it doesn't seem to depend for this one mod this time), but i also believe making it a permanent change for the mod might save a few headcaches, but that's just my opinion as well, i hope it's shared.
One thing someone might wonder: why would you have two copper versions? Simple, even if in the files it's still copper, i might edit one or another in order to change its appearence (for example, copper becomes pyrite). But don't worry, it's just for personal use only.
I also have another questions, unrelated to this specific issue: what about the mod structures? Do they spawn at all? I know for a fact they do in the old 1.12 version but i'm not sure about this one.
edits: few clarifications.
I think your use case is on the extreme edges of something that I'd be willing to spend time rewriting the code just to support; you certainly are the first person to complain about it, but if more people start raising it as an issue, I'm willing to take another look. It might save you a "few headaches", but at this point in time it's performing the behaviour that I (and others I know) expect it to perform.
Regarding data packs, I would start googling on how to make a data pack, and then use the recipes found in the GitHub repository as the starting point for how to edit them. You can see the list of tags and the recipes in the generated resources folder.
Finally, structures don't currently spawn.