This issue is to start some discussion about possibly changing the tag convention used by the ecosystem. I am opening this on Fabric so that the discussion can be public, but the major mods that are concerned are AE2 and MI (myself), Create (@AlphaMode), IR (@notsteven) and TR (@modmuss50), and if we all decide to change convention then the rest of the ecosystem will be forced to adjust.

The idea would be to adopt Forge's convention for tags, but with the c: namespace. So that would be c:ores, c:ores/tin, c:nuggets/copper, etc...

Advantages

• Hierarchical organization. Feels a lot cleaner, especially for people looking into mod jars. Shouldn't matter for mod devs since tags should really be generated via datagen and not written manually.
• Easier multi-platform mods. They would only need to change forge: to c:, but the paths for standard tags could stay the same.

Disadvantages

• Doesn't match the standards established by Mojang. Can be argued that it doesn't matter since this is not vanilla.
• Would require a lot of work to update, which makes this possibly not worth it.

I'm against this change.

• The current "flat" tag system has been widely used for multiple MC versions without any real issues. Most mods won't have so many tags that it's hard to browse the tag list. Mods with that many will most likely generate them and not touch them by hand at all.
• It's also quite widely adopted by mods that aren't one of the large tech mods mentioned - even simple mods like Adorn might use tags like c:wooden_chests - that would be changed by this move - pretty widely in recipes.
• It might be a bit confusing to have e.g. c:ores/tin but minecraft:iron_ores - we should match the vanilla convention where there's a clear one like with ores.
• Multiplatform mods have to change the ids anyway, so change of namespace vs change of file name is not that much different. (Especially if mods generate the tags like you recommend)
• We don't need to copy-paste Forge's decisions for the sake of matching Forge.

Can’t mods just mirror tags into a new tag system with directories if they want it organized that much?

Imo a tag unification system, where two ids, such as c:tin_ores and forge:ores/tin can be merged to refer to the same tag (instead of one contained in the other), would be a better solution.

I opened this to spark some discussion. I agree with @Juuxel's points.

This shit can be done with datapacks… does it really matter?

first to oppose juuxels points

• it doesn't have issues in use, this is purely better for devs, specifically datapack devs or mod devs that don't do datagen
• c:wooden_chests is not a "material" tag, it should actually stay the same.
• minecraft:iron_ores is not a material tag, its the exact same as minecraft:chests, it isn't really designed for mods and modpacks with hundreds of materials.
• i don't think ease of porting from forge was ever a point for anyone
• i don't think there's a reason to match forge, but flattened directories are not good, if there was a fabric version that didn't cause hundreds upons hundreds of jsons to be in a single location, i think it would be just as valid

to oppose the disadvantages tech has stated

• mojang doesn't have a material standard at all, none of the items have tags, it's a stretch that has created this standard
• the work to update depends on how it's done in each mod, i already made a fork of MI that has it just to see if it was that hard, and honestly, you can always use a mod or a script to convert the tags until there is a shift, or in fact to my next point

https://github.com/gudenau/minecraft-tagAlias
mod that allows tags to be aliased, i don't know how finished it is but it does exist

the advantages are that it's cleaner, easier to manage, and even more readable, because the current standard has some pretty terrible things like c:raw_iron_ores, c:steel_rod_magnetics or c:emerald_small_dusts the separation and order from what material it is, and what it is is almost non existent, using / means you know the separation, for most mods this doesn't matter at all but if it ever does, it's a big deal.

on top of which current mods like create, and more upcoming mods are going to use this standard, so more than likely a divide is going to be created, so there needs to be a solution, other than telling people to follow the current standard when there are so many flaws with it.

For AE2 I am considering using some automatic "ore dictionary"-like tag detection to support item substitutions without requiring users to select a tag, based on a similar system used by Mekanism.

(On Forge) Mekanism has a prefix whitelist that they use to detect such tags, i.e. forge:ingots/*, forge:ores/*, forge:dusts/*, forge:nuggets/*, and forge:storage_blocks/* by default. Using a similar system on Fabric might lead to issues because doing some naive pattern matching on the tags could return wrong results. I haven't tried implementing this yet, so I don't know. This is also not a commitment from my side to move to another convention, just something I noticed.

Also note that the following folder is quite unreadable for anyone browsing through the github files: https://github.com/AztechMC/Modern-Industrialization/tree/master/src/generated/resources/data/c/tags/items.

A tag aliasing system might be a interim good solution in case we need more time to decide on this issue.

For AE2 I am considering using some automatic "ore dictionary"-like tag detection to support item substitutions without requiring users to select a tag, based on a similar system used by Mekanism.

(On Forge) Mekanism has a prefix whitelist that they use to detect such tags, i.e. forge:ingots/*, forge:ores/*, forge:dusts/*, forge:nuggets/*, and forge:storage_blocks/* by default. Using a similar system on Fabric might lead to issues because doing some naive pattern matching on the tags could return wrong results. I haven't tried implementing this yet, so I don't know. This is also not a commitment from my side to move to another convention, just something I noticed.

Also note that the following folder is quite unreadable for anyone browsing through the github files: https://github.com/AztechMC/Modern-Industrialization/tree/master/src/generated/resources/data/c/tags/items.

A tag aliasing system might be a interim good solution in case we need more time to decide on this issue.

yeah that's exactly what i'm talking about, i get the standard is a standard, but this really does make things more manageable, and some other systems like kubejs unification able to be simplified more, even if we have to use tag aliases for awhile to transition, to me it's worth while overall because of this

This shit can be done with datapacks… does it really matter?

Sure you can duplicate all of the tags, but that's not a good fix.

Are the current tag conventions published anywhere, btw? Currently things are a bit of a decentralized mess, and I know of a few mods that intentionally register their blocks to duplicate tags (like c:glass_pane and c:glass_panes) because some mods use the "wrong" convention but which one is the right convention anyway.

Idrc lol, any tags are fine w/me. As long as they work with KJS

@quat1024 Tags should be plural. For this example, it is c:glass_panes, as can be found in the convention tags module.

After more discussions it's become pretty clear that the current convention is not going to change.