I have a project where I compare a string from an enum using function string(equal).
The enum is the Event Type from an onMIDIEvent (though I suspect this is nothing to do specifically with midi)
The enum translates to a message :- ‘Note On’ or, ‘Note Off’
When I compare in the editor I must use ‘Note On’ with a space or it does not work - but this does not work in the packaged project - neither development or shipping.
If I change the compare to ‘NoteOn’ with no space then it does not work in the editor but does work in the packaged project.
The attached image shows what works in a packaged project.
Furthermore, I notice that when I save the message as a variable and display in a widget textbox the editor version shows ‘Note On’ with a space and the packaged version shows ‘NoteOn’ without a space. Noticing this is how I came to solve the problem. Seems like it may be a general thing with strings and spaces?
This is not a bug. Meta data (i.e. string display names for enums) are an editor-only thing.
But even if this was not the case, the approach you are doing is incorrect. You should NEVER do enum - string comparison, and if you structure things correctly, you should never have to do string comparison in the first place.
Thanks for your response. I can compare the integer value of course but the string is there and makes it more readable so thats what I used. I am interested in why you are so insistent with your capitalised never? I don’t see why it should really be a problem. A bit more processor time but what else? Surely there are cases where you may want the user to type text in and then string comparisons and parsing are unavoidable? Entering a username or password for example off the top of my head?
Strings can have typos and string comparison is extremely slow. Even with usernames and passwords you’re comparing hashes, not the raw values. My point was mostly due to the fact that there is no reason to compare strings. Looking at your BP I’m going to take a wild guess and assume that you’re a Unity users who’s used to their messaging system? It’s an extremely unsafe way to call events due to the hard-typed nature of strings. If you want to refactor an event you can’t because that string literal is being used in 15 different places etc etc.
The Event in question is an OnMIDIEvent that fires when a midi message arrives from a midi device plugged into the computer. And the Enum in question is part of the message that the event is signalling. So, I don’t have any choice either in the Event or the data format. The Enum is for the ‘Event Type’ which are integer values as defined by the midi protocol. Whoever created the midi device support plugin for unreal decided to be nice and use an Enum to translate the Event type integers into friendly text. Thats why the messages say Note on and Note off - midi is musical instrument digital interface. The message types are fixed and there will never be any new ones added so rejigging will never be an issue.
I used the string compare because when I tried printing the Event type it was automatically converted to the Enum string. I Know the Event type as an integer but I went with the conversion - easy to read and not such a processing burden as all that. I wasn’t expecting that the editor and the executable would treat the string differently - After all, it is unreals’ blueprint that has done the conversion to string so why should it be different in the two situations.
I didn’t create my own Enum because I am only using Note On and Note off at the moment.
I’m not from Unity. I am a process control, interfacing, microcontroller sort of person who is interested in making some realistic helicopter controls to interface using the midi protocol to operate my sons mi-24 helicopter model https://www.artstation.com/artwork/3P8eA
Well you are currently converting the enum to a string, storing it in a variable and then comparing that variable to a hard-typed string. Why not just store the enum and compare it with an enum? No need for any conversion at all. Just store the enum in an enum variable and check if it’s equal to the enum you want.
Enum its just a single byte of data, engine/c++ interpret each value 0-255 and give you friendly name for it, but it’s still a number and you can compare numbers, in blueprints, there are node "byte == " which accept bytes and enums.
Thank you very much DamirH. I have only been using Unreal for a couple of months and it had not caught my eye that enum variables were even possible. I have re-arranged things and now everything is behaving very nicely. I still have a nagging feeling that, despite being clumsy, my first effort should not have caused the error I got but I won’t lose any sleep over it and will never go there again.
Thanks to all who have taken an interest and contributed to solving this. Now, about the bug when posting a reply and the update hangs…
To help alleviate confusion - the engine stores variable metadata in variables for reflection purposes. In the case of enums, it generates a friendly display name. This is however only for the purpose of the editor, it gets stripped out of the packaged build so you get the “raw” name, causing your issue.
CriErr - I appreciate your advice but I have been progamming in assembly language and C on microcontrollers since 1978. C++ didn’t even exist back then and besides, microcontroller intefacing doesn’t really have much use for higher level data structures. But I have written some C++ for my own amusement including a midi application using the windows midi api.
My main thing at the moment is, having only used the engine since march, finding out about the unreal interface specifics but thats coming along. I have the helicopter flying using physics to model air density with altitude/ air drag and the lift equation and am using physics to control it so its behaviour depends on its mass, coefficient of drag etc. I have also built a prototype controller using a microcontroller to translate the inputs to midi messages. I think in a couple more weeks I should have a decent working prototype of a realistic model with realistic behaviour and realistic controls. At least, thats the plan.
My problem here was that I have never considered an Enum to be a ‘variable’. In my experience it has always been used simply as friendly name placeholders when programming to represent the actual integer values. Yes, you can create instances of an Enum but I would never have described it as a variable.
Still, live and learn. From the conversations/arguments on stackexchange it seems the learning will never end.
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.
Things just break randomly, especially with some third party API or plugins.
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.