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!
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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)
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.
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.
