Is there any logic to how /data get entity ENTITY Tags sorts the tags? I see that doing /tag ENTITY list sorts it alphabetically, but the /data command doesn't.
#Data tags ordering logic?
toxic canyon
sudden summitBOT
Is there any logic to how ``/data get entity ENTITY Tags`` sorts the tags? I see...
<@&1201956957406109788>
elder loom
in nbt data tags are just stored as an array, so they're left in the order they were added in that case
actually testing now that seems to be incorrect, tag <entity> add doesn't seem to just append to the list, so i guess i'm not sure what the order is.
it seems like there's some sort of internal logic to the placement but i'm not clear on how it works. regardless the answer to your actual question is still that /data just lists them in whatever order they're stored on the entity
strong heron
I've always treated it as random. Why do you care about the order of tags?
toxic canyon
It'll make my life a whole lot easier to access Tags[X] then to create and maintain a separate data holder entity/system
But yeah it does seem random.
strong heron
what are you doing that you want to store tags externally?
fallow plume
probably the wrong stuff. Yes tags are faster than nbt checks, but if you have this many tags and you don't know the names you are using the wrong construct anyway. use custom_data if you do not actually use tags to GROUP entities.
much likes the tags folder the entity tag list is meant for GROUPING not for marking individual entities.
hushed stone
Scoreboard tags are certainly for marking individual entities
fallow plume
in programming, a tag is used for grouping things, not making things unique, if uniquesness is what you strive for we already have a system for that it is called a UUID
hushed stone
OK, well scoreboard tags do not have that limitation in practical Minecraft Data Pack applications
You can tag something with a unique tag and reliably use it to find that entity, and that's not only acceptable but optimal.
It's also not really relevant to this thread
fallow plume
tags are not unique, so you never have uniqueness guarantees. bad practice and bad idea.
thin bone
tags are not unique, so you never have uniqueness guarantees. bad practice and b...
If you have no idea what you're talking about, just be silent.
If you only give a single entity a tag, it is unique and can unmistakenly be identified, which is 100% reliable.
and one of the intended use cases for tags.
strong heron
But it doesn't make sense to procedurally generate tags for an id system
All tags should be hardcoded
hushed stone
We don't know that that's what's desired
The OPs actual goal is extremely unclear
But I agree that would be true, using a scoreboard id system is better for that. It just has nothing to do with the completely inane argument that tags shouldn't be used to identify unique entities at all
Which doesn't require procedurally generated tags
fallow plume
Insanity would be to claim tags are good for uniquely identifying a lot of entities. Again they are for grouping behaviors with scoreboards among other things. An item, function, block tag doesn't identify a single item, function, block either. It is not design intent and if it happens to work it is more likely to be due to unrelated causes than because tags are the answer. The game runs on UUIDs for a reason.
thin bone
Insanity would be to claim tags are good for uniquely identifying a lot of entit...
I think you are talking about a completely different tag than we are
elder loom
your definitions of "unique entity" and "grouping entities" are incompatible, which is why you're disagreeing. as far as i can tell, "unique entity" as kano is describing it seems to be identical to "grouped behaviors" as you're describing them. either way, this discussion shouldn't be continued in this thread