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.
Before Update:
After Update:
Really helpful, however I really need the Instance type.
12 Likes
Not really true, the script only has to access for example a much shorter route than it would having to search for those value objects. script.GunReload would be much faster than script.Folder.GunReload.Value for example and if you had multiple then the time it takes in the amount of code you have will start to show with the latter. Not only that but there is less clutter in the workspace, valueobjects were only ever extra containers to hold data so having that container now embedded in the script for example of which is also quickly accessible is a plus. Also wouldn’t you tell your engineer where the important attributes are? Considering they’d be set in scripts of which can be named for the engineer to easily find.
1 Like
This is all I need to transition from value objects to Attributes.
So far the main advantage i have found for using attributes over value objects are that since its not instance based, there will be no need to clutter the script with FindFirstChild / WaitForChild’s. Its pretty minor but would definitely help avoiding errors caused by instances not being replicated!
3 Likes
OH MY GOSH YESSSS FINALLY!!! I cannot believe this is FINALLY here. I thought it was abandoned awhile ago but now that it’s released will finally open up SO many possibilities to devs. Thank you SO much to the people who worked on it on the backend.
2 Likes
Seeing as a Value object contains a 5 “attributes”, it follows that a single attribute should use less memory, though I have no way of confirming that without seeing the way Roblox internally sets up Attributes vs an Instance without any additional Attributes. That being said, I doubt you would see any significant performance increase by using one over the other.
I do, however, see the use case for something like this. By allowing you to store additional data attached to a single Instance, you could add attributes to a Model to make it represent a PetBase or CustomCharacter.
I do agree with this, though there are non-hacky ways around this (such that you do not need to clutter projects with WaitForChild or FindFirstChild). Edit: You might end up removing clutter from FindFirstChild, but you will end up cluttering a project with GetAttribute instead, though once again there are non-hacky ways around this aswell.
I do have some additional things to add to when you said you don’t want new engineers to dig through your objects looking for attributes, but seeing as I do not know the structure of your projects I doubt I could provide any meaningful feedback.
2 Likes
The file format supports this already, and can actually load integer values too, so, if its in demand I’m absolutely sure Roblox would be able to add it pretty quickly (and may already have plans to)
The attribute format supports all of those excluding TweenInfo, Instances, and RBXScriptSignals (I checked literally every single data type and I have all of their type ids in the file format and everything)
RBXScriptSignals sound impossible to support I think, so I doubt they’d make it, but the other two are probably possible, Instances though would be difficult.
Also if you’d like to be able to send TweenInfo I think it’d be a good idea to create a feature request for their support in remotes. (I would like to see them in attributes too)
AttributeChanged only detects when an attribute’s value is updated afaik, and there is no programmed limit to the number of attributes as far as I’m aware. I would guess the string cap is 2,147,483,647 if I had to guess since iirc the length indicator is stored as a 32 bit unsigned integer (but that doesn’t take into account the limit for strings in a script)
They are significantly more performant and memory efficient, and on top of that, far, far easier to work with in code. They are a miracle.
Tables are actually supported, both dictionaries and arrays, hashmaps, etc, as long as the key type and value type can be saved as an attribute value, the table itself can also be saved.
I think they’re incredibly useful. They introduce a very clean interface between instances and code, take up less memory, and are more performant by a long shot, and on top of that support far more data types, can store tables, and don’t require you to find the class name you need for a given value. These are the future replacement for value instances, imo.
I was actually just about to say something about this. I think that I would like to have the ability to add little indicators over Folder and Configuration instances instead though, maybe they could get a property to select their indicator, for example, there might be a gear icon like configurations have, or there might be a star icon, maybe styled after the sparkles texture. (I actually really dislike the existence of Configuration instances personally)
12 Likes
I think that’s kinda the point he is trying to make. Let’s say I prefer value objects to attributes (because I don’t have to switch back and forth between the explorer and properties tab and overall value objects just fit with my workflow better)… then are there really any differences between the 2 that are not negligible?
At first I was really hyped for attributes but I am failing to find any use cases that object values do not already fulfill. I still think they are cool though and I will use them in the future, but only because they fit my workflow.
4 Likes
This is awesome!! I can think of so many ways I can use this! 
1 Like
I see a lot of people saying this supersedes or replaces values. Is it the official plan to deprecate all ValueBase instances? These don’t sound like the same thing. I can think of several places I would prefer to have a ValueBase around where an Attribute wouldn’t really make sense.
Oooooooo, this is looking to be a really handy feature to have. I’m sure this will also reduce index lag since its not an instance.
Excited for this to be live 
1 Like
I am really looking forward to this update. Looks promising!
@Neutron_Flow
The biggest one is that attributes support complex tables, and far, far more data types.
There are a few other benefits I thought of though:
- Performance & memory usage (Particularly network performance I think will be an important difference, but also CPU performance)
- They’re generally a lot easier to use in code
- They’re a lot more compact in your save file meaning your save file will be a lot smaller
I absolutely agree that value instances still make sense in some cases, but, I personally think they should be deprecated. Value instances to me have always felt hacky and strange. But, that’s not to say I don’t think Value instances should never be used, sometimes deprecated features are still used and for good reason. Deprecating them doesn’t make them go away or anything. Generally I would expect them to be used somewhat like Configurations, where you maybe use a few Folder instances to specify options, or you might store your attributes directly on the model they’re a part of.
Maybe that’s just me lacking info about what your case is though, I’m sure you’ve got good reasons considering the amount of people I’ve seen saying the same thing about that.
3 Likes