[FEATURE REQUEST] [VERSE] Expose internal utility attributes for QoL editor workflows

[Sprintermax]

As a creator working with verse, we have limited ways to deal with the communication to non-verse devs when working on infrastructures for projects. The editable UI is not always consistent, lacks customization, accessibility features and functionality to work with it in a more flexible way.

We creators already have some attributes available (such as specific types, tooltips and categories), but they does not cover the usages mentioned later on this request.

Something important to note, is that verse already has attributes to deal with many of these limitations, and Epic is already using it internally on the API they provide for devices, scene graph, structs and other fields in verse when working with the editor.

The main problem still is, these attributes are not public, and we creators can’t use it, thus creating the lack of flexibility mentioned previously.

---

Here is a list with some of the internal attributes that should be exposed for us creators:

• @hide_in_editor → This attribute prevents a struct, field, class/subclass type and other data from appearing on editor. This is specially useful for when we want to give creators ability to choose classes for behavior selection, but some variants of it must remain hidden and not being exposed to the editables. Currently we can only hide classes that are <abstract>, but that limits other usage, such as preventing us from creating internal instances of it in code too.
  Example Usage:

@hide_in_editor
game_config_base := class: # This class does not show in editor to be selected/instantiated

game_config_float := class(game_config_base): # this class shows on the dropdown normally
    @editable
    Value : float = 123.45678

game_config_string := class(game_config_base): # this class also shows normally to be selectable
    @editable
    Value : string = "Hello World!"

#### Then:
my_device := class(creative_device):
    @editable
    GameOption : game_config_base # User will be able to select the allowed child classes but the base class will not show on the dropdown due to having the '@hide_in_editor' attribute

• @display_name("Something") → This attribute overrides the display name on the UI when showing the property that has it. It is absurdly useful on the communication with non-verse devs working on the project, since we can give friendly names to structs, fields, values and property names, that is shown when selecting or displaying it on the editor, instead of always showing the internal verse name that may be confusing and “too spammy”, specially for the non-verse devs.
  Example Usage:

@display_name("Float Config")  # Instead of 'game_config_float', will show as 'Float Config'
game_config_float := class(game_config_base):
    @editable
    Value : float = 123.45678

@display_name("String Config")  # Instead of 'game_config_string', will show as 'String Config'
game_config_string := class(game_config_base):
    @editable
    @display_name("Game Name") # Instead of 'GamemodeIdentifier', will show as 'Game Name'
    GamemodeIdentifier : string = "Hello World!"

@display_name("Game Type") # Instead of 'game_variant_selector', will show as 'Game Type'
game_variant_selector := enum{
    @display_name("Fixed Spawn Count") # Instead of 'Finite Spawns', will show as 'Fixed Spawn Count'
    FiniteSpawns
    @display_name("Last Survivor") # Instead of 'Last Standing Wins', will show as 'Last Survivor'
    LastStandingWins
    @display_name("FFA") # Instead of 'Free For All', will show as 'FFA'
    FreeForAll
}

#### Then:
my_device := class(creative_device):
    @editable
    GameOption : game_config_base
    @editable
    GameMode : game_variant_selector

• @units("Something") → This attribute is used to attach a suffix on a value when being displayed. This is useful to append unit type information to values making it easier to undestand what it may be about. That would be a better and more flexible way of informing the user than placing this same information on the variable name or some description field.
  Example Usage:

my_device := class(creative_device):
    @editable
    @units("s") # will show as '10.0 s', informing that the time is in seconds
    Duration : float = 10.0

    @editable
    @units("cm") # will show as '150.0 cm', informing that the distance is in centimeters
    Distance : float = 150.0

    @editable
    @units("x") # will show as `3 x`, informing that intensity is a multiplier
    Intensity : int = 3

    @editable
    @units("km/h") # will show as '30.0 km/h', properly informing the speed unit used
    Speed : float = 30.0

Again, all the three attributes mentioned already exists and already works like described above. They are just internal and we creators can’t use. My proposal is to expose these to allow more flexibility when displaying verse related values on the editor.

---

New Attribute Idea:

Now, the following attribute currently does not exist, but would be amazing to have something with this functionality:

• @disallow_subtype_selection → This attribute would hide the dropdown that is shown that allows the user to select variants of some subtype, such as on interfaces or classes. This is specially useful if we want to expose a specific class type to the user but not allowing to change the type, while still having the types internally on the code. This also would be useful to remove “spammy” selectors when they don’t make sense to exist, such as fields that does not have variants to be selected at all.
  Example Usage:

my_class := class:
    @editable
    Thing : float = 0.0

my_class2 := class:
    @editable
    Something : float = 0.0

my_class3 := class(my_class2):
    @editable
    AnotherThing : int = 0

my_device := class(creative_device):
    @editable
    @disallow_subtype_selection # hides the dropdown to change the class type, and user only see the fields of 'my_class2' base class, such as 'Something'
    SomeData : my_class2 = my_class2{}

    @editable
    @disallow_subtype_selection # hides the dropdown to change the class type, and user see the fields of 'my_class3', such as 'Something' and 'AnotherThing'
    SomeData2 : my_class2 = my_class3{}

    @editable
    @disallow_subtype_selection # hides the dropdown to change the class type. It does not make sense at all to be displayed on this case, since there is no other variants valid to be selected
    SomeData3 : my_class = my_class{}

---

These attributes would help a lot with the communication, flexibility and usability of the editables in editor. Here I made an example of how it currently is (on the left), and how it could be (on the right) when using attributes to improve the UI/UX:

On the example above, it would be using the @display_name("") on the classes, and the @disallow_subtype_selection on some fields (such as the “Result”). See how it would improve readability a lot by just having these functionality exposed for the ability to control editables more granularly.

[Hicsy]

edited

[Sprintermax]

That’s a feature request, not a bug report hahaha xD It must be manually approved and picked up by the devs.

And, the edit were just fixing small typos, not making big changes to the design!
This means that even if it were picked automatically by a bot (like on a bug reports), the first version of the post would still have all the data needed for the internal team

[Mineblo]

+1

[IamSushi]

This is a great FR, I would love to have all mentioned in the post.

I would only suggest a naming change for @units decorator. I would love to have it called @suffix instead (so it can be used on non-numeral types). Additionally with @prefix decorator. Example of usage:

@editable
@display_name("Condition")
@prefix("If")
@suffix("Then")
XYZCondition : xyz_condition = xyz_condition.Default

[Sprintermax]

I also think the “units” naming is a little weird, I just used it as-is since it’s an already existing attribute internally with functionality already working

Also, there is other internal attributes that would be amazing to have that I did not mentioned on the initial post. An example is @sort_priority to explicitly tell the order the editables should render on the editor (instead of following the order defined on the code. Specially useful when dealing with subclasses and instancing)

[im_a_lama (LAMA)]

While I understand your request, I hate attributes personally, some languages use them to much and I don’t think it increases “readability” at all, generally, I feel like it’s always better to raise a concern without providing a solution.

@Sprintermax

Currently we can only hide classes that are <abstract>, but that limits other usage, such as preventing us from creating internal instances of it in code too.

Do you have an example where an <abstract> class is not enough here ?

[Sprintermax]

This feature request was not focused on readability or avoiding cluttering the code. Like I said on the original post, the ones that I mentioned are already existing features that is just not exposed for us creators…

I did not wanted to redesign the implementation of these functionality, so I kept it all how it already works internally on this request. I understand that it can make some parts of code cluttered and that not everyone would like it being this exact way, so feel free to suggest a better syntax or alternatives for it!

About the <abstract> limitation, imagine having internal classes inside the code that you want to instantiate internally but not wanting to expose to the user. The abstract keyword is to limit and define behavior on the code, and not usability or access control, so it is not the best way to do it. If we use abstract just as a filter, we would need to do other workarounds such as making different classes hierarchies and copying properties between the internal and public ones to avoid exposing them, and consequently creating more noise and duplicated code…
Also, since abstract is class-related, it would not work on some scenarios outside classes, for example, avoiding exposing specific internal enums such as this example:

verification_method := enum {
    @hide_in_editor
    ConditionUnset
    CheckIfAll
    CheckIfAny
    CheckIfAtLeast
    @hide_in_editor INTERNAL_ALWAYS_PASS # can be inline too
    @hide_in_editor INTERNAL_ALWAYS_FAIL
}

Again, I undestand your concern about readability and noise on the code, but I just mentioned the already existing attributes without any modifications to it… Feel free to suggest any ideas that you may have, for example being some other syntax such as my_thing<editor_hidden> if you prefer…