Tags don’t replicate to the server, only from. Checking them client side is not an issue.
1 Like
Tags can be added by the Server and the Client, but only server-made ones will replicate to all clients meaning that you could and should use a LocalScript for GUI tagging since they can only be seen and accessed by a specific client.
This is the replication scheme:
Server → :AddTag() → Tag is added → Tag replicates to other clients
Client → :AddTag() → Tag is added
Server-made tags can be accessed by: Server, Client, Other Clients
Client-made tags can be accessed by: Client
It would, but only for the client that was in control or had ownership of the LocalScript. In that case, the client would see them as tagged bricks and would die if it was to touch them, but other players would not die since they won’t even see the tag in a first place.
3 Likes
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.