That is really nice and it is going to help developers a lot
wouldn’t storing jsoned arrays with string typing work?
AMAZING!
Gone are the days of just making values, now its not important to store values which is now useless on the other side can we get the table of attributes? in code
Wow, this is great! This looks like it’ll be really useful.
- CFrame
- EnumItem
- Instance
- Region3
Also, the ability to tween attributes would be super useful, but if not that ok because we still have value objects.
This opens a lot af new doors! Excited to try this out without having to add values!
Object value type would be useful! For example we could add a “Destination” attribute to a portal/door to allow linking it to its destination portal/door object (to replace using ObjectValue).
yayyyy, big motivation coming into me! I have been waiting for attributes for quite a long ever since I saw colbert hyping it up XD
One question is, will there, by possibility be a method to get every attributes available within game? I would like to have some global configuration and link up those attributes to certain objects or simply review the attributes that I have set which both requires me to have a centralized way of altering those objects at once. If this method is available, I will be able to make a custom plugin to do so.
Finally! we’ve been waiting for this for years
this is much more practical and economical
So far the only way to get them is by doing: Gun:GetAttribute("ReloadSpeed")
.
It would be nice if you could define like that however.
It is actually better not to be able to get them like that, because if you name a attribute the same as an existing property there could be issues, unless they added a safeguard that you can’t add attributes with property names that already exist.
Wait a minute… I never even heard of this! Once it’s out of beta I might just move away from dictionaries because this seems to be easier to use. Can’t wait!
That is true, they already have some name restrictions in place so they could possibly add that safeguard you said before allowing us to define it that way.
Thank you! I will not need to use values such as bool and int values that much anymore! Thank you SO much for this.
I see these being really useful for open source resources.
(Would be interesting if we could create dropdown selections for attributes?)
Another great addition for developers.
OH MY GOD ITS HAPPENING!
I have been anticipating this feature for a while now! I can’t wait to play around with these! I also can’t wait to see how others play around with these - I know that many packages and free models will be a lot easier to organize with this!
I am definitely feeling like CFrame is a needed value here. We have Vector2 and Vector3, CFrames are used just as much for positioning.
On a lesser request, maybe some time we can get Instances as a valid type? I know you can do it in Unity and it does make things a lot easier, but it isn’t something that is a 100% solid use case.
we can add more options to the pbr like displacement map oh put more options to the illumination?
YES YES YES, They are here. I cannot believe this. Oh I can’t believe this.
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!
First of all:
Next up, a question:
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.
Also, this: