CollectionService – Track all tags in the place

Feature Requests Engine Features
#1

As a Roblox developer, it is currently too hard to get and track all the tags in a place. This is needed for tag editing plugins.

There are no methods to get every tag in the game. There are also no events to track when new tags are created, or when a tag no longer exists in the game.

What I need to do:

  • Get every tag in a place
  • Track when new tags are added
  • Track when a tag is removed

In order to do this for the whole place, I must:

  • Use :GetTags() on every object in the game
  • Keep track of plugin created tags manually. Its impossible to know when other tags are created without constantly looping through ever object in the game.

Neither of these options are performance friendly.

If Roblox is able to address my issue, I would be able to write much more performant code to track all tags in the game, such as tag editor plugins.

7 Likes
#2

It would also be nice if Studio just had visible tags in the properties window or something like that. And a visual for collisiongroups. And we could filter the explorer for certain tags :)!

4 Likes
#3

Thankfully this is currently planned! In that post, there’s also a link to a plugin to edit tags with a graphical interface until official Studio UI is implemented.

2 Likes
#4

In my original tags plugin I keep track of the tags by maintaining a list of them (which is saved with the place file) that requires user action to add to the list. I don’t really see too much of a problem with this. It’s kind of nice because if you use some internal tags for bookkeeping in your scripts, having the plugin open while in play solo won’t highlight all these random parts that have bookkeeping tags.

I could create a proposal for this API, but it takes a good reason why we should add it in order for it to be accepted. Is this only useful for plugins? What are the disadvantages of tracking the tags manually like I described?

Relatedly (but off topic from the OP), I’m wondering if there are any other API additions we might consider for CollectionService.

Here’s one I’ve been thinking of:

Variant CollectionService:GetTagValue(Instance instance, string tag)
void CollectionService:SetTagValue(Instance instance, string tag, Variant value)
Event CollectionService:GetTagValueChangedSignal(Instance instance, string tag)

It would be neat to collect some use cases for that. It would probably be limited to the same inputs as HttpService:JSONEncode (basic tables, no mixed keys, no instances / other non-primitive types, strict tree structure).

4 Likes
#5

I could have used something like this a few days ago

pictured I have a door with a color based configuration menu.

In order to do this, I marked the door with a ColorSensitive tag to tell my editor to listen for color changes and update the model visually to react. I use a ColorSenstive tag because this behavior will also extend to switches and other mechanisms.

Doors of a matching color will connect to each other, so in order to accomplish this, I create a second ColorCode: <ColorName> tag so that it may be identified with its matching pair.

--purge other color codes
for _, tagName in pairs(CollectionService:GetTags(Adornee)) do
	if string.sub(tagName, 1, 11) == "ColorCode: " then
		CollectionService:RemoveTag(Adornee, tagName)
	end
end
CollectionService:AddTag(Adornee, "ColorCode: "..newValue.Name)

The code to maintain the second value is pretty trivial, however I would have benefited from this proposal

#6

Why not just use the color in the door, use a value object, or use a Lua table mapping doors to their colors? What about this scenario made you think the best solution was to store data in tag names?