This seems like it may be an issue of a null reference somewhere in your code, but I can’t tell where as these are just the exceptions thrown. Can you hit the “Break” button and provide the callstack for these occurrences? It may be helpful to comment out your most recent changes to see if something recently added may be causing the issue.
Edit: Also moving this out of Bug Reports for the time being, as it seems to be a project related issue rather than a bug with the editor.
The callstack should be under the “Call Stack” tab at the bottom left of Visual Studio after you select Break. Also, if you’re unable to get any information from opening the project via debug, can you try compiling it for Development Editor and attempting to open the .uproject directly?
Are you calling UPrimitiveComponent::AreSymmetricRotations at any time in your code, possibly in BeginPlay? This seems like a complex project and I’m unfortunately not going to be able to learn but so much without seeing the code itself.
Hi, sprry for such a delay on my response, I don’t call upon UPrimitiveComponent::AreSymmetricRotations, but I do set the characters position and rotation during BeginPlay(), I can send you the code if you wan’t.
Thank you for sending me your project. I found that the issue is related to this line of code, which is #139 in your KingdomManager.cpp file:
siteName = "Resource Field " + siteName + FString::FromInt(i);
Due to how the for loop is set up that this is contained in, it is resulting in the siteName string becoming extremely long with the words “Resource Field” repeating over and over. This results in an assert triggering when the name hits a certain limit, which explains this check causing an assert:
I commented out the body of the for loop that the line I mentioned above is in and I was able to PIE without an issue. I would like to explain how I found this however so hopefully you can find the next error that you run into.
Once I hit PIE and VS broke, I hit “Break” and then double-clicked the first line listed in the callstack. This took me to the check that caused the assert. After that, I noticed that the assert was checking a variable called “InName” and something about that value was why it was asserting. I then opened the “Locals” tab at the bottom right and found “InName”. Looking at the value, it showed that it was repeating “Resource Field” over and over as its value. I then noticed that the assert was checking against a “Size” variable so I assumed that the problem was how large the string was. This prompted me to search for the words “Resource Field” in your code which led me to this line of code.
Hi , I did now about this issue and this is something new I have been testing and working on, it’s not part of the original problem, The issue starts wen you try to rerun the project on the PIE after the first time it has been played, can you verify whats the problem there, the call stack doesn’t give me enough information on to what is happening.
From messing around with it some more, it seems like it may be a memory related issue. Everytime an assert is triggered, it points toward something not being initialized or failing a check for currentWorld being initialized. One of the times it also directly asserted due to a lack of memory.
After a few asserts pointing to the ChangeMainCamera function in CameraManager and the BeginPlay function in PlayerCharacter, I commented out the body of the former and the following line from the latter:
This led to being able to press play/stop about 4 times before running into another assert which also seemed to be memory related. It’s looking like there are some things that aren’t being released when PIE ends. Do you have any ideas where that could be? The project is rather large so I don’t have much of a grasp on everything that is going on behind the scenes.
That could definitely be the issue. This is an older post but the subject matter should still apply.
I don’t have much experience with using Singletons in the editor myself, but seeing as PIE always creates a new instance of everything to run, that would explain this only causing problems on subsequent attempts.