As a Roblox developer, it is currently inconvenient when making Attribute-based systems to suddenly need an ObjectValue instance because “Instance is not a supported Attribute type”.
If this issue is addressed, it would improve my development experience because I wouldn’t need to change how I receive values, going from property-like instance Attributes to relying on ValueBase instances. For example, when keeping track of the last player to attack an NPC, that information could be kept as an easily overwritable Attribute of the NPC rather than relying on physical values within said NPC.
While Attributes were, to my understanding, not a replacement for ValueBase instances, it has greatly increased my workflow to be able to give instances characteristics without creating further instances. Some instances already have Instance-type properties, so I would be willing to assume that this might be something easy to implement on the Roblox backend.
Attributes also have support for tables, dictionaries, and a ton of other data types, that behaviour is just disabled initially:
I think it’d be very nice to have Instance types on attributes, and with other stuff, that’d basically allow me to actually port all of my game classes to fully utilize attributes.
@metatablecatmaid ObjectValues do store their values just fine. They use a referent which is basically just an ID specific to the rbxm file its part of that tells it what instance in the file to refer to. You can save an ObjectValue with its value so long as the instance it references is part of the same file (otherwise you couldn’t save ObjectValues in your game at all, their value would reset at runtime)
Making attributes support instances is as simple as using the referent ID in the file.
I figured something like this might be the case. I also understand their approach to implement this as a system that is freely accessible without programming but CFrames, for example, one of the most commonly used data types, are not visible in property menus. I think all types should be available for use in the meantime.
Object attributes are extremely important for things like streaming!
ObjectValues currently handle parts streaming in/out very seamlessly, which makes them easy to work with. It’d defnitely be nice to support object attribute types with this behavior as well.
After a year, this has still not been added and is still very much needed.
Its absolutely infuriating having to use ObjectValues alongside attributes. Its just an inconsistent mess. I wish I could convert everything to attributes already.
After almost 2 years, the last news (that I know of) was this:
Having to deal with object values and attributes can get really messy in some cases and can get very frustrating. This is a 100% needed feature. With the addition of CFrames to attributes, I hope to see this effort continue into instances. With large codebases of hundreds of module scripts, having to deal with both attributes and object values is very hard to work with.
Its been a few years since this was “under investigation”, I really hope to see this ship soon.
Currently, the only workarounds for the lack of instance attributes is either through using an ObjectValue or using a unique identifier.
ValueBases are not ideal because they crowd the workspace making it worse to work with, for myself and my team, and also increases the amount of memory the client for players because of the amount of information instances alone contain from properties (events included). This is worsened even more by the fact that we have hundreds of value bases in the workspace to construct each physics based object and options.
You could argue that I should use a mix of ValueBases and attributes but at that point remembering which settings are value bases and which are attributes for someone who isn’t a programmer isn’t really easy. And it would take a long time for me to write up a guide that would change every time a new physics object is implemented, not to mention how disruptive it would be to our workflow.
A unique string identifier for each replacement of an ObjectValue is just not feasible for us either especially when we’re working with multiple non-programmers who would have to ensure they don’t overlap identifiers. I could probably write something up to warn when identifiers overlap but once again this is going to take time which could be better used towards something else (plus once again disruptive to the workflow).
Anyway, allowing for instance (among other data type) attributes would reduce memory usage for our players, while imposing a minimal if any workflow disruption for both me and my team.
If I remember correctly, I read it hasn’t been added because of the Lua API, and how nil is the default value for Instance properties, but nil already means the attribute doesn’t exist. There would be trouble with the difference between an Instance attribute existing with no value or not existing at all.
Honestly, because of the whole nil issue, I believe the best approach would be to have a nil-like object thats treated as nil by Luau, but isn’t actually nil in the property editor and attribute spec when saving.
Going to revive this because I still come across code that would benefit from this.
My use cases usually revolve around storing quickly swapping Instances like Checkpoints, Selected Objects and Bullets for other scripts to use.
I don’t really care about setting those attributes in Studio since it’s not really the main point of ObjectValues either, so I think holding this back just because it wouldn’t mirror well with the properties widget is unneeded.
Is that not the case with any other attribute type like Vector3 or CFrame? I don’t see what problems it would cause, why would anyone expect to handle the cases of an attribute existing with nil or not existing at all differently?
Well the attribute is nil if there was no attribute found with the provided name. Nil is the default value for objects so this would become problematic.
Again, there’s no such problem right now with Vector3 or CFrame values, which could also be nil in the case of the attribute not existing, what cases would this be problematic specifically? what does introducing instances change?
Programmatically, there is no problem with the current implementation of attributes that prevent Instances from being added. A nil value acts exactly the same as no attribute, but the setback is they wouldn’t appear the same in the properties widget because, well, no attribute is no attribute.
My only idea would be to simply allow instance attributes to be shown in the widget as “blank” (i.e., they don’t actually exist), and then in studio be able to set their value to whatever it is. The problem to this is probably how attributes are serialized in file places, which would need to be changed in order for studio to retain those attributes’ names between saves.
Personally, I would just add engine support for them already and worry about studio interfacing later because the majority of my use cases don’t revolve around having pre-set attributes anyways.
Meanwhile the binary format uses u32 based Referent objects, while I would say the best way to fix this would be to just compile the attribute string based on how you save (RBXM or RBXMX) but that feels a bit hacky since attributes have their own specification.
What I’m thinking of on that RBXM/RBXMX thing is having two unique type ids, InstanceBinary and InstanceXML which would be a u32 and string respectively, regardless, we’ll let Roblox decide.
