Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Another useful info is probably that internally the engine stores enums as 8-byte unsigned integers. Hence why in C++ the standard namespace enum is deprecated (as far UE4 is concerned)

    The norm in UE4 is this:

    Code:
    UENUM(BlueprintType)
    enum class EMyEnum : uint8
    {
          OPTION_A      UMETA(DisplayName = "Option A"),
          OPTION_B      UMETA(DisplayName = "Option B"),
          MAX                UMETA(Hidden)
    }

    Comment


      #17
      Originally posted by CriErr View Post
      You might want to go over simple c++ 101 youtube few hours tutorial series, so you actually understand how programming works and possibly even convert to a dark side of c++
      Brutal and not helpful..! Especially giving his actual experience with C++.

      teak
      "A little bit of nonsense now and then is cherished by the wisest men..."
      -- Willy Wonka

      Smooth Zoom Camera Plugin for 4.24 here.

      Comment


        #18
        Originally posted by teak421 View Post
        Brutal and not helpful..! Especially giving his actual experience with C++.

        teak
        How is that "brutal"? Enum to string and compare strings its rookie mistake, also I didn't know any background.

        Comment


          #19
          CriErr,

          Just to be clear, I understand that you know nothing about me and I am not in the least bit offended but I have a question. 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? You may say that it is sub optimal but it was accepted and compiled.

          There seems to me to be something quite subtle and, unreal specific, in the stripping of spaces. It is not something I have come across before.

          Besides, Enums and strings are not quite as simple as you imply. I refer you to this thread which is one of many. http://stackoverflow.com/questions/5...le-to-a-string

          Even if I were a complete beginner your advice to watch a few introductory videos on basic programming would not answer this question.

          Comment


            #20
            Things just break randomly, especially with some third party API or plugins. Click image for larger version

Name:	dunno.gif
Views:	3
Size:	3.0 KB
ID:	1128074
            Right now I have a task to find out why the game crashes on connecting to steam session in build version but appears to be working great in Play in Editor standalone, but I still would go over functionality there and check is really working as intended.

            Regardless link, I've read that post year ago and after that, I dropped the idea of it for my pet project and accepted the way of someone else engine where everything is done for me and I do agree, that your problem is really specific edge case of which you know or it straight up doesnt work and you dont know why.

            Comment


              #21
              Originally posted by Podgyhodgy View Post
              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.
              | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

              Comment


                #22
                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.

                Comment


                  #23
                  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.

                  Comment


                    #24
                    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.

                    Comment


                      #25
                      Thanks,
                      That has helped a lot.

                      Comment

                      Working...
                      X