TL;DR: I have a Blueprint implementable event that works when called from outside a particular else clause, but crashes the editor when called from within it(code below). If I compile the C++ code and then add that event to the Blueprint graph, trying to compile the Blueprint crashes the editor.
The event receives a parameter of type const int32. The behavior described above does not happen if it receives no parameter. Below you can see the exact code:
void MyClassName::SetHitboxEnabled(const bool bEnabled)
{
if (bEnabled && bIsAttacking && GetWorld()) {
//Hitbox->SetCollisionEnabled(ECollisionEnabled::QueryOnly);
//LastHitboxEnableTime = GetWorld()->GetTimeSeconds();
//OnHitboxEnabled();
}
else if(Hitbox->GetCollisionEnabled() != ECollisionEnabled::NoCollision) {
//Hitbox->SetCollisionEnabled(ECollisionEnabled::NoCollision);
OnHitboxDisabled(0);
// Reset the number of hits since activation
// This is so the next activation starts from 0 again
//nHitsSinceHitboxActivation = 0;
}
}
That is my exact function. As you can see, I’ve stripped it to the bare minimum, leaving only the OnHitboxDisabled() function call. It still crashes, but only if it’s called from within that else clause.
Engine is 4.24.3.
I did all you can imagine, from recompiling, to closing the editor, to rebuilding the whole project. Nothing, save from removing the function from the else clause, seems to fix it. This is quite weird though, not the sort of thing one should do to solve a problem.
One thing that may be worth mentioning is that this particular SetHitboxEnabled() function is called from inside animation notifies. I’d suspect this may be caused by animations running in a different thread, but then again, merely compiling a Blueprint that implements the above function crashes the editor. It doesn’t get to a point where the code can actually be tested in-game.
Does anyone have any idea what the hell may be going on?
You’re calling ''Hitbox->GetCollisionEnabled()" without first checking if the Hitbox is valid. It probably isn’t, which is why it’s crashing. Blueprint has a safety net for code that tries to dereference nullptrs but C++ doesn’t.
AnimNotifes are queued up and execute on the Game Thread regardless so it’s not a threading issue.
The hitbox is the first thing created inside the constructor and never messed with again, so it can’t exist in a NULL state. Not to mention, I am certain that is impossible because it still happens without the test. I’ve tested it several times before making this thread. It only crashes if the function call is inside that else clause, takes a parameter, and is added to the Blueprint graph. I know that makes no sense, but I assure you looking for a null pointer exception was also my first guess.
As I mentioned, I was suspecting it had something to do with calling the class’ functions directly from animation notifies. So, I’ve updated the notifies to call Blueprint events instead, which in turn call the functions from inside the derived Blueprint. It no longer crashes.
I do not like this at all. I will actually revert to see if that is truly what solved it.
I am calling SetHitboxEnabled directly from an animation notify again, and nothing happens. Adding the event to the Blueprint graph no longer crashes when compiling the Blueprint.
This kind of problem looks like what you get when you change the class layout and recompile with the editor still open, but I always close the editor when compiling C++. However, I just realized something. I double clicked a node by accident earlier and VS opened the class’ .gen file. It’s been loaded inside VS until earlier when VS randomly asked me to reload it, and I instead closed it. SINCE I added two new functions to the class and a new variable, and since I usually compile from VS, could it be VS was overriding the updated .gen header with the old one from before the layout change?
Since the assert was pointing me to the .gen header, this came to mind.
EDIT: Scratch that, I’ve reproduced the problem by reverting most of the changes I made earlier. The editor just crashed 5 times in a row. I will change the animation notify back to what it was when it was working, and report back if that makes a difference.
Post the callstack and/or a log as this will help diagnose it better. If you’re certain that it’s not nullptr (I would still guard or assert against that, personally) - it’s obviously not this function itself that’s causing the crash. (HitBox definitely can be null, especially if it’s not a UPROPERTY for example).
Just a note that if you are compiling with the editor open you cannot make constructor or header changes. If you do it will corrupt the memory of the running application and all sorts of things will break. Although Hot Reload lets you do it, it’s incredibly unstable (Live Coding is way better anyway, and faster).