I was kinda expecting Object.Attribute instead of always using :GetAttribute() but o well
I can’t see it in the documentation but attributes can have object values right?
1 Like
I didn’t realize you still have to use functions to get/set attribute values 
This is cool, but I’m tempted to keep using ObjectValues.
Edit: Actually, using ObjectValues really floods the Explorer window. I could see why you’d use this instead.
-
As of release we support nil, boolean, string, number, Vector2, Vector3, UDim, UDim2, Rect2D, NumberRange, NumberSequence, ColorSequence, Color3, and BrickColor.
-
Attributes are replicated the same way we replicate properties, so changing one attribute on the server won’t affect other attributes on the client.
3 Likes
I agree with @dispeller since I would rather do Object.IntValue.Value instead of Object:GetAttribute()
But I’m pretty sure properties replicated from Server to client. You mean changing on the client won’t affect the server?
I included some stats in the beta release post:
6 Likes
I don’t think this is meant to replace object values, it’s just an alternative.
Sometimes having too many ObjectValues can be overwhelming to scroll through. This makes things a lot neater.
oh i guess it’s a lot faster
Hmm true but scrolling down the properties menu will be a pain aswell, also object values can be “sorted” into folders, Although the performance of it might be worth it
1 Like
This is actually a great use-case for attributes! In our testing, we often replaced a traditional debounce by assigning a temporary attribute to an instance.
-- LavaPart.lua
part.Touched:Connect(function (hit)
local humanoid = hit.Parent:FindFirstChildWhichIsA("Humanoid")
if humanoid then
if humanoid:GetAttribute("DealingDamage") then
return
end
humanoid:SetAttribute("DealingDamage", true)
humanoid:TakeDamage(part:GetAttribute("Damage"))
wait(0.1)
humanoid:SetAttribute("DealingDamage", nil)
end
end)
11 Likes
Submit a feature request! 
3 Likes
Check out my previous reply 
3 Likes
Yo that makes a lot more sense. I guess it’d be pretty inefficient to create entire ObjectValues for something like a debounce.
Attributes aren’t really added or removed, they just change value where nil is the default (similar to Lua tables). Therefore, you would use AttributeChanged to listen to added and removed events; comparing the last value to the new one.
cc @pa00
5 Likes
This was referring to a very specific case with tags. When you change the tags the instance has on the server, the client loses any additional tags they’ve also added. This isn’t the case with attributes.
4 Likes
This is awesome, time to use these new buddies.
“S ame”
- Ubisoft
(btw im happy bout that)
wait hold up
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.
I think there are some issues with the code snippet on GetAttributes.
- The variable on line 1 does not have closing brackets on GetAttributes()
- instance:GetAttributes() is repeated on line 2 even though there is a variable for it on line 1.
But GREAT FEATURE! I shall make a video on this shortly.
16 Likes
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.
4 Likes
Oh right!
I totally forgot tags were just booleans
1 Like
THIS. IS. AWESOME! Will be useful for making a gun system, or even making a car faster! Really cool, nice.
1 Like