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.
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).
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:AddTag(Adornee, "ColorCode: "..newValue.Name)
The code to maintain the second value is pretty trivial, however I would have benefited from this proposal