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: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.
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.
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.
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)
Yeah, this is a currently known bug:
http://devforum.roblox.com/t/collectionservice-failing-to-replicate-tags/46405/3
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.
Completely missed the api that retrieves all parts belonging to a tag. Thanks for pointing that out.
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.
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
Maybe they should cache those results
We’re talking about 2.5 µs versus 0.50 µs per call, so there’s probably bigger fish to fry.
Setting the aspect ratio of grid cells was just what we needed, thanks.