Right now, attributes are a simple value container with nothing else special about them. This is perfect for their purposes during runtime, but when it comes to interacting with these attributes in Studio through the Properties menu, there is room for improvement. Introducing unique methods for plugins to leverage in Studio that modify the behavior of attributes is a great spot to begin.
I implement attributes in a plugin to create new data for playable creatures in the game I develop. This works great, but some of the properties of these creatures are intrinsic (should be read-only through the properties menu, only editable by the plugin), and other properties use very vague restrictions (such as a string attribute to represent the diet of this creature) that has room for error without the ability to choose from a number of presets. This also applies to a selection of numeric values that have a min/max constraint or only accept integer values.
To work around these little issues, my plugin implements a great deal of code designed to manage the values of properties. Tracking which objects are valid creature data containers makes the code very messy, and without the typical visual cues that native properties can provide (e.g. being grayed out if they are read-only, having dropdown menus, etc), it can often be confusing to users. My plugin’s code is about 2000 lines long, and of those 2000 lines, almost 1000 lines are data verification to correct malformed user input and let them know what’s wrong, and to limit read-only attributes by detecting changes and changing attributes back to their intrinsic values. Ignoring lines from data structures (e.g. the table that defines what the structure looks like), this makes a minority of my code actually relevant to creating the data. A great deal of this bulk could be cut with the following capabilities:
The features that would be useful for my case:
- The ability to mark attributes immutable from the Properties window. This makes them appear like read-only properties. Scripts can still modify them through
SetAttribute, but the Properties menu cannot be used to modify them. This hypothetical locking/unlocking method would exist at PluginSecurity or above. This is relevant because in my plugin, some data is intrinsic to everything else on the structure, and is a result of a number of settings, not something that should be directly set in the Properties menu.- This shouldn’t change how standard scripts interface with attributes. Get/Set will still work unquestionably and without restriction. This only applies to the properties menu in studio to prevent a human from using the GUI to change properties as a loose means of saying “Hey, this is managed by a script, you probably shouldn’t be messing with the value.”
- The ability to create a set of options for a string attribute (a drop-down menu). This would be in a manner akin to that of Enums, but basically it adds support for arbitrary terminology. This is relevant because it makes it much easier to use for my coworkers that are not familiar with the terminology used for a few arbitrary string settings of a data structure. Rather than requiring my peers to remember a set of strings, they can just click from a dropdown menu.
- This extends to the ability to define minimum and maximum values for numeric attributes, as well as requiring integer values or allowing decimal values.