After successful packaging - Assertion failed Enum

I have packaged my project for Windows 64 bit version successfully, however, when I run the .exe a window pops up.

The game does work in editor and since this is my first experience packaging a game, I have no clue why this is happening. Packaging settings are mostly untouched. Here is the log: [Log][2] I am using a map with enums as keys, as well as other enums that are also put into each other, if that matters. Is there a common cause for this assertion failed error?

Can you post a screenshot of the Enum to Map that you’re using?

The log unfortunately doesn’t tell me much but you could try and go into the Enum file, and turn on serialization and see if that works. Look under the Advanced Options.

Thanks for the answer.

I have now built the game about 40 times (Im dead) and it is VERY weird behavior. It seemingly has to do with world settings of the map. Whenever I set some character as default character OR my own controller blueprint, the error pops up. OR in the case that there is another pawn on the map. No matter what it is. If it’s my player character, my enemy, or a newly made character with nothing in it.

Even when I use the default controller and a newly made character with only the UE4 default mannequin as mesh, the error happens.

I even went as far as making a new branch and deleting EVERYTHING that my own character or my own controller had. No success. If I set None for default pawn and the default controller, I can start the game (provided no other character is on the map); of course, I can’t do anything there but see the level. It’s infuriating, really. I just can’t make any sense of it.

Based on these posts:

https://answers.unrealengine.com/questions/584819/maps-with-enum-keys-crash.html

https://answers.unrealengine.com/questions/574277/uenum-from-uint8-has-no-hash-function.html

I would say that maybe the hashfunction for your map is missing. What are the types that you are using to make your Map? If you can explain in more detail what you’re trying to do, then I might be able to come up with a different way of doing it.

I do not believe that my map is at fault, because my game ran fine in editor, always, while those posts of yours indicate error even in editor. I also have removed the map and any enum associated with it and the error still popped up… in any case, it is a map with enums as keys and bools as values. I use it to declare certain types of actors enemies. “Player - yes”, “Neutral - no” and so on. When detecting an enemy, the AI agent looks into its map, goes through all its keys, looks up the value for each key and IF the value is true and IF the key equals the affiliation of the could-be-enemy, he is declared an enemy to attack.

EDIT: This is made in blueprints, by the way.

In any case, when I have a level without my actors on it, it works. When I have a level with one of my actors on it, even if only a new one (no added variables, no new components, just a fresh character), this error pops up.

By the way, one weird thing I have noticed: I have a component called RagdollComponent. Often, when I package the game, I see two lines: “Couldn’t find variable “IsInRagdoll?” and “capsuleComponent”” or similar, which is weird, because it indeed doesn’t have those variables anymore. They have been renamed since long ago. This isn’t responsible for the error as I have been able to start a packaged game even with those warnings, but it’s weird nonetheless.

I got it! It’s definitely a bug and should be fixed asap.

The error lies within the EComparison Method enum and struct interaction.

Steps to recreate:

  1. Create third person (should work with blank, but only tested with third person) project.
  2. Create Struct with single member of “EComparison Method” enum
  3. Open ThirdPersonBP (or any actor blueprint on the map)
  4. Add variable of the struct
  5. Compile the actor BP, set some default value, doesn’t matter
  6. Package win 64 development build (tested only that one), start the .exe, watch the crash

This has cost me about 17 hours of debugging (trial and error really…) to track it down. I hope the staff will notice this and put it onto their list to fix.