During my refactor I made the mistake of not using a pointer when adding a UGoKartMovementComponent member variable to AGoKart. This compiled fine, but when I opened the editor it would immediately crash with an error about a constructor being called on the stack. This is because the actual object creation of my UGoKartMovementComponent was being done improperly, as the error stated (note, however, that the error was a bit vague and didn’t exactly point to UGoKartMovementComponent. More on that below*). To get the editor to open again, I had to fix the code so that UGoKartMovementComponent was a pointer and add the call to CreateDefaultSubobject in AGoKarts constructor. However, I also had to delete the Binaries folder in the project directory. This will prompt you to rebuild the project when you reopen the editor, and all was happy again.
It’s a bit of a hassle, but makes sense. Basically, I had created a bug that occurs in the setup code which the editor will run at startup (or reload). Because I can’t stop the editor from doing this, it would immediately crash. There are other ways a bug can be introduced that has the same symptom. The general process for fixing these sorts of things should be:
- Identify the bug in code
- Fix the bug (or at least remove the problem code to get back to a working state)
- Delete the Binaries folder in the project directory
- Reopen the editor
This should fix the problem if you end up with the UE editor crashing at launch. If anyone has another approach or process, please let me know! I’m also here to learn.
* If you get a vague error message in a crash report that doesn’t directly point you to a line of code like many compiler errors do, it’s always a good idea to step backwards through what you just changed. In this example, I got an error about a constructor being called on the stack, but it didn’t specify what or where. This was an easy one to track down because there was only one place this could have been in my recent changes: the UGoKartMovementComponent member variable. However, things might not always be that easy to track down. My advice in general is to make the smallest effective changes as possible and test between each change. Sometimes with refactoring (like in this lecture), it can be difficult to test anything until the refactor is done and you’ll have to use the breadcrumbs given to you in vague error messages to find the issue. Google can also be your friend.