Yeah that’s what I wanted to know. The performance improvements with value objects was pretty extreme, not minor, so I wasn’t sure how much that changed here.
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?
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.
I agree with @dispeller since I would rather do
Object.IntValue.Value instead of
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:
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
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)
Submit a feature request!
Check out my previous reply
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.
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.
This is awesome, time to use these new buddies.
(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)
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.
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.
I totally forgot tags were just booleans