Extend the EditableInterface with two new BlueprintNativeEvents so property
combos can show human-friendly labels while storing technical values:
- GetCustomOptionsWithValuesForProperty returns TArray<FPS_Editor_PropertyOption>
where each pair carries a DisplayName (shown in the combo) and a Value
(written to the property via ImportText). Wins over the legacy flat-string
variant when non-empty. Ideal for TSubclassOf / TSoftClassPtr properties
driven by a DataTable lookup where the stored value is a class path.
- GetCurrentDisplayForProperty lets the actor authoritatively resolve the
DisplayName from the current stored value, for cases where the automatic
reverse lookup (normalize class path, exact-match) isn't reliable — e.g.
several Values collapse to the same label, or the format is user-specific.
UI refresh now asks the actor first, then falls back to a normalized match
(strips the `TypeName'...'` wrapper from ExportText output so it compares
apples to apples with a plain /Game/Path.X_C string).
Same logic duplicated across both widget implementations (MainWidget and
MainWidget_Legacy) since the project can switch UI mode at runtime. The new
CLAUDE.md rule makes that requirement explicit.
Also documented in CLAUDE.md:
- Editor-vs-gameplay execution boundary: which interface methods fire where,
including the gotcha that OnEditorPropertyChanged *does* fire in gameplay
on the server when the timeline animates a property.
- UI modes: keep all MainWidget* implementations in lockstep to avoid the
"I edited the file but nothing changed" class of bug.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
j.foucher
bc491b7b94