@editable and the Details Panel: Let Artists Tune Your Component

1. Where It Goes and What It Means

@editable is an attribute: it starts with @, occupies its own line, and sits above the field it modifies. That's a different syntax family from specifiers like <public> and <final_super>, which live inside angle brackets. Don't blend them.

lift_platform_component<public> := class<final_super>(component):

    @editable
    Height<public>:float = 200.0
#   ▲          ▲       ▲      ▲
#   attribute  access  type   default (required)

Adding it does three things: the field shows up in UEFN's Details panel; the value written in code becomes the panel's initial displayed value; and when the component is attached to different entities, each copy can hold a different value. The official wording on that last point is blunt: changing an editable property's value only changes it for that instance — five copies of the same component in a level can hold five different values. And editing the panel requires no recompile.

Those three points together are exactly the semantics of Blueprint's Instance Editable. That little eye you light up next to a Blueprint variable has become one line of text in Verse.

Conversely: a field without @editable is purely internal data and simply doesn't appear in the panel. That's a design discipline in itself — expose only what genuinely needs tuning by someone else. Dump your whole internal state into the panel and your designer, faced with twenty boxes of unknown consequence, will just come ask you anyway.

2. Which Types Can Be Exposed

Here is the official list of editable types. Note the recursive condition on the containers and structs tier: whatever is inside must also be editable, or the whole field never reaches the panel.

Hold that table next to Blueprint's Variable Type dropdown and the coverage almost lines up: boolean, integer, float, string, enum, array, map, struct, object reference. Nearly anything you'd tick Instance Editable on in Blueprint can carry @editable in Verse.

The class-instance tier is the closest analogue to Blueprint's "Actor reference variable": in Blueprint you'd declare a Target Door variable typed to some Blueprint class, then eyedropper a specific door in the level. In Verse you give the field a class-instance default value, and the same reference slot appears in the panel.

3. Variants: Putting Guardrails on the Box

A bare @editable hands over an unguarded input box — a designer can type -99999 into Height. In Blueprint you'd set Slider Range and Value Range in the variable's Details; in Verse you switch to a more specific attribute variant instead. The main variants in the official docs:

Syntactically, these variants take a colon and the config items are indented underneath — consistent with block structure everywhere else in Verse:

guarded_component<public> := class<final_super>(component):

    # Slider: 0.0 to 10.0, one step per 1.0
    @editable_slider(float):
        MinValue := option{0.0}
        MaxValue := option{10.0}
        SliderDelta := option{1.0}
    Speed<public>:float = 1.0

    # Numeric field clamped between 0 and 10
    @editable_number(int):
        MinValue := option{0}
        MaxValue := option{10}
    Lives<public>:int = 3

Note the bounds use option{...} — the optional values from Lesson 18: you can set a lower bound without an upper one by writing only the MinValue line. That's a touch more flexible than Blueprint's two Range pairs, which want both boxes filled.

4. Categories and Tooltips: Making the Panel Presentable

Once a component has a lot of parameters, the panel turns into soup. Blueprint's fix is filling in Category and Tooltip on the variable. Verse's fix is the same, except the text has to be declared as a message first and then hung on the attribute:

# Category name and tooltip text, declared as localizable messages
MotionCategory<public><localizes>:message := "Motion"
HeightTip<public><localizes>:message := "How high the platform rises, in centimeters"

tidy_component<public> := class<final_super>(component):

    @editable:
        ToolTip := HeightTip
        Categories := array{MotionCategory}
    Height<public>:float = 200.0

<localizes> is the localization specifier: text marked with it enters the translation pipeline, so panel labels can follow the user's language later. That's more disciplined than Blueprint, where a Category is a raw English identifier that never gets localized.

Categories takes an array, so one field can belong to several groups at once. The practical pattern: one category constant per functional axis, declared together at the top of the file, with each field hanging off whichever it belongs to.

5. Defaults versus Overrides: Who Wins

This is the section that causes the most misunderstandings, and the one most worth memorizing.

• ▢ The value in code is the factory default. Writing Height:float = 200.0 means "when this component is freshly attached, the panel shows 200". It does not mean "it is always 200".
• ▢ The value in the panel is that copy's override. Official wording: the change applies to that instance only. Attach the component to five entities and the five copies never interfere.
• ▢ Editing the panel needs no recompile. That is the entire value proposition over "a constant in the code" — designers change numbers without a programmer in the room.
• ▢ Changing the code default does not retroactively fix instances that were already edited. Watch this one closely: after you change the default from 200 to 300, instances in the level that were manually edited keep their own values. To move everyone, either edit each panel or route around the field in code. It's exactly the trap where changing a Blueprint variable's default value doesn't overwrite the Details panel of already-placed Actors.

Which yields a practical rule: write defaults that produce a correct-looking result when nobody fills anything in. A default height of 0.0 or a default name of "" just makes whoever attaches your component first assume it's broken. Giving every editable field a self-evident default is the most basic courtesy you owe a collaborator.

One more comparison carried over from Lesson 27: Blueprint variables also have Expose on Spawn, and Verse has no switch by that name. To pass parameters at spawn time, assign the field directly when constructing the instance — for example lift_platform_component{ Height := 300.0 }. That path and the Details panel are two parallel ways to fill a value; they don't conflict.

Sources

Compiled from Epic's official documentation:

• Editable Properties in Verse (official docs) ↗
• Creating Your Own Component using Verse in UEFN (official docs) ↗

The exact config options on each attribute variant get extended release by release; check the official docs of the day before you build.