I have separately tested each of the widgets outside of the level they are called in successfully, but when I call them in the level blueprint together, they always crash the editor. I receive the following stack of errors:
Essentially what I am doing is picking the sex of my character before passing it into the character designer. The sex is bool, 0 male and etc… the value returned from the GUI/UMG is passed into a variable in the level blueprint and then called again to determine which model should be visible (male or female).
I’ll post a video of the blueprint (since it is big) so you can scroll through it and see everything.
I think epic is trying to get us to engage with the rest of the developer community more. I’ve gotten a few of these emails myself.
Anyway is it absolutely necessary for you to call on the widgets via level blueprint? I noticed I was trying to do something similar to you by passing variables to the level blueprint from UMG, and solved all of my problems by moving everything to the default player controller for the level (if you didn’t designate one, best do so now).
I’ll be honest, I didn’t take a look at your video but I will once I get off from my job.
Well here in lit the problem with the player controller option. When I tried to assign a player controller to the widget or any other function calling for the user index, I receive an error every time I reference self. If i leave it blank, it works (compile) but doesn’t execute correctly (IE nothing happens because the player controller in question hasn’t been referenced) So of either method, the only thing I can think of is that there is something causing the blueprint to crash the editor between deleting a widget and then making a new one. I think I will just make a widget containing all of the gui interfaces and just hide elements. But this doesn’t solve THIS problem, if it is indeed a problem… which I would still like to find out regardless and save myself the trouble up the road if I encounter it again.
Well here in lit the problem with the player controller option. When I tried to assign a player controller to the widget or any other function calling for the user index, I receive an error every time I reference self. If i leave it blank, it works (compile) but doesn’t execute correctly (IE nothing happens because the player controller in question hasn’t been referenced) So of either method, the only thing I can think of is that there is something causing the blueprint to crash the editor between deleting a widget and then making a new one. I think I will just make a widget containing all of the gui interfaces and just hide elements. But this doesn’t solve THIS problem, if it is indeed a problem… which I would still like to find out regardless and save myself the trouble up the road if I encounter it again.
Not an answer - but some advise to reduce the impact of these kind of problems
I backup my development area every day
I have a ‘blank’ level on entry into the editor. I then load the level I want to work on. If it crashes, I can check the logs.
On Crash I can then reopen the editor (back to the blank level) and attempt to fix the problem. A lot of problems stem from compilation errors that only occur on level load. (Hence the blank level) I can open the blueprint in the blank level and compile \ fix the problem.
Some typical problems.
Cyclic references. If I have two blueprints that reference each other compilation fails at some point in the futu.re Be careful how you build your scripts.
Moving stuff around. It may ‘seem’ to work, but often stuff has not recompiled until level load. You then sometimes need to reassign the objects that cause problems. (You load the blueprint mentioned in the log and look for the error amongst the constructor \ event graphs)
Animation can be very dodgy when you have two blueprints open together. Save every step of the way.
Save BEFORE compiling anything. At least you do not loose your work on crashes.
Alright I have the answer, and I regret to say it is completely my fault. In the widget blueprints I was loading and unloading a level everytime the blueprint was executed. I simply stopped the level from being loaded and it worked just fine. Doah.
I’ve since just created a single GUI interface that uses animations to move and hide all the content I load and unload excluding the levels.And to no surprise, it also runs much smoother now.
you can see it as a supplier that keeps sending a heavy book, you can manage one, but if it keeps sending books you’ll be soon flooded by books and simply collapse because of it (just be careful with what you load/are doing)