BUG? - Enum text treated differently in editor and packaged project

[BrUnO_XaVIeR]

@Podgyhodgy;709017

If what I did was a mistake then why did it run successfully in the editor? And why did it run successfully when compiled without a space?

Because the Editor can read UMeta metadata fields, but packaged games do not include any metadata.

[kamrann]

While I totally agree that in your use case, storing/comparing the enum itself is the best approach, I’d still suggest you report this as a bug on AnswerHub. The fact that it can be explained why there is this discrepancy does not mean that it should be expected behaviour.

Enum-string conversion nodes are not marked editor only, and rightly so (there are valid reasons for doing it, one obvious one is for human-readable/future proof serialization). So it’s reasonable to expect they should behave the same when packaged. Ideally there should be a separate conversion, editor-only, specifically marked as conversion to display string.

[Podgyhodgy]

So, correct me if I am wrong, but what you are saying is that the enum descriptor - ‘Note On’ is purely used by the editor as a label but it actually represents a number. (The number in this case being 0x90) and that the compiler will replace all instances of ‘Note On’ with the actual number. So the string comparison no longer works because the ‘Note On’ descriptor of the enum no longer exists.
This I can understand.
But, in this example, if I use ‘NoteOn’ with no space it fails in the editor as you would expect because it does not match with ‘Note On’ but… When compiled it does work. So, in the packaged project the descriptor (meta data if I have it right) has not gone completely. It has just lost its space.

This question has become academic now because the problem is solved by using the enum variable method prompted by DamirH. But I am interested. That the packaged project contains no metadata does not seem to me to fit the behaviour exactly. What am I misunderstanding or is it a bit strange?

Thanks for your time.

[kamrann]

At the C++ level, enums are indeed essentially integers that have text identifiers, and these identifiers only exist at compile time, not runtime.
There are two independent levels of associated data on top of this with UE4 enums however.

The first comes from the reflection system - the string identifier for each value in a UENUM is associated with its value; this information is embedded into code generated by UE4’s build system and is available at runtime in both editor and packaged builds.

The second is metadata (UMETA in this case), which is added on top of the reflection data, but is stripped out in packaged builds.

It would seem (based on info in this thread) that the enum to string conversion node is probably using the DisplayName metadata for each value that has it, but falls back onto the name in the core reflection data (the string of the enum identifier) both for values which don’t have DisplayName metadata specified, and also packaged builds.

[Podgyhodgy]

Thanks,
That has helped a lot.