Finally! we’ve been waiting for this for years
2 Likes
this is much more practical and economical
1 Like
So far the only way to get them is by doing: Gun:GetAttribute("ReloadSpeed").
It would be nice if you could define like that however.
2 Likes
It is actually better not to be able to get them like that, because if you name a attribute the same as an existing property there could be issues, unless they added a safeguard that you can’t add attributes with property names that already exist.
1 Like
Wait a minute… I never even heard of this! Once it’s out of beta I might just move away from dictionaries because this seems to be easier to use. Can’t wait!
1 Like
That is true, they already have some name restrictions in place so they could possibly add that safeguard you said before allowing us to define it that way.
1 Like
Thank you! I will not need to use values such as bool and int values that much anymore! Thank you SO much for this.
1 Like
I see these being really useful for open source resources. 
(Would be interesting if we could create dropdown selections for attributes?)
Another great addition for developers.
1 Like
OH MY GOD ITS HAPPENING!
I have been anticipating this feature for a while now! I can’t wait to play around with these! I also can’t wait to see how others play around with these - I know that many packages and free models will be a lot easier to organize with this!
I am definitely feeling like CFrame is a needed value here. We have Vector2 and Vector3, CFrames are used just as much for positioning.
On a lesser request, maybe some time we can get Instances as a valid type? I know you can do it in Unity and it does make things a lot easier, but it isn’t something that is a 100% solid use case.
we can add more options to the pbr like displacement map oh put more options to the illumination?
YES YES YES, They are here. I cannot believe this. Oh I can’t believe this.
Maybe I’m missing something but I don’t see the point / advantage of this feature, it feels like it’s just another way of doing the same thing therefore adding confusion to the engine. Is there a performance improvement?
It feels like the exact same thing as Value objects except it’s much harder to see if something has a value inside it (by checking the explorer dropdown). You’re now required to use the property widget and can’t see if an object has attributes at a glance. You can also categorize your values into sub-categories this way.
Instances in Roblox is the meta for how you add properties to an object. This system feels like it’s trying to be a Unity/Roblox hybrid. Roblox should be innovating based on developer needs, not copying oddities from other engines. If this is the path going forward and Value objects will be deprecated, please make an announcement!
6 Likes
First of all:
Next up, a question:
How do attributes work with packages? The ideal scenario would be that adding/removing attributes themselves counts as a change to the package but changing the value of attributes does not.
Also, this:
3 Likes
valuebases might get deprecated soon after attributes are released to the public
You really don’t see the use for this? Attributes are almost definitely more memory friendly than ValueBases (instead of having a dozen separate instances each with their own name, parent, etc. you’ll now have just a few properties of one instance), they reduce clutter in the explorer, and they can support a much, much wider range of data types without introducing whole new instances.
19 Likes
This could work but ultimately I’d prefer having to avoid decoding a JSON every time I have an update on the table. I like convenience; it would improve my developer experience to not need to use HttpService whenever I update an attribute with a table value. Instead, when checking for a changed attribute, I can just access the table’s members directly.
4 Likes
I’ve been waiting so long for this feature! Thanks you guys for this!
Time to head on to a Baseplate 
2 Likes
When I hire a new engineer I don’t want them having to dig through all of our objects checking if they have attributes.
They can currently easily look under a folder and configure the parameters. This is easy for our artists as well.
If there’s performance improvements I would love to see the details! From what I understand the only extra property a Value object has is a memory address (Parent), which is extremely small. So having 100 values in my game versus 100 attributes will likely make little difference.
This just feels like a hack week project and not something the engine should have had added. Multiple ways of doing the same thing are not beneficial to scaling teams or future-proofing code.
2 Likes
This seems like an amazing update at first, but I think I’d avoid using it until more types are supported.
This includes TweenInfo, Enums, CFrames, Region3, object values and tables.
If those values were supported, this would be the one of the best updates I’ve ever seen.
1 Like
Bit of a weird question: is the serialized format for attributes stable? I figure it will be, but since this is a beta I figure I would ask.
Also support for Enums and CFrames are my Big Requests. I realize there’s some oddities with having CFrames appear in the property widget though (read: they don’t appear in the property widget), so I expect that it may take a while if we ever get support for it.