Instance Tagging is now enabled (plus some extras)

Instance Tagging is a revamp of CollectionService which allows you to add multiple tags to any instance, to query what tags an instance has, and to enumerate all instances in the data model that have a given tag. The tags on each instance are serialized and replicated from server to client like any property would be.

We are planning on adding Studio UI for editing tags, but do not yet have anything. The goal is to make it easier for level builders and scripters to collaborate by making it so the level builders can tag objects like doors, death planes, and moving platforms so scripts can add behaviors to them. The current methods of tagging objects in this way are pretty disappointing, like using magic Name fields, magic StringValues (both of which are easy to typo), LinkedScripts, loader scripts, etc.



There was a bug with this feature in a recent release where code that tried to find child objects named “Tags” would fail because of an unscriptable property. This has now been fixed.

Four new methods on Instance have been enabled:

You can now put constraints inside of GridLayout to change the CellSize.

BillboardGui.MaxDistance is enabled. (It has been for a while, but I never announced it.)


Neat additions. Glad to finally have these around, will be pretty useful; saves us from writing our own functions to perform the same sort of action.

What separates this from Instance:FindFirstChildOfClass()

1 Like

I believe the difference here is that Instance:FindFirstChildOfClass() uses exact ClassName matching, whereas this new method works more like Instance:IsA() (descendant class matching).


IsA allows using abstract classes (such as LuaSourceContainer, GuiObject, BasePart, etc.) where you would have had to specify the exact ClassName

Never even knew this was a proper thing before, really cool. I can think of a lot of use cases for this.


I can say goodbye to my many-line functions and just use these instead. Woo!



Variant<Instance, nil> FindFirstAncestor (
    string className

Description: Returns the first ancestor whose Name is equal to className, or nil if none can be found.

Just by luck, I also saw the intellisense description of FindFirstAncestor in studio yesterday. It also said className in the parameter/description, but I wasn’t sure if that was wrong. Now I’m quite sure that className should be name. This is probably a “typo” from copying stuff from

(it’s actually wrong in the ReflectionMetadata/API Dump/ROBLOX source code, the wiki just copies it)


I was actually about to request this in features lol

1 Like

This is wonderful.

Unscriptable properties can still be identified if you use GetPropertyChangedSignal. Just a side note.

1 Like

They also show up in the API dump, and in tweens, and probably a few other places too. Ideally they would show up nowhere, but at least with this fix they will no longer interfere with child lookups.


Only a select few show up in the API Dump for some reason

1 Like

There is now a plugin for editing CollectionService tags, until there is dedicated Studio UI:


Can we look forward to a FindPartOnRay* function that tests for membership in a tag?

1 Like

I’d really like a filter function that returns a Finished/Unfinished EnumItem to stop the ray when needed. (and since it’ll call the filter for every part, you can get a lot of parts with just one raycast)


This is the better solution.

I’ve been thinking of that for a while. Has there been any comment about how that would be better than implementing that as a module? It would have to execute Lua anyway, after all, so speeding it up with C bindings probably won’t do much (correct me if I’m wrong.) Perhaps a raycast that returns a list of parts up to N parts is more generic?

Anyway, FindPartOnRayWithTagWhite/Blacklist would solve a lot of common problems we have riight now. Projectiles and particle effects made with blocks can be tagged to a blacklist instead of parenting them to a certain folder. Level geometry and characters can be added to a whitelist with tags, as well.


Not really a fan of this to be honest. There are other ways of doing this message such as


Instance tagging isn’t really meant to be a replacement for IsA. Instead of checking to see if a model is a Model, instance tagging is more useful for checking if a model is a “Burnable Object”. There are existing ways to do this, but they have their flaws:

  • Add all burnable objects to a single model - forces you to structure your game a certain way which can be inconvenient, or just not possible if the object is of multiple types (e.g. “Burnable Object” and “Scannable Object”).
  • Manually define all burnable objects - have to also manually update this whenever you add a new object
  • Recurse through the game at runtime to define all burnable objects - can have performance implications and not detect objects added after the game has run

Instance tagging provides an elegant solution to aggregating these objects. In addition, when the Studio UI supports them, they can also be used as custom properties, which will be tremendously helpful when creating models for others to use, whether they be free models or models you make as a programmer for the less-programmaticly-inclined members of your team.