I’m not really sure what I’d use this for unless it’s supposed to replace objects like boolValue, IntValue, etc…
Yay! I dont have to keep redoing items now trying to get them perfect! Great update! I have already used this a lot since it came out.
1 Like
For those wanting to access attributes as properties this would not work too well in the grand scheme of things. In the future when Roblox releases new properties such as the recent AssemblyLinearVelocity and whatnot if players had an attribute named that, it would break their game as having an attribute the same name would be seen as the new property too. I’d assume this is why Roblox has gone with functions to read and write attributes. Keeps developer created properties away from Roblox ones. That’s just my guess though and would love to hear an official response! 
2 Likes
I thought we were going to be able to do Instance.Attribute… ;( But looks like I have to call a function every time I wish to access a custom property. Will this changed or the only way will be GetAttribute()?
4 Likes
I don’t really see what’s so useful about this; dont get me wrong this could be useful in some cases but if your not planning on using actual object values I dont see why youd need to use this
Maybe I’m not understanding what its true potential is, so if someone could shed some light or explain it to me better than; thatd be great 
This doesn’t really add anything new it can just improve the workflow for some developers.
As an example a programmer creates a weapon and has many settings for configuration, currently the programmer would just have to explain to the team that are going to be configuring the weapons how to enter the script and modify the settings. With Attributes the programmer can just expose what should be configured and everyones lives are easier.
Other examples are it superseeds all the ObjectValues replacing the ability to store persistant data in studio/game, reducing how complicated and messy the games Workspace is.
3 Likes
Yeah this is exactly what I thought, thanks for clarifying
1 Like
That could be solved by making attributes take priority over properties when direct indexing. If Roblox adds a new property, it won’t break the script.
edit nevermind, direct indexing for attributes is a bad idea
2 Likes
no way this is being added, FINALLY SAYING BYE BYE TO VALUE OBJECTS
If I’m understanding you right, this then makes it impossible for the developer to write code for that new property without redoing that aspect of their game? The way they have it setup with functions makes the most sense and helps “future proof” the feature.
3 Likes
FINALLY!
This is going to change the future of Roblox in an incredibly major way. Hoping table support comes next.
1 Like
You can just use find & replace (ctrl/cmd+shift+f) on all of your scripts, and then use a command bar script to rename the attribute on all instances. It wouldn’t take long at all, and that’s only if you choose to use the new feature.
edit nevermind, direct indexing for attributes is a bad idea
2 Likes
As a developer I shouldn’t have to change the name of my attributes because Roblox has added or changed a property name. Having functions for attributes flows better with updates as they do not need to worry about accounting for names that would be taken by developers which could be literally anything and then making developers go through process you mention above.
1 Like
Wow, nice!
Attributes are great for adding easily accessible global variables, no more pesky []Values! (even though they still can be used for some things)
Just a suggestion, maybe extra toggles for it?
As in setting it to ReadOnly (value locked in place from the first time you set it, might be bad now that I think about it)
and setting it to NoReplication, better because it can keep behind both ends of the client-server, either kept on the client or server.
2 Likes
If you ask me it might be a good idea to add the new value as a parameter in the AttributeChangedSignal. Even though it’s not needed, might be a nice method to have.
3 Likes
Replication
Attributes are replicated, respecting filtering rules, from server to client. If the server changes an attribute, the clients value will also change. If the client changes the value however, it will not be changed on the server.
This is straight from Instance | Documentation - Roblox Creator Hub
4 Likes
wouldn’t it be perfectly reasonable to use folders for this?
1 Like
String values have a limit of 10 thousand characters iirc (I didn’t rc, its 200k), and scripts have a limit of 65563 characters I believe. That probably comes down to how string lengths are stored in lua/lauu, though it could be a hard coded limit. If you try to access a string that’s too long, you get an error in the output.
I can actually answer this. This is sort of partial speculation, but, I believe attributes are sent with the instance along with its properties, and when attributes are updated, they’re sent in a similar way as property changes. I’ve not verified that, but, based on what I’ve seen and how attributes are stored, I believe they’re fairly network efficient as well as space efficient. From my understanding properties and attributes seem to be stored in a very very similar way format-wise.
Based on some crude testing, they seem to be significantly faster than using Value instances. I’m not sure how they compare to remotes, but, I would guess remotes are actually slower in the case of tables due to some of the above (but are likely faster for most other data types). Again, more speculation, but, I do know that attributes are much faster network-wise.
I love testing these sorts of features, and eventually I’ll find ways to more clearly confirm or deny a lot of this (assuming staff don’t state anything), so in the meantime, yes attributes are generally more network efficient than some things but to what extent I don’t really know.
6 Likes
https://developer.roblox.com/en-us/api-reference/class/StringValue
BaseScripts do not share this limit but only when you are accessing Script.Source it will error
after testing I found that:
- a string attributes with 1e+6 characters can be set before Roblox Studio would crash
- 1e+4 attributes can be set before Roblox Studio would crash
however it seems like Roblolx Studio is crashing because it can not display the attributes and string in the Properties widget.
Code
ModuleScript
local module = {}
--|| max Attributes test
--for i = 1, 1e+5 do
-- script:SetAttribute(i, i)
--end
--|| string character limit test
script:SetAttribute("string", string.rep("A", 1e+6))
--
script.Parent = game.ReplicatedFirst
return module
Command bar
require(workspace.ModuleScript:Clone())
3 Likes
Try combining two strings of 0.5e3 length with a decent yield between them. Same with attributes, try 0.5e4, then yielding for a bit, then 0.5e4 again. Generally I’ve found that sometimes if you trigger a loop that’s too big it, I guess, overflows or something? I actually had an exact length at some point using this, but, I can’t remember what it was.
(On top of that, make sure when you’re testing you’re not selecting the instance you’re adding attributes too just to make sure you’re not updating the properties widget)