Attributes - Now Available!

Thank you for the list of supported types!

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

1 Like

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’.


Are there any benefits in using attributes instead of traditional value objects?

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

This is awesome! No more having values all over the place!

Thanks for the awesome update! :slight_smile:


This is amazing. This changes everything.

1 Like

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.


I agree. In my opinion, it takes way too much space in the properties menu.


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.

1 Like

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.


I believe you still have to use value objects for leaderstats.

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?

Oh my god, this saved my life :rofl:

Seriously thanks for adding this feature I will definitely use it a lot in my projects.


OMG! This is amazing. Finally I’ll be able to stop using ValueObjects :grin:


…just treat the attributes the same as they currently are but allow the dot operator. it would first look up the property, and if the property of the instance couldn’t be indexed, the instance’s metatable would detect that and attempt to lookup the attribute instead. so Object.InvalidProperty would fail to index and the function for __index would try to call Object:GetAttribute("InvalidProperty"). naturally, you wouldn’t be able to get any attributes that could conflict with the existing properties of an instance this way, but GetAttribute() would still exist for that purpose if for some reason you really want a model with two names or something.


Flags no longer have to be controlled by Value instances, thank god :pray:


I’m still gonna use values for a lot of things

1 Like

This is awesome! I would love to see the ability to set StarterPlayer attributes.

By that I mean be able to possibly add an attribute to the StarterPlayer folder, and have that Attribute carry over to players when they join. Without that, you have to run an event when a new player joins, which can be clunky if scripts are searching for that Attribute on start.

Another solution to this would be to add a function similar to 'WaitForChild" where it instead is “WaitForAttribute” that way scripts that need an Attribute that may not exist yet can use that function to wait for one. Without that some sort of repeat until loop may need to be run, which is very clunky and inefficient.


We also very much want to expose parameters for playerscripts as attributes in the future.