Instance Tagging is now enabled (plus some extras)

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)

5 Likes

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.

3 Likes

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


Instance:IsA(TypeHere)

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.

5 Likes

Instance tagging is really helpful and should be used in places where it can.

Example:
A game I develop utilizes a system where players are able to pick up an object and click the pedestal again to place it back.

To check for when the tool is gone, I have to write long lines of code to accommodate for when the player leaves, health reaches zero or does something else with the tool. Now all I need to do is add a tag and it does everything for me - when the tool is removed from the player’s character via death, removal or leaving, it automatically tells me “instance is gone” and then I can run my functions again to replace it.

(sorry if that was confusing ^ I wrote this while the sky was dark if you know what I mean intensive winking)


Point in case; I love this thing.

To reiterate my reaction, read my earlier post.

2 Likes

Builders do this:


Scripters write this:

local CS = game:GetService("CollectionService")

local function Added(part)
	if not part:IsA("BasePart") then return end
	part.Touched:connect(function(p)
		p:BreakJoints() -- Just a demo
	end)
end

for k,v in pairs(CS:GetTagged("Kill")) do Added(v) end
CS:GetInstanceAddedSignal("Kill"):Connect(Added)

This happens:

Builders just have to use the convenient Studio UI (in this case still the plugin) to add a tag to the part. They don’t need to code, add StringValues named “Kill” or parent the part to Workspace.Kill, they just need to add the Kill tag and bam.

Scripters don’t have to scan through the whole workspace (and listen to DescendantAdded) looking for parts in Workspace.Kill or parts with a StringValue named “Kill” inside or whatever. They just need to use the convenient tag API.

10 Likes

Do the tags only replicate when the instance is fully replicated? This happened in Start Server with 2 players:

(assume Server is just CollectionService on the Server. idem for Player1/Player2)

Server:GetTags(workspace.Part) --> Kill
Player1:GetTags(workspace.Part) --> Kill
Player2:GetTags(workspace.Part) --> Kill

Server:AddTag(workspace.Part,"Server")
Player1:AddTag(workspace.Part,"Player1")
Player2:AddTag(workspace.Part,"Player2")

Server:GetTags(workspace.Part) --> Kill, Server
Player1:GetTags(workspace.Part) --> Kill, Player1
Player2:GetTags(workspace.Part) --> Kill, Player2

-- Server
workspace.Part.Parent = game.ServerStorage
wait(2)
Server:AddTag(workspace.Part,"Replicated?")
workspace.Part.Parent = workspace

Server:GetTags(workspace.Part) --> Kill, Server, Replicated?
Player1:GetTags(workspace.Part) --> Kill, Server, Replicated?
Player2:GetTags(workspace.Part) --> Kill, Server, Replicated?

Seems like they only replicate when the instance fully replicates, not when altered after that. Similar to (the children of) Terrain (unless that changed). I don’t expect Client2Server with FE, but at least Server2Client. (I tested this with FE false, as that’s apparently the default when I create a new place, and didn’t check until after the test)

1 Like

Yeah, this is a currently known bug:

http://devforum.roblox.com/t/collectionservice-failing-to-replicate-tags/46405/3

1 Like

Good point. However, I don’t think there is a need for this API. One can just grab the collection and pass it into the whitelist / blacklist as is (Use the version with IgnoreList). You shouldn’t have to be parenting things right now anyway.

2 Likes

Completely missed the api that retrieves all parts belonging to a tag. Thanks for pointing that out.

1 Like

This actually seems very useful, look forward to using it at some point.

The fix for the replication issues is now live. Tags should replicate properly both in team create and in live games.

9 Likes

Has anyone done performance testing between WhichIsA and OfClass for these API calls?

I’d assume OfClass would be faster as it doesn’t have to check for inheritance.

Yeah, WhichIsA is usually about 5x slower than OfClass

3 Likes

Maybe they should cache those results :thinking:

1 Like

We’re talking about 2.5 µs versus 0.50 µs per call, so there’s probably bigger fish to fry.

3 Likes

Setting the aspect ratio of grid cells was just what we needed, thanks. :slight_smile:

1 Like