I’ve just created a clean project in 4.14.3 using the third person template using this in editor works as intended:
It should return 2 which it does (in editor) but when i package my project in “development” or “shipping” it return -1 every time.
Hello AndrewM47,
I was able to reproduce this issue on our end I have written up a report and I have submitted it to the developers for further consideration. I have provided a link to the public tracker. Please feel free to use the link provided for future updates.
Link: Unreal Engine Issues and Bug Tracker (UE-43645)
Make it a great day
Hey,
What you’re seeing here is caused by the use of FText, rather than the Blueprint function itself.
The issue is: what does it mean to generically compare two pieces of localised text?
Do we compare the source string? No, because two texts with the same source string may have different display strings.
Do we compare the display string? No, because two texts with the same display string may have different source strings.
Do we compare both the source and display strings? No, because while they may currently be equivalent, the display strings may deviate if the culture is changed (an issue for hashed containers).
Do we compare the identity of the text? Yes, because if the text shares the same identity then the text will always be identical regardless of the current culture.
This question is actually the reason why FText has no operator==, however, since all properties need to be able to perform a comparison check, properties of type FText have an equality check based on the identity of the localised text. This is the reason your comparison fails, because the text you’re comparing has a different identity (namespace or key) than the text in your array.
Sadly, due to other reasons, the editor is forced to perform a display string comparison to ensure that property updates work correctly. This is “safe” in the editor as we never load localised versions of authored text (so we don’t really deal with the localisation concerns). It would be great if PIE was consistent with other game-modes (running the editor with -game has the runtime behaviour), however the property comparison happens at a level where we neither know what instance the text property belongs to, nor do we have any knowledge of the editor, worlds, or PIE.
We do have functions exposed to Blueprints that let you lexically compare text (as if you’re using those, it’s assumed you know specifically what comparison you want to do), but I’d also ask you: why are these array entries localised text?
If the text was flagged as culture invariant then it would perform a display string comparison rather than an identity comparison (as there would be no identity to compare). At the same time, if the text shouldn’t be localised, then it would be better as a string rather than as text. Similarly, these are numbers (which I admit may just be an example), so why not an int?
If these are entries that map to a localised display string, then you could use enums in your array, and then map your enum entry to localised text for display.
Basically, there aren’t may cases where searching for localised text was something that was done intentionally. Often it’s a side effect of an odd design, and in that case there are usually better options available 