I would add, for security of our games, be very careful what you let the client monitor with regards to tags. For example, I add a GUID tag to all spawned items to prevent duplication, but only the server can see or access the master list.
1 Like
Got it! That clears a lot up for me. I’ll go ahead and try it now. Thanks for the explanation!
So I tried setting this up with a local script, but can’t get a gui button connected via tags. I am trying this out on a blank baseplate. The structure I am trying to replace is below. This works to print the local player’s name when the button is pressed.
The new structure with CollectionService is:
When I implement this structure, everything is printed (including the last print("Connected), but the button.Activated event does not work. Nothing happens when I press the button. Is this the correct implementation of the CollectionService?
EDIT: Also the ScreenGui is tagged with the TagEditor plugin like this:
Well, in that case the CollectionService implementation seems correct and I don’t really see why that could be happening, but definitely check out the button and its properties or try to use other event, maybe adding the function in the same for loop?
Does not look as a CollectionService issue.
1 Like
I see, thanks! I got it to work by just adding a wait(1) at the beginning of the local script. So you’re right, no CollectionService issue.
I found it for you! The local GUIService runs before LocalPlayer. You need to modify your code a little to remove the wait.
1 Like
Thanks! Fixed it with the documentation you linked to. Looks like the text button was loading after the connection was made. I just had to add this line to fix the issue:
game:GetService(‘Players’).LocalPlayer:WaitForChild(‘PlayerGui’):WaitForChild(‘ScreenGui’)
2 Likes
Still helps even after many years! Thank you! 
1 Like
you should probably update the ‘tag editor’ section
since roblox has added the plugin into ‘View’
also, you’re able to enable a beta feature allowing to manage tags within properties
Yeah! I’m aware of CollectionService having received some good additions since this post was made and trust me, this guide is going to updated. However, I have no time yet.
Can’t you just store the parts into a folder, then use :GetChildren() to then run scripts on all of those parts? The folder itself can be a “tag”.
1 Like
Yes, but using that method, you would essentially “lock” the objects under that particular folder and can’t place them anywhere else
2 Likes
Try naming them to something specific, so you can then do workspace:GetDescendants() and then search for those names?
But why would you want to do that over using tags? That still doesn’t fix the issue of being unable to move them and having them attached to specific objects
2 Likes
That is a bad idea, What if you want to do it in different parents?
necro but i think it’s worth adding a small correction for anyone following along in april 2024 onward:
when creating your instances be sure to parent them to the DataModel to prevent issues with :GetTagged() later on
local CollectionService = game:GetService("CollectionService")
--The service we're going to use
local instance0 = Instance.new("Part")
instance0.Name = "instance0"
instance0.Parent = game.Workspace -- these two lines
local instance1 = Instance.new("Folder")
instance1.Name = "instance1"
instance1.Parent = game.Workspace -- right here
-- The instances we're going to work with, a part and a folder,
-- remember that any instance can be tagged.
quote from the official CollectionService docs:
This method [GetTagged] does not guarantee any ordering of the returned objects. Additionally, it is possible that objects can have the given tag assigned to them, but not be a descendant of the DataModel, i.e. its parent is nil. This method will not return such objects.
i could then follow along with the rest of the tutorial without any further issues thankfully. though the Tag Editor plugin doesn’t seem necessary anymore with studio’s built in tagging system being present (likely added some time after this guide)
there might be another more modern CollectionServices tutorial, but this is the one i found and it’s been incredibly helpful, thanks for the guide 
1 Like
Yup!
Some things have quite changed since the writing of this tutorial. CollectionService is more tricky now although we have better tools to work with it. Maybe, I’ll rewrite this tutorial to include updates; sadly, I’m not really motivated lately to do so.
To summarize a little bit what’s new:
- What @LittleWorlds has mentioned is true and a real trap that can result in hours of pointless debugging not knowing where the issue comes from, be aware of how tags replicate.
- Roblox has released its own Tag Editor. I haven’t used it, I prefer writing tags manually, but you should give it a try.
- Amazing tools have been released with the goal of turning tags into (probably) what Roblox wanted them to be: entities and components (being these last ones: the tags together with the attributes). Check out RbxObservers, an amazing library by @sleitnick that takes tags (and attributes) to the next level.
1 Like
Then you change it? I don’t see any reason to not update your scripts after changing the instance’s parents.
I know you said you’d advise this method over for loop functions. But my solution has always been to put the bricks I want to affect with a script in a folder and iterate through that, and not how you described. My main question is however performance. Is collectionservice more efficient than the for loop function method in a situation where I’m using 1000 bricks to do the same thing?
Doing that or using CollectionService is the same performance-wise. Now, the main purpose of CollectionService is offering a more “global” way of accessing instances.
Using tags enables you to retrieve your bricks from any script without referring to the folder itself and makes it possible to add new instances without having them be part of the container which allows for a more free approach to structuring your game.
1 Like