How is this any better than using Tags with CollectionService?
Is it just that you don’t have to use CollectionService now?
local CollectionService = game:GetService("CollectionService")
-- LavaPart.lua
part.Touched:Connect(function (hit)
local humanoid = hit.Parent:FindFirstChildWhichIsA("Humanoid")
if humanoid then
if CollectionService:HasTag(humanoid,"DealingDamage") then
return
end
CollectionService:AddTag(humanoid,"DealingDamage")
humanoid:TakeDamage(part:GetAttribute("Damage"))
wait(0.1)
CollectionService:RemoveTag(humanoid,"DealingDamage")
end
end)
Edit:
It’s different because CollectionService only allows you to store booleans on objects.
For any example using booleans, you could also use CollectionService. However, if you wanted to store additional data (such as the amount of damage being dealt) then you would use attributes.
Thank you for your hard work so far, I am sure a lot of Developers will appreciate this new Functionality, ValueBases are really clunky but they served us well.
I definitely need Instance and Table type support for what I am doing (if you want to know more ask) simple explanation, I would like to use Attributes for sharing Data between Server and Client when using Remotes aren’t the best option, but to do that I need Instance and Table type support.
@WallsAreForClimbing Is there a release date on support for new types, an estimate is fine I understand how things might not go as planned, but I would be grateful to know when I can expect this to roll out so I can decide what I should be working on.
Just to clarify CollectionService behaves like this
first Client AddTag B to Instance
then Server AddTag A to Instance
now Tag A exist but not B
This won’t happen for Attributes right?
Properties are predetermined and they can’t be removed, so I wasn’t sure if Attributes would be like Properties or Collection Tags
You should definitely put this in the OP so people don’t ask already answered questions
Very useful update, I see it’s very welcomed by the community however, I find it hard to get the value of an attribute or set it through a function that has 12+ characters, it also affects code readability. At this point I see no difference between using a DataValue and an Attribute since they are pretty much having the same concept, and none of them give me it doesn’t give me any reason to use it on top of a DataValue. The only advantage to use an Attribute is likely the memory usage which I am not too sure about.
are they going to add an ‘Instance’ type cause I was testing with it and there seems to be no ‘Instance/Object’ type and would it function similar to an ‘ObjectValue’.
Using Attributes I believe are better than physical Value objects, but also if you want to store values inside module scripts, that’s either as good as attributes or better, I just looked at other replies
Thank goodness they’re live now, I had made/scripted some assets for a group game that make use of them and was slightly concerned that once they’re done that I would have to wait before using them.
Giving custom properties to complex models, more memory efficient, not having to put everything in modules (you can now set the values in studio and preview them), not requiring any value objects that make stuff look crowded and messy and need an additional “MyValue.Value” to read/write to them.
I’m surprised they haven’t added this one. ObjectValues are one of the most important values in my game and I was excited to adapt them into attributes.
Don’t think you can store a table/dictionary in a attribute.
You can JSON encode a table though and save it in a string attribute or create a empty folder/model object and use every attribute as an key - value so the object on it’s own is a table?
