A new property for Instances called “Tag” would be nice,
would be a Read and Write property,would also be used to Identify what type of object it is by the developer.
Whats the difference between this and “Name” or “ClassName”?
Well first off ClassName says what type of object it is. Name, well its the objects name.
Not convinced, what would it be used for?
For an example, each player model in workspace you can assign a Tag as “Player” in that model’s property. You obvioulsy cannot change the of the model name to “Player”
Another Example: If you have Static Items in your game you can give them all a Tag of “Static” ( Items can be anchored but they would they could still move, this example means they would never move )
Once you assign a tag to something you can then easily find the types of objects with a certain tag by for example: workspace:FindAllWithTag()
this’d be really helpful and has proven to be helpful in Unity, so I thought to suggest it here
This could be pretty useful.
As stated before Unity implements this and it can provide more user control in how we define instances in our game. This higher level of abstraction can make things more maintainable.
This seems like a really weird solution. Tags are essentially properties added onto objects, so I don’t know why we wouldn’t just completely address the issue the first time around and make user-defined classes possible on ROBLOX without needing to hack around with tables that aren’t actually instances.
I find tags super useful in Unity and always love being able to use them to find objects I need easily. I Would definitely like to see something like this and have dozens of uses for it…
Tags are completely backwards from what ROBLOX currently uses. There’s not Instance:FindAllWithTag(“Poses”) – there’s keyframe:GetPoses(). Specific classes or services provide functions relevant to that class/service instead of throwing everything in Instance (that’s the whole point of classes). The “weird” part of the solution I mentioned is having a generic function to find stuff instead of assigning that responsibility to a relevant, user-defined class/service.
Really no difference here. Something like keyframe:GetPoses() is super specific to that object. FindAllWithTag is pretty universal and can apply to the children of any instance.
This would add extra memory overhead to every single instance in every single game. I don’t think it’s a good idea
Consider grouping similar objects in a folder, use StringValues, or store a reference to them in Lua.
You say Unity uses this. Does it ever have problems with two different scripts fighting over the use of ‘tag?’ I would imagine if two scripts are designed by two different people & they both use tag, things will fail miserably.
I remember back when I was programming long, long ago, I used Visual Basic 6 which had a tag property for everything. I recall making it a comma-delimited string so that I could throw more data in there. That sort of usage would probably want to be avoided because it’s unnecessarily complex & would totally ruin FindAllWithTag. However, at the time, I needed multiple things to share Tag, so I did what I had to do. I imagine people on ROBLOX would do the same.
However, I might look into solutions which you as a user can implement.
A solid plugin would be a “tag editor” which allows you to add custom properties to parts. These are stored in a StringValue named “Tags” which is a child. In code, you could require a module script which can be queried to return a list of all elements with that tag. The goal would then be allowing an unlimited number of “tag” properties & to keep them distinct.
Creating a plugin which satisfies a need & proving this is a good feature is a step toward convincing the devs it’s worthwhile to implement their own solution.
Let’s think this logic through for a second. If you know a Model is a Players character, so that you can give it the tag “Player”, then you don’t need the tag in the first place because you already know it’s the players character. Same with normal instances, only instead of you grouping them under folders or Models and labeling the model name what you’re doing is adding Memory overhead to every instance in a game.
Pre-made assets you would know are of a certain type and can be parented to models accordingly, and anything you COULD tag something specific, you already know what it is, and can store it in a Lua table. The only difference is that your suggestion adds memory overhead.
I’m all for a tag system as I’ve had quite a few situations in which it would have made development a lot easier. However, if we were to get a way to tag objects, I think a seperate Tag instance would be most in line with how things are currently implemented. It would basically hold a ‘table’ property you can add values to (or remove from). Unfortunately you’d have to either give every single instance a method to look for tags within that hierarchy or give ‘game’ a method to do that (which doesn’t sound logical) or you’d need a new Service for it, which doesn’t sound great either. Anyways, it’s up to the engineers though so I shouldn’t really be talking about implementation methods.
Unfortunately it’s not always possible to set up a perfect hierarchy to fix these problems. There’s always only a single path to from ‘game’ to a certain instance. Instances never fit into multiple places in the hierarchy even though they might have multiple roles.
Let’s say you are making a first person shooter and you want bullets to go through a tree’s leaves. You also want individual trees to fall over when a vehicle hits it with too much power. What will you do? Will you group all leaves together as an ignorelist for raycasting? In that case, how will you figure out which leaves belong to which tree when a tree is falling over? With a tag system you can just tag them as ‘Leaves’ and suddenly you don’t have to group all leaves together anymore, making it easy to identify each tree individually.
This is just one example though. I can name way more situations in which a tag system would be great because setting up the correct hierarchy is too difficult/illogical if not impossible.
Sometimes, yes, but often not. I should have mentioned that assets don’t just serve one or more unique roles. Instead there can be multiple different assets which have overlapping roles. Let’s take a typical RPG as an example. Monsters often won’t stand still waiting for a player to approach them. They will often randomly wander around a bit every few seconds. NPCs will often also wander around a bit. They might both share that specific behavior, but the NPC and monster both also have other different behaviors/roles, so they would need different names in that case (even though they share similarities). With a tag system you could assign a ‘Wandering’ and ‘Hostile’ tag to the monster and a ‘Wandering’ and ‘NPC’ tag to the NPC. In that case you also wouldn’t have to write overlapping code for the ‘Wandering’ behavior.
Also, naming every instance by their role can make navigating the game’s hierarchy during development really confusing. The ‘Name’ property is, as the wiki calls it “A non-unique identifier for the object.”. Naming everything according to their role isn’t descriptive for what an asset actually is. Most people wouldn’t call every NPC in their game ‘NPC’, you would give them real names so you can distinguish between them.
Shouldn’t be too big of an issue since I imagine 3rd party scripts usually don’t use tags or they allow the player to define them as most scripts lets player define parameters in the properties panel.
To other posts:
Names are object specific.
Tags are category specific.
A Tag is a word which you link to one or more GameObjects. For instance, you might define “Player” and “Enemy” Tags for player-controlled characters and non-player characters respectively; a “Collectable” Tag could be defined for items the player can collect in the Scene; and so on. Clearly, Tags are intended to identify GameObjects for scripting purposes. We can use them to write script code to find a GameObject by looking for any object that contains our desired Tag. This is achieved using the GameObject.FindWithTag() function.
Games with complex or different Hierarchy’s would benefit from this.
Lets not talk about how big this memory ‘overhead’ is unless a ROBLOX engineer can comment on the impact it has. Everything has some kind of hit on the performance of the overall program but the actual impact depending on implementation may not be as big as people make it out to be.