#Cross-loader common tags convention
3297 messages · Page 4 of 4 (latest)
Sci can't read smh
stop changing history, smh
you have no proof

You can also set a time limit and also allow one person to do multiple votes
you can see who voted on the polls by clicking on the options (at least on mobile)
[Reference to](#1134480199937957969 message) #1134480199937957969 [➤ ](#1134480199937957969 message)oh wait, we can see who voted in the poll
heh
@static scroll The unify PR has a c:hidden_from_recipe_viewers block and item tag. Should the block tag be removed and only keep the item tag? Or is there a reason that the block tga should be kept? I can't find the original convo that sparked the original creation of that tag
nvm found it #1134480199937957969 message
i'm not sure i've ever seen a plugin with a block ingredient
even ones that logically should [e.g. create casings], having them declare the ingredient in item form is better for compatibility since you can find it in usages for the item
what about that mods that does in-world crafting?
the one like anvil falling onto stuff to make new blocks or something
Like I said, there's stuff that logically should use blocks
but the problem is, the palette on the right has only items, so if you right or left click on one, what do you get
in principle there could be extra support on the JEI side, so that it searches for both
block, item, and fluid are all supported
the block tag is used as a forward for items
for easier entry
if you have some existing block tag you want to hide but no item equivalent
It would be nice if Vanilla forwarded block tags to items automatically, but oh well
er, at least for EMI
I would imagine at least item and fluid are also supported for the others
so does having a block in the block tag hide the corresponding BlockItem even if it is not in the item tag? that should probably be stated explicitly in the convention if so
yes
what if wall torches are in the tag and floor torches not
if no equivalent item exists or it's already hidden by another heuristic it's a no op
it's a naive block -> blockitem -> item chain
ok so it's not going item -> block [and therefore potentially ignoring the wall torch]?
implementation is up to the recipe viewers so it wouldn't make sense to have it be in the loader's javadoc
so is implementation of the tag at all :p
I think "recipe viewers should do this, mods can expect recipe viewers to do this" is more or less the entire point of having a standardized convention
implementation of the storage blocks tag is up to mods but that doesn't mean we can't say anything about whether it should include 2x2 or 3x3 recipe blocks
whether that documentation should take the form of a javadoc i don't know, but we should have somewhere to write this stuff down
just by the by, the recipe viewer I'm making makes uses of this quite extensively; block "ingredients" are used to indicate the in-world machine used to craft something, so iron ingots have a dependency on the furnace block for example
huh
JEI calls those catalysts [and uses their item forms]
though immersive engineering somehow fakes it out to allow one that's a full miniature 3D image of the multiblock, idk if that's a fake item or some other thing in the JEI API
Could we add a tag similar to this but to hide structures on minimaps or similar viewers? Jacobjo's map viewer currently uses #c:hide_on_map but it would be useful to include it in the standard
The world preview mod does: https://github.com/caeruleusDraconis/world-preview, as well as my web map. We've agreed on #c:hide_on_map to hide specific structures from both maps in https://github.com/caeruleusDraconis/world-preview/issues/5. The main use case I think are the "z-pointer" structures in terralith, used to create explorer maps pointing to biomes.
Obviously open to better name suggestions.
the name sounds like hiding from vanilla map items which it isnt
perhaps
#c:hide_from_locators
#c:hide_from_displayers
which would cover mods like structure compasses where you dont want structure to be locatable with a modded item. or something like that
#c:hide_from_locators is maybe a bit confusing as they mostly exist to enable locators to biomes. Maybe #c:hide_from_player_selection?
Or more descriptive: #c:technical, #c:invisible, or #c:marker could also work, but that would exclude structures that the modder simply wants to keep hard to find.
I like those. But yeah hidden is better.
added to PRs. Where should I reach out to caeruleusDraconis to let them know of the change. They don't seem to be in this discord. Unless you wanted to let them know about the name change
No idea, I just communicated with them in the one issue.
I'll reply there then

CC @gilded cave, in case you haven't seen yet.
anyone have contact with nature's compass dev? cant find Chaosyr on discord
Otherwise I’ll make issue report to them as well
I think that if we want "hard to find for game balance reasons" in scope we should have difficulty level / rarity tags rather than a simple on/off
thanks for the cc, looks good
I can't imagine much luck getting people to agree which ones or how many should exist lol
That's an unsafe vararg
and to ignore the warning the method needs @SafeVarargs but iirc that anno can only be added to final methods
so not rly usable here unfortunately
This is close to the final hours of the tag PRs. Iirc, fabric will be looking into if it can be merged today or tomorrow (weekend was mentioned before) unless something comes up to delay it
Once fabric is merged, NeoForge is fixed in place too. Then will wait till dust settles with 1.20.5 chaos for people to make issue reports on what needs adjustment or additions. So get in any lookovers now for any typoed or bugs
the changed files is all borked cause the 1.20.5 branch is not in the 1.20.x branch yet 
Should I target the 1.20.5 branch so reviewing is easier
yes 
for anyone reviewing, filter out the json files or else the site lags to hell
Ender pearl tag setup exactly the same as egg tag
The tag for enderpearl is literally blank
But eggs has the value
wtf?
Ran the datagen code and breakpoint hits the enderpearl tag.
Try reading it with cat/type or another editor
I feel like I've seen IJ just see datagen files as empty for some reason a few times before
The game itself when running is also saying the tag is null and unparsable because it has no json inside
Ah ok
Huh deleting the files and rerunning datagen creates them properly...
json fixed now
Last call for Fabric's unify PR
I've been trying to diff the generated json files between the neoforge and fabric PRs, but there seem to be a lot of differences? (Even apart from the obvious inclusion of legacy tags). Am I missing something?
Some tags are niche to the modloader's ecosystem but not specific to the modloader itself.
example
fluid tags aren't used highly on fabric ever
but heavily are on forge
but still good to put under c so if fabric mods slowly changes to using fluid tags, they can add it. But most tech mods that interact with fluids seems to be forge
You can see stark differences in usages here:
https://docs.google.com/spreadsheets/d/1cBSLCHqR1vrqxRZqofeSlHQxgqAjVn9WfT9z-1DGq90/edit#gid=0
https://docs.google.com/spreadsheets/d/1KBn2hKOz3nnIYh3KAeqv5vezMwFSDO-tL8TUAKYTiBE/edit#gid=0
There is also some pre-existing tags that I moved to c to prevent lost of tagging when removed from modloader namespace but was far too niche to carry other to other loader. Like feathers tag in forge that I could not find anyone using similar tags in fabric. The prs isn't perfect but strong starting point with majority of tags (the most useful ones) synced. And more tags/syncing can be done with people making issue reports/prs going forward after this
Ah ok, fair enough. That makes the diffing a bit more diffcult. Just want to double check that the tags that do exist in both are the same contain the same elements.
A list of the diff would help knowing what could have future discussion on if worth generating on other modloader as default. Dunno best way to diff on existence of files
Important diff: Most enchantment tags are plural in fabric but singular in neoforge.
typo in neo
yeah that can be changed
Thats the reason I'm doing the diff right now, to catch those.
fixed and pushed
Should the c:is_ biome tags that mirror minecraft:is_ tags also include the vanilla biomes separately or not? Because that is very somewhat inconsistently done.
it should pull from the vanilla tag unless the vanilla tag is stupid
like vanilla forest tag has grove in it instead of that in taiga tag...
I think I was going off of what fabric might had been doing before. But i can remove the biome entries and just keep the tag mirroring. Unless seeing the vanilla biome entries directly here is preferred while also importing modded entries from the vanilla tag
ehh i'll remove redudant biome entries
yeah having the entries in multiple tags when could just be a tag ref makes it a pain for datapackers imo
gotta remove entry from all tags its ref'd in, not just the vanilla tag and have that inherited up the tree by other tags
remove from vanilla tag i expect the modded variant to inherit the change
not that i have to remove from both vanilla and modded tags
Yeah, very inconsistently done between neoforge and fabric too, but not always in the same direction. I guess that only matters when someone for whatever reason decides to override the vanilla tag to remove biomes.
IT BEGINS
Ok, done with the diff. Found a number of tag content differences, mostly in the biome tags, but also some for items and blocks. Put it in a gist since its somewhat hard to determine which version is the preferred one, so I can't put it into github reviews: https://gist.github.com/jacobsjo/1fcf1d8c64cc8fabf08fb8fab4c09ddc
(For some, it was obvious which is the correct one. For those I left review comments on the relevant PR, and those aren't in the gist above)
try now with the new changes
Looks good, except c:is_tree/coniferous, c:is_tree/savanna and c:is_tree/jungle use the #minecraft: tags instead of the #c: tags in neoforge.
Oh and I think you forgot to add the c:rods/breeze tag to the c:rods tag in neoforge.
addressed now
Can someone update the labels on the PR from 21.0 to 20.5?
convention tags were merged in fabric
when will the neo pr be merged?
Where are the haters that said it wouldnt be merged 😄 /s
Anyway, thanks everyone here for the input on it. I look forward to seeing people benefit from it
hooray
the PR still needs to be rebased on neo
why y'all force pushing so much lol
@cursive surge are you going to force push again for the 1.20.5 branch?
No
This force push was only to rebase it on top of 1.20.4 now that 1.20.4 has been frozen, giving us a nice linear history
sob
net minecraftforge? 🤔
Did you squash your PR before rebasing it?
You'll go insane if you try to rebase 137 commits
i can't squash
Why?
Normally I merge in the parent branch's change into my branch. Not rebase
so it's all messed up if trying to rebase and I don't have much experience with rebasing
i guess this is fabric only atm, but with the new c tags I'm seeing "melee_weapons", "mining_tools", and "ranged_weapons". any reason they don't use the vanilla swords, axe, and pickaxe tags for the former two and why ranged weapons doesn't use the bows and crossbows tag?
make an issue report if you want it to pull from the vanilla tags. But what if someone makes a sword that isn't a melee weapon but shoots fireballs on swings?
that makes it a ranged weapon
that's what we do to keep a linear history 😛
didn't want to make an issue if it wasn't an issue, just wanted to know the reasoning for it 😄 that makes enough sense though, thanks
trying one thing to resolve conflicts on the tag pr
oh uh, let me undo my last commit then to not conflict with you
ok there, back to what it was when you checked it out.
Sorry about that
I'll work on fabric tag translation pr in meantime instead
Can you give me a commit message I should use for this monster? Or are you going to edit it afterwards?
"rebased to 1.20.5"?
My commit messages have been declining in quality as I lose my sanity
o
So rebased to 1.20.5 is definitely not appropriate hehehe
not to mention, I didn't even do that yet. I just squashed your entire work up until now
"Unify tag namespace and conventions between Neoforge and Fabric for 1.20.5 MC"
Body of it can be a link to the 2 PRs:
See PRs for more info
https://github.com/neoforged/NeoForge/pull/135
https://github.com/FabricMC/fabric/pull/3310
nice
I compared the work-tree of that with your original branch and it has no differences
Just to make sure I made no mistakes there
Okay you'll have to do that 😄
Wait no, somethings borked there
Uh you might have merged something into your branch that you maybe didn't intend 😅
The files changed before the monster commit was showing only the files I changed
Okay, I have to re-squash I see. I did that on top of the wrong commit
Okay this looks more like it: https://github.com/shartte/NeoForge/commit/3baf096d9ff396c7bc6dde60eceef56590b40f73
Okay, rebase done. No conflicts
You sure? Files changed is still showing pre-1
https://github.com/neoforged/NeoForge/pull/135
Updated
No conflicts
yeah that looks correct there
Tag Translation PR up for fabric: https://github.com/FabricMC/fabric/pull/3716
Isn't there already a non-generated file?
I'm surprised it runs at all if that's the case
This file is under c namespace. Wouldn’t the non generated one be under NeoForge namespace
Ah true
is 1.20.5 even runnable
trying to run datagen on my tag pr after the squash with 1.20.5 branch
Ah right
I ran setup task and the unpack sources task. Then tried to datagen and got this error
finally able to run
tag PR should be finished now. Tested the warning log stuff and addressed some missing translations. Ready for final review for typoes/issues and can be merged when 1.20.5 branch needs it
i see the PR is including old forge tags... given 1.20.5 is already quite breaking, i'm not so sure if we should
also is it just me or does fabric not have the c:cobblestones folder for blocks
same for chests? 
@dawn nova
Cobblestones can be added to fabric side as another pr but I didn’t find any fabric mod trying to make a similar tag. Seems more forge ecosystem.
And what forge tags are still in
The enderman one? That’s a functional tag that changes gameplay only on forge/neoforge. damagetypes is from shadow’s or and those are more functional as there’s some code backing to them. Like poison potion now uses a custom damage type which is tagged as is poison. And the enchanting fuel is also a functional tag tied to neoforge
All forge convention tags (no functionality mostly) I turned into c namespace.
Chests fabric does have
only chests/wooden, neo has ender and trapped too
Make another fabric pr if need. I think I only saw wooden ever used on fabric
Sheet1
SORTED BY COUNT,SORTED BY NAME,C SORTED BY COUNT,C SORTED BY NAME
tag,count,tag,count,tag,count,tag,count
minecraft:blocks/mineable/pickaxe,129,ad_astra_platform:fluids/biodiesel,1,c:blocks/ores,13,c:blocks/adamantite_blocks,1
minecraft:blocks/mineable/axe,73,ad_astra_platform:fluids/dies...
noticed this in fabric
yeah I dont see ender or trapped here. those tags were pretty much only ever used on forge ecosystem. But can be added to fabric
c:strings contains c:string
the PR is solid foundation and people can make future prs off of it to fix stuff or add or sync. I can fix that one to be pulling in c:string (was supposed to be backwards compat with old tag) Anything else?
oh right, did we end up having a "cheap chests" tag, separate from wooden chests?
no though good luck getting people to agree on what is "cheap". Using the wooden_chest tag should be good enough
fair; my assumption was that anything that is infinitely renewable would've been cheap, so stuff like "cobblestone chests" would count
but yeah, i guess wooden chests would work for the most part
Ik i keep repeating myself but I just want people to know for sure this is not the end of the story for tags. This will forever be an ongoing thing that requires people to keep contibuting and expanding
wooden is fine
and it will be impossible to keep fabric and neoforge perfectly in sync but I don't care 😄
In the absence of a cheap chests tag, yeah, wooden is fine
90% in sync is better than 0%
yeah
review comments are so painful
So I noticed armor tags are absent
There's only the base armor tag, but no tags for individual types of armor (chestplates, boots, etc.)
can't you check if the item fits in an equipment slot?
That would be extremely complex in this case
Though maybe with some rewrites (that are already due in 1.20.5) it could be done
Rewrites using item sub-predicates
Maybe
Actually probably not
Not really, no
without a use case description I can't do anything
My use case is generalized for datapack use
Hardcoding special advancement triggers all over the place for this would make this very messy very fast
vanilla
Ah
https://github.com/misode/mcmeta/blob/data-json/data/minecraft/tags/items/chest_armor.json
https://github.com/misode/mcmeta/blob/data-json/data/minecraft/tags/items/leg_armor.json
https://github.com/misode/mcmeta/blob/data-json/data/minecraft/tags/items/foot_armor.json
https://github.com/misode/mcmeta/blob/data-json/data/minecraft/tags/items/head_armor.json
the c:armors tag is just these collected for ease
https://github.com/TelepathicGrunt/NeoForge/blob/Common-Tags-Refactor/src/generated/resources/data/c/tags/items/armors.json
Unify or on neoforge now merged. Both loaders now has unified c tags
@static scroll the only thing left is fabric to merge tag translation as its own pr. (Neo has translations already now) https://github.com/FabricMC/fabric/pull/3716
i'm half-tempted to give you a "Tag Czar" icon role 
now apply for neo maintainer so you can maintain the tags (/s /s/s/s/s/s/s)
I wonder when it comes to the translations if we might be better off with a unified project that then is packed as a resource pack shipped and enabled by default for both loaders. That way translations people submit don’t have to be manually mirrored between the projects
The bucket tags are missing on NeoForge
Can you please add them?
Specifically these are missing:
#c:buckets/water
#c:buckets/entity_water
#c:buckets/lava
#c:buckets/milk
#c:buckets/empty
yay
no mc tags is probably fine since EMI will translate them
but for the sake of other mods curious what the solution is
@cobalt moon
Iirc, buckets on neoforge got pushback cause neoforge modified the bucket item to hold fluid types
You can make issue report to see if they will change mind and add the bucket tags
what's the difference bet- oh is it an entity in water?
that was my thought too then remember fish in buckets exist in vanilla 
There can be an argument that entity water should be just entity instead
Forgot what I did in fabric. So many tags that i forgot most of them
yeah i'd say either entity or entity_in_water
but w/e if the fabric PR is merged I don't want to hold things up 😛
There’s nothing to hold up anymore. Both loaders have the unify pr merged. Now it’s just up to community to make PRs and issue reports to make adjustments and coordination.
yeah any fluid container holding a fluid and entity could be to that tag tbh
not specific to water, imagine some mod making strider in a bucket, id imagine that would be lava in that case not water
(would we then need c:buckets/entity_lava? with how it currently is)
I don't need specific bucket types btw
I just need a tag with all bucket items
Which I'm currently getting by combining bucket tags in a single tag
does c:buckets not exist?
usually if theres a group, the root exists which contains all the children
looks like it does not exist on fabric, should maybe be added to keep consistency with all other tag groupings
Nope
eh, idk. i've seen a mod that adds a strider lava bucket
fish buckets, importantly, A) require a water bucket to make, and B) place a water source block in the world, along with the entity, when used on dry land.
i've also seen mods that have a bucket that can contain a small slime or a bat with no water
Wait, why is there a meats tag? Vanilla has one
what exactly do you mean
vanilla does not have a raw and cooked meat tag.
it has a general meats tag with both cooked and raw meat https://github.com/misode/mcmeta/blob/data-json/data/minecraft/tags/items/meat.json
the tag prs does not have a c:meats or c:foods/meats. Just the separated cooked and raw variants for ease
@cobalt moon now that the common tags convention has been merged in NeoForge and Fabric, should we start talking on how to ensure both sides are in sync? and write it down, and have both sides agree, so we have a clear path for changes
If someone makes an issue report or pr for new tags, make an issue report or pr on the other loader and see if they like it or if changes should be done or if rejected
Also link the PRs to each other please so that anyone looking into one knows that the other is a thing too, and can easily find it
@cobalt moon Would you be interested in reviewing Forge's impl/port of the common tags once ready?