[Feature Request][Complaint/Frustration] Blueprints/UMG unusable...

Skip to the TLDR; for feature request.

I’ve been using UE4 since 4.1, and one of the main drawing points to it were Blueprints, and the editor in general. I’ve done some objective C programming for iOS, and been able to create games using just code, but the process was slow for a single indie developer like me, so I wanted to get into something like Unity or Unreal. As an indie developer I don’t have unlimited resources and time. I don’t even get to spend 8 hours on my game a day as a I have a full time job - so even as a programmer, Blueprints and UMG have real appeal to me. In the long run I was hoping the editor would be able to help people like me create more faster.

I was wrong, at least for Unreal Engine 4 as it currently is. I need to set some parameters with my complaint before continuing though: I am primarily focused on mobile / iOS development so I can only speak from my experience with UE4 in this narrow area.

When I first began developing with UE4, I used blueprints the most with C++ when there was something blueprints couldn’t do. This worked at first, but I encountered alot of time costly pitfalls. First of all, renaming things could be dangerous, as in blueprints could become unusable. As in if you tried to open them, the editor would simply crash - ungracefully I might add. At this point, your blueprint is complete junk, no matter how much time you spent on the blueprint, and sweat and tears, he’s dead. Give up on him, and then rebuild him from scratch. This wasn’t TOO bad, as blueprints are fast, but still, when it happened at least for me 5 times, or more it becomes depressing.

But that’s not the only issue, the worst issue is, my game works beautifully in the editor, then I go to package it to iOS, and then it crashes instantly. The cause? Usually somewhere in the Blueprint Linker/Loading phase! Again, works fine in editor -> but on iOS device just dies. I’ve came across this a few times, but unfortunately, its really hard to reproduce in a new blank project the preferred (and appears the only way to report issues). It appears the issue is related to Blueprint corruption as they usually crash because some variable its trying to serialize isn’t there (presumably). However, there isn’t anything I can really do about that. Blueprints are blackboxes, they get serialized into mostly bytecode, I can’t just open the file and fix the issue or even look at it. I could try to pretend I know Unreal’s blueprint underlying system like the people who wrote it and just start making changes to the engine where I see it crash and perhaps make the issue even worse in the long run.

Eventually, I got so frusturated, and so sick of wasting time of endless deleting blueprints here and there until I figure out where the issue exactly is, I just gave up on blueprints, I converted them all to C++, this set me back a couple of weeks but wasn’t the end of the world. Still its one of those big features I wanted to use UE4 for, that I have had to abandon.

Then comes UMG… I continued to use Blueprints there, because as many people know building an interface from C++ code, is alot like how building interfaces from the WinForm days were. Its not fun, and with the long compile times, and load time of the editor, it can take forever just to test a new change. So UMG was a godsend, until, the same issues with normal blueprints, seemed to persist there way to UMG for me in 4.6.1. Once again, UI looks great in editor, and for a long time it looked great on iPhone to, until it didn’t. Just eventually, it started to crash. I traced it to the all and great Blueprint linker, it was expecting to serialize some sort of GenerationInfo struct from the file but instead crashed on memcpy, presumably because the data wasn’t there or formatted correctly.

Of course I post this issue on the answers, but you know it comes down to being able to replicate this issue, and how do I replicate file corruption? and you can’t just drag the same widget into an empty project without basically moving everything else with it.

I don’t know how blueprints get corrupted…maybe its the ungraceful crashes that happen in the editor FREQUENTLY. Maybe it happened while upgrading between difference releases… I don’t know, but I’ve given Blueprints between 4.1 and 4.6 a real hard chance, and as far as I’m concerned, I’m done with the pieces of junk.

**TLDR; **I think one thing that could be beneficial, is if there was a ‘human readable’ version of blueprint files, like xml or json. Obviously, this would make files alot larger, so it should be optional, and obviously when the program goes to cook it could convert them back to byte as they are now. But if we had human readable versions of files, corruption issues like this would be alot easier to trace…and blueprints that become unopenable might be able to be fixed. As it is now, they are blackboxes, if there are any issues with them they are basically junk and you lose everything forever end of story. There might be issues with this idea… I don’t know. I don’t want to blame Epic Games, because they have done a great job with all the work they’ve put into UE4 but I’m out of ideas and this is a real problem as an indie developer.

As Blueprints are today (and UMG blueprints by extension) I couldn’t recommend anyone use them period. I honestly believe if you are making a game of any substantial size that everyone use C++. The pay off is a lot better in the long run. If you get crashes you get a real line number to a real issue you can solve. With blueprints or any of the epic generated files you get a big stack trace deep into the engine source and at that point your blueprint is probably long gone and trash anyways.

Hi Awdogsgo2heaven,

Thank you for your request, I have entered a feature request, UE-8618, to be considered by the development staff.

I have to second this.
I have redone my game from scratch two times due to backwards incompatibility with blueprints and REINST messes around (using promoted unrecommended branch several weeks ago). This is a PITA and we need ways to recover this kind of disasters.

Only advice I can give you is to avoid fancy stuff in blueprints, for example instead of calling EventDispatchers from UMG, just call BP events (you need a BP which will act as event handler passed in construction or somewhat). Do not pass references around within UMG since it can lead to dreadful REINST. Do not instantiate directly UMG custom widgets inside containers from the Designer because It can also lead to REINST stuff, I instantiate them in Construct event instead.

Right now I just do not make any upgrade and still working with 4.6.0 :confused:

As said by the OP, we need a way of recovering from disaster!


I agree completely. I started doing most of my iterative tasks in blueprint while using C++ for “infrastructure” functionality that doesn’t need to change too often. It was really fun and I managed to get the results I wanted pretty quickly. Then came UMG and it was a delight to have WYSIWUG. But then came the Blueprint and UMG bugs. So much, in fact, that I’ve tried (and failed) three times to upgrade from 4.5.1 to 4.6.1 and gave up. Tons of Blueprint compilation errors that didn’t exist in 4.5.1 and lots of crashes if I try to fix them. I even got blueprints that crashed because 4.6.1 somehow replaced some nodes with NULL pointers, something the compiler definitely didn’t expect to happen.

Also, the blueprint editor has little regard for preserving your work. There are some actions that result in pins being disconnected across multiple blueprints without notice, like changing a function/event input type, forcing you to manually hunt down all references and perform the changes. Deleted a variable? All references to it in the same blueprint will be deleted as well, leaving you with no idea of where to look for. Ideally the connections should be preserved and the blueprint should simply fail to compile in all cases, just like your C++ code won’t magically change if you make a change somewhere else.

Hi everyone,

I have entered the feature request as mentioned above, in the meantime, please keep in mind that there is a backup folder in your saved folder for the project. You should be able to pull older versions of blueprints from there if a change corrupted a specific blueprint, you can replace it with a saved backup by moving the backup to the location of the original blueprint within the filepath. Hopefully this can help you in the meantime to prevent losing too much data.

Also everyone should use a version control system, GitHub, Perforce, Subversion. Even if blueprints never became corrupted, it’s just a good workflow to have.


If the issue doesn’t occur until after packaging it can be a long time until you realize it and just restoring files is not really an option. If it occurs because of c++ code changes , restoring back ups also won’t help you.


Any news on UE-8618. I didn’t find a status with a google search.
Having blueprints in a human readable format is also great for source control and collaboration. Having just a binary asset, excludes merging.
Copy-pasting nodes in blueprints is just text. It doesn’t have to be pretty, it just has to merge :slight_smile: (probably the nodes positions would have to be separated in a table or something to avoid diffs for cosmetic changes)

The status is won’t be fixed Unreal Engine Issues and Bug Tracker (UE-8618)

Thanks for the quick reply