I was testing latest additions to my settings menu, which is full of various custom ENUMs.
Everything was working fine so I saved and moved on to trying to get some PostProcessVolume related stuff working.
I loaded between two maps a couple times to check and compare variables, make changes, save, then playtest.
Afterward I returned to first map I was in.
Upon attempting to playtest, editor informed me that two blueprints were not compiling properly.
Upon checking them I noticed that every single custom ENUM in both blueprints had been converted into bytes.
I was able to change them back to custom ENUMs without problems and after some work project was properly playtesting again.
only thing I messed with between project functioning and ENUMs deciding not to be ENUMs, was Film>Saturation, Misc>Blendables array, Misc>ScreenPrecentage, and Misc>AAMethod.
Unfortunately I am unsure of exactly when bug occurred, as I did not immediately notice problem and failed to take note of order of those changes. I also stupidly closed editor and recompiled my C++ code without thinking to check editors output log first.
If there is any existing information on why this would occur(so I can try and prevent it in future) I would much appreciate it.
Enum values are actually bytes. Do Enum nodes now look like ones reported here?
If so, that’s a known issue (UE-12550) that has already been fixed internally, and fix should be included in 4.8 release. Please let me know if you experienced something different. Thanks!
It was in Details Panel > Variable Type where problem was showing.
Instead of being my custom ENUM it was a byte, which was only a problem because I was trying to use Enum To Name node to “return friendly user name of enumerator”.
Ah, okay, I understand now. So it’s actually changing variable type from Enum to Byte? And this only occurs with custom Enums? Did it happen with all of your custom Enums, or only some? After you fixed them and closed editor, did they remain fixed when you reopened project? I haven’t been able to reproduce this, so any other details you can remember would be helpful. Thanks!
I can’t say if standard ENUMs would be unaffected as I was only using custom ENUMs, and unfortunately did not think to check inherited standard ones.
It was only ENUMs in two blueprints that failed to compile, but it was all custom ENUMs in those two blueprints.
Oddly I have same type of ENUM variables in several other blueprints(that interact with two that failed), but their variable types were not changed.
I also have several more blueprints with a whole different set of custom ENUMs that were also unchanged and fine.
Yes, after fixing them they remained fixed after reopening project.
only other details I can recall, atm, is that custom ENUMs were declared in C++ and are apart of a custom structure also declared in C++.
If I remember anything else I will post here.
I will also try to remember to check output log first thing if it occurs again.
Okay, thanks. Just to be sure, I also tested with an enum as a part of a struct, switching between levels and adjusting properties in a PostProcessingVolume, and still couldn’t reproduce. Hopefully this was a one-off occurrence, but please do let us know if it happens again. I’ll resolve this post for now, but we’ll reopen it if you get some more information or if we’re able to reproduce it here. Thanks for report!
Are you compiling with editor open? Do enum types change if you compile with editor close and then open? Are you using code based enums inside of structs? Please provide as much detail about your case as you can to help me understand how this may have come back up again.
Yes. No I don’t believe so. All of them are UE4 enums in C++ like so:
UENUM(BlueprintType) enum class EMonsterState : uint8
It only seems to break some enums, probably only classes that use enum’s that get recompiled from VS. Weirdly all of my enums are in a “utility.h”
header file but not all of them break when recompiling.
I was able to reproduce this issue and have submitted a bug report (UE-19528) for further investigation. Though it is a tedious workaround, it is possible to duplicate enum node in blueprint and use duplicate as a replacement to fix blueprint.
As a faster workaround, I hit RefreshNode on “bugged” nodes and compile BP!
Same problem happens to me when I hotreload so I tend not to use hotreload anymore when working on this particular BP (containing “bugged” enum).
Problem might be related to creating a BP with an enum (defined in C++ in my case) UPROPERTY and then changing (adding/removing/inserting/renaming?) values in enum afterwards. Not sure about all exact causes for this bug but maybe it will help to track it down completely…
My version is: 4.8.2
I had also that kind of warnings when starting editor so I decided to recreate “bugged” BP from scratch (and without modifying enum in C++ anymore)…
LogEnum:Warning: Enum Text OldEnumValue for Enum EMyActorState failed to resolve to any value
I come here to say i also came across same problem and thought people may need more info.
Same things happens to me after i compile code and UE hotreloads. An easy solution is to restart engine, instead of reconnecting nodes(especially if you have many nodes connecting)
