I see what you mean, but this is the kind of hidden hard-to-discover behavior that we wouldn’t want to bake into streaming. For example, should it suddenly not work when you put those Value objects into a folder? What about more nesting? What if you nest the value objects under a script? Should it still work for any “container”? But at that point you run into the same problems again.
9 Likes
I couldn’t agree more with this point. I feel that a lot of the black-box behavior that we (developers) complain about to Roblox is stemmed from this kind of request.
At the end of the day, Attributes are a wonderful improvement regardless of their StreamingEnabled benefits, which I also greatly appreciate. I would rather we add features that explicitly take StreamingEnabled into consideration instead of creating behaviors which more likely than not will come back to haunt us a few years from now.
3 Likes
This is a very nice way especially for someone who saves a little data in instance tags.
Another version of this would be a similar thing for uploaded assets so developers can easily create meta. Something like labels for uploaded assets with key-value pairs is like putting JSON to its description but without getting hashtags.
This way beginner developers can make easy asset configurations without even making their solution. Didn’t make a feedback post for that because it is minor.
A good upgrade, thank you!
They should make it indexable like “object.Property” but if it interferes with an existing default property it should be, “object:GetAttribute(“Property”)”
2 Likes
Ive been waiting for this for quite a bit now, pretty exited to see it in beta. My new projects definetely use a lot of ValueObjects for data so its nice to not have to do that anymore.
For the initial release theres quite a bit of supported datatypes, but do you have plans on supporting Instance data types? I find myself using ObjectValues a lot and having attributes support Instances will be very nice.
Im exited for this to go live
Idk if you guys know already, but when I ran this code no errors popped up:
workspace:SetAttribute("Userdata", newproxy(true))
1 Like
The documentation has an error, shouldn’t this be all with capital letters:
SetAttribute by the way…
1 Like
whats going to happen to the value objects?
2 Likes
THIS IS SO AWESOME LETS GOOO 
It would be nice if I could use .Changed, so for now I’m gonna stick to Values for the stuff I do.
Epic! Seems like this will be very useful.
I am hoping in the future there will be support for all data types (primitive and non).
This is cool, but custom object/instance attributes will be really useful, because i’d like to replace object values for organization purposes.
They will probably stay for now since it has it’s own usages (For leaderstats).
1 Like
You cant use Userdata in the beta.
So this is going to be so useful! Now I can just add attributes instead of creating millions of values and referencing them.
Also artibbiutes are basically like public variable in unity right?
Or more like adding your own properties to an object
Based on all the points raised in this thread it feels like the best solution would be to un-deprecate the Configuration object, and allow attributes to be applied to them exclusively. This solves the streaming issue while also not duplicating Value functionality.
My main gripe with Attributes is how they effectively try to replace Value objects/instances (ability to place them anywhere) - while also being impossible to view in the Explorer. This is akin to adding random properties to classes in a codebase wherever you need them - it encourages bad style especially as a game codebase grows.
Locking the feature to Configurations would allow Roblox to un-deprecate an object rather than duplicate functionality, and be easily viewable in the explorer as well. It would be a dedicated place for configuration and be very clear to contributors and non-engineers how to use it.
Please consider these changes!
2 Likes
Why artificially limit the capability of this feature for all developers when for the example you’ve given could easily be achieved by just setting a standard within your own team.
Use Attributes only with the Configuration object your team can make this choice.
4 Likes
Forgive me if I’m wrong, but it really seems like you’re just searching for any reason to bash this feature at this point. Roblox has always had multiple ways of doing things, this isn’t anything new. It’s simply one of the drawbacks of having a backwards-compatible engine. They introduce new and improved ways of doing things while keeping old functionality all the time (case in point: the new raycasting API). Not to mention that by arguing against attributes, it seems like you’re implicitly arguing for having hundreds of different ValueBases to cover every single data type.
The sizeable number of benefits to using attributes over ValueBases have been thoroughly discussed many, many times throughout this thread, but you still seem keen on bashing the feature because it just isn’t what you’re used to. Sorry, but wanting to cling to an archaic, outdated system because it’s what you’re used to isn’t really a valid reason and all-around seems like a very entitled attitude.
Lastly, Roblox is evolving as an engine and wants to appeal to developers who haven’t necessarily been on Roblox since they were ten years old like you have. This is how both Unity and UE4 handle parameterized objects (tied to the object and edited through the properties panel equivalent) – you even admitted this yourself. If you proposed a system akin to ValueBases to anyone at Epic Games, they’d laugh you right out of town. There’s a reason they do things the way they do and it’s high time Roblox adopted a similar system.
(Also, there’s literally nothing preventing you from continuing to use ValueBases, so I’m not sure what all the fuss is about.)
12 Likes