Instance-editable FText on a BP component resets to None when assigned a string table entry with an empty source string

Development Pipeline & Plugins
, ,
1

I tracked down a bug where assigning a string table reference to an instance-editable FText reverts to None. It only happens when the referenced entry’s source string is empty. Since the string table picker auto-assigns the first key in the table when you select one, any table whose first entry has an empty source looks completely unselectable: you pick the table and the property just snaps back to None.

It only happens when the FText lives on a component of a Blueprint actor and is edited on a placed instance. Actor-level BP variables and native actors keep the same reference fine.

What I think is going on: the property set itself succeeds and the value dies afterward. PostEditChange on the placed actor reruns construction scripts, which rebuilds the component and round-trips the instance-edited properties through the instance data cache. During that diff, the null-default overload of FTextProperty::Identical treats any FText with an empty display string as identical-to-default (it effectively returns GetDisplayString(A).IsEmpty()), so the freshly assigned reference looks unchanged-from-default and gets dropped. That’s consistent with actor-level variables and native actors surviving — they don’t go through the construction-script instance-diff path. The auto-pick behavior comes from STextPropertyEditableTextBox.cpp (“Just use the first key”).

The annoying part is that an empty source string is legitimate data (placeholders, entries pending translation) and the namespace/key identity is meaningful regardless of what the string resolves to. The loss is silent (no warning, the value just reverts), and when the empty entry happens to sort first in the table, the whole table looks broken in the picker. That’s how our content team first hit it.

We already have workarounds in place for this (like setting the text somewhere else, copying the value, and pasting into the component), but I believe this is a bug that should be addressed.

2

Steps to Reproduce

Attached is a minimal repro project (LocTextAssignmentBug.zip), created in vanilla 5.8.1. It contains one map with two Blueprint assets and a string table.

  1. Open TestMap. It contains a placed BP_TextActor (a Blueprint actor with a BPC_TextComponent ActorComponent that has one instance-editable FText property).
  2. Select the placed instance and find the FText property on the component in the Details panel.
  3. Open the string table picker on that property and choose ExampleStringTable. Its first key, FirstString_IntentionallyBlank, has an intentionally blank source string.
  4. The picker auto-assigns that first key, then the property immediately resets to None. This is the bug. Because it fires the instant the table is selected, you can never even reach the key dropdown to pick a different key on this field.
  5. For contrast, try the same table on an FText that doesn’t live on a BP component, like an actor-level Blueprint variable, or a native actor like a TextRenderActor. There the table selection sticks (even with the empty first key auto-assigned), and you can switch the key to SecondString normally.

To reproduce from scratch instead: make a Blueprint ActorComponent with an instance-editable FText, add it to a Blueprint actor, place the actor in a level, and assign it a string table whose first key has an empty source string.

3

Hi,

Thanks for the report/repro project, I’ve updated FTextProperty::Identical to handle this case properly by returning false if checking a string table entry against nullptr. You can grab that at CL#56859938. I appreciated the hidden message in the repro project!