Add Instance as a Valid Attribute Type

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.

70 Likes

I’ve mentioned this on the original thread a̶n̶d̶ ̶i̶t̶ ̶s̶t̶i̶l̶l̶ ̶h̶a̶s̶n̶’̶t̶ ̶b̶e̶e̶n̶ ̶a̶d̶d̶e̶d̶:


I’m quite surprised that they didn’t add all of the different object types as valid attributes.

9 Likes

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.

8 Likes

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.

5 Likes

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.

11 Likes

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:

7 Likes

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.

3 Likes

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.

1 Like

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.

1 Like

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.