Attributes - Now Available!

According to a quick test Attributes are about 13% averagely faster than ValueObjects(Tested using String Value Object and String Attribute) according to test done by using 3 value objects and 3 attributes of which all there values are set randomly between 1 and 90 using math.random.image

However it seems number value objects are alot faster than number attributes by 47%. Im not sure why but i’ve tested multiple times again following the same 3 rule 3 rule method.


If a part’s physics is being manipulated by the client will the attributes also replicate from client to server? For instance, the player’s character is almost always being controlled by the client. If an attribute is added to the Head part will it replicate all changes and additions to the server?


can we now get a visual scripter in the nearish future???

it’s about the size as other software

O… M… G… They are finally here!

This is by far one of the best updates ever. No more clutter in your models!

Some features that I want are CFrame Attributes, Object Attributes, the abaility to use them in DataStores, and a little more organization please?

I don’t really like that you can’t organize it, only order it by oldest → Newest.
I feel that organization is a good feature so you can make it alphabetical for example. This little blank space:
Should honestly be used for dragging them around to the developers wish.


This is a good update and all, but why no support for CFrame?

1 Like

We’ve updated the page to address this. Thanks for letting us know!


Not just yet

That is correct


Sure! I left a reply a bit earlier explaining this.


You can replicate this by waiting for the attribute changed event:

local attribute = instance:GetAttribute("Attribute")
if not attribute then
    attribute = instance:GetAttribute("Attribute")

We are unlikely to add a built-in method for this as nil is still a meaningful value. In that sense, how do you wait for nil?


No, attributes adhere strictly to filtering rules. The only exception is in team-create where attributes need to replicate from the client to server.


How will attributes work with Parallel Lua? Will we be able to access them from other Actors or VMs? Is this a viable replacement for relying on modules returning the same value every time?

This is all our current properties

But here’s a list of things I’d like to see.


0 voters


I’ve been using attributes while working on my combat system, and it’s more convenient than I anticipated.

it’d be cool if

  • Scripts could create private/read-only attributes
  • Arrays were supported
  • Object values were supported
  • The Properties window differentiated attributes so it’s clear that they’re not indexable.
    I originally thought we could just do Object.AttributeName = 123. The documentation is clear enough, but it might confuse some kids. Better yet, maybe just make them indexable? Idk, could be another reason to have a method that lists the indexable properties of an object.

just my 2 cents
I’ll try to shut up now


Are you considering doing a feature request for any of these to add with the new Attributes? They’re all great ideas

:stuck_out_tongue: I thought it was a nice idea too until I noticed that it’s a bad idea

1 Like

haha I sorta just skimmed the beta post.
Why not something like

Object.Attributes.myAttribute =,0,10)

As for mutability, it’s not like you could do Part.Position.X = 5 so why would anyone expect to be able to do that with attributes?

In all fairness though it’s fine as it is. It has already launched and arguing semantics should’ve been done in the beta.

We also considered this and decided it wasn’t a great idea either. Unless you cache the value of ‘Attributes’ you’ll always be doing two index operations .Attributes and .MyAttribute. Performance wasn’t great as you can imagine, and neither was expecting developers to cache the value.

There’s still some weird semantics with mutability too:

-- this is fine
instance.Attributes.MyAttribute =, 0, 0)

-- this is not
instance.Attributes.MyAttribute.X = 5

Overall we concluded explicit getters and setters were ideal, and if developers wanted something else then they could always write a helper that used the same methods underneath.


I have one suggestion in regards to attribute value options. I think it would be handy to include “Int” as one of the data types, even though we already have the “number” value for this. Reasons for this is because:

  1. Can stop decimals from being added to an attribute that is only compatible with Int. A user may accidentally put a decimal and might cause issues in scripts (such as sound id)

  1. For free models using attributes as a way to configure stuff, users may attempt to put in number values as an attribute, which may cause scripts to break. This could be fixed by round up in scripts, but users may still think that entering a float number is okay as the attribute does not force whole number
    (While “IntObject” does force whole number)

  1. You already have an “IntObject” and a “NumberObject”. So why not also have “Int” Value as an attribute, which is a standard data type in most programming languages.
1 Like

The complication is that there’s no way to tell which is which.

thing:SetAttribute("Foo", 4)

Is 4 an int or a number in this case? The developer could mean either option and a more complex API would be needed to disambiguate.