Attributes outdo configuration modules which outdo ValueBases in my opinion.
They’re really only useful for leaderstats now, but even then Roblox can just implement a new way of making those without them. I really can’t think of any other use cases for ValueBases that the two aforementioned can’t do.
Even leaderstats have been something I was thinking about roblox deprecating in a way. The way you make leaderstats is so stupid. It should have been a function under the player object or something. Making a object called leaderstats to put values in… it’s so… it feels so wrong in a way. It’s annoying to type and just not my thing. I was creating a leaderstats module a time ago, ended up stopping because I forgot, it made the code so much smaller.
Definitely one of my favorite features to come out. Makes life so much easier for certain stuff. Thank you so much. This couldn’t have come at a better time for me.
same, I’m so used to using Values and dictionaries, ill probably still use attributes, but not as much as others, for me it just causes a little more confusion if I forget where the attribute is etc…
ValueBases are still a preferred option for people to use because using Attributes can make things a little harder to organize then using a dictionary in scripts, or Values
I don’t find using attributes too tedious, you can create and edit them all through the properties widget in one go, versus inserting a bunch of different types of ValueBases into some Configuration folder and selecting each one and inputting different initial values. Also reduces the amount of indexing for children since most people index for children using the dot operator, which you avoid by using attributes.
yea, you’re right, to me its just more fun using dictionaries to store data that I’m only going to use in one script. I don’t know if others will do that, but to me, its just my own preference.
May be considered a bad practice in the future
This new feature is massive for the Scripting Community as a whole, I’m sure we’ll all benefit from this. If possible, I think we’d all like to see AttributeAdded and AttributeRemoved events, similarly to ChildAdded and ChildRemoved if possible. Without them, it makes certain uses such as an attribute-based inventory where each attribute represents an item difficult to keep track of.
well this update alone has pretty much rendered Values redundant in a sense since attributes not only allow you to keep the values all in one place but they let you choose the type of value that is contained within the attributes, effectively rendering the Value instance redundant
This has been the think i always wanted when i started developing. This is going to change everything about scripting in this platform and make it more accessible to people.
I’d suggest to make Attributes locked to Configuration objects, this would be neater for the feature as a whole and provide some intentional functionality to them.
or you can just deprecate them
But this is epic now that it’s live! ObjectValues redundancy go brr
Custom methods are a really interesting idea! They are out of the scope of Attributes, but you should definitely make a feature request if it’s something you want.
local value = instance:GetAttribute("Value")
instance:GetAttributeChangedSignal("Value"):Connect(function ()
value = instance:GetAttribute("Value")
end)
In which case, you should see some minor performance improvements if you’re using the value of ‘Value’ a lot.
Yeah that’s what I wanted to know. The performance improvements with value objects was pretty extreme, not minor, so I wasn’t sure how much that changed here.