As you can see, the parameter forceExplosion is by default set to false.
The problem is that when I hop in game, the variable is true!
I don’t understand how.
In the Projectile constructor I have this delegate:
// When the projectile hits something
MovementComponent->OnProjectileStop.AddDynamic(this, &AProjectile::AddDynamicOnImpact);
So the function AddDynamicOnImpact() should be called when the Projectile hits something, right?
Apparently it doesn’t because the string “Hello, I am the delegate!”doesn’t appear on the screen!
void AProjectile::AddDynamicOnImpact(const FHitResult& HitResult)
{
if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Cyan, FString::Printf(TEXT("**HELLO, I AM THE DELEGATE!**")));
// HERE I CALL OnImpact() passing FALSE as argument!
OnImpact(HitResult, **false**);
}
I tried to take a look at the Call Stack provided by Visual Studio:
According to call stack your OnImpact is called from some script place, not from AddDynamicOnImpact
Maybe you are binding it elsewhere.
And show your header file.
PS. And you are debugging Grenades, aren’t the supposed to be Explosive? )
I’d try to dig down into MovementComponent->OnProjectileStop in the VS watch window, to try to find what function(s) are bound. It looks from the call stack as if OnImpact is itself directly bound. Were you perhaps binding this previously, or changed the name of a method?
I had issues in the past with old bindings persisting after I changed the code, especially when blueprints were involved. Since then, I always try to avoid binding dynamic delegates in constructors, and do it in BeginPlay instead. If you have a blueprint based on this class, I’d suggest recreating it, or a new blueprint, and seeing if you still get this behaviour.
So the OnImpact function is directly called when the projectile hits something? Seems legit.
But then why is my bool variable set to true by default? Despite of the = false in the header?
Many people have always told me to set delegates in the constructor. The ShooterGame example also does it. Can’t understand where to put this freaking delegates!!!
Yeah I know it’s often done in the constructor, and it should work, I just personally try to avoid it since wasting a huge amount of time once tracking down an issue that turned out to be caused by corrupted delegate bindings in a blueprint after changing the C++ code. If you bind delegates in BeginPlay, then they won’t ever be serialized so that can’t happen.
It does seem strange that it’s coming through as true, but it’s possible that could happen if the binding is corrupted and is attached to a function with an unexpected signature (OnProjectileStop expects only 1 argument, so if it’s somehow got bound directly to OnImpact, the second argument could end up being anything). Maybe confirm the underlying value of forceExplosion in the debugger - if it’s 1, then I doubt this is the issue, but if it’s anything other than 0 or 1, then this could be it.
If you open the Watch/Quickwatch window and enter (int)forceExplosion, it should show you the value.
If the delegate is stored corrupted, moving it to BeginPlay now won’t help. Though you could try (in BeginPlay) adding
Clearing and Re-Bounding the delegate inside the BeginPlay() seems to work fine. Even though I still don’t understand what’s the reason of this mess… And I would like to know what is definitely the right way to do this.
Also, I have noticed that with my Grenade (which explodes after a certain ammount of time) the AddDynamicOnImpact() function is called twice.
1) The first one is called as soon as my Grenade hits the wall. Which is right, because the Projectile hits something and the delegate gets triggered.
2) The second one is called before the Grenade explodes. But it’s strange since the Grenade has already collided with the wall. Why should the function be called twice? And, more importantly, why the function gets called again after some time and not instantly?
What I have noticed, though, is that while the AddDynamicOnImpact() delegate is called twice, the OnImpact() function IS NOT.
This because the OnImpact() function has a Role == ROLE_Authority check.
The first time the delegate AddDynamicOnImpact() is triggered, it is able to execute OnImpact().
The second time, however, it isn’t because it doesn’t pass the Authority check.
Are you running in multiplayer? Sounds like it’s just being called once for server, once for client, and the client doesn’t pass the authority check. Which is as it should be. I don’t know the details of when ProjectileStop is supposed to fire, I’ve never used it.
Anyway, sounds like the original issue probably is a corrupted delegate, same as I had. You can leave the Clear call there and it should be fine, though if you want to resolve it properly the easiest way would be to recreate your blueprint from scratch, if that’s feasible.
I agree with you that the function has to be called twice, since there is a multiplayer context.
But they are not called instantly twice. The server-version is called first… after a while the client-version.
I need to know more about this. I can’t continue the development of my game with these holes in the code.
Anyway, sounds like the original issue probably is a corrupted delegate, same as I had. You can leave the Clear call there and it should be fine, though if you want to resolve it properly the easiest way would be to recreate your blueprint from scratch, if that’s feasible.
[/QUOTE]
What would you do if you were me?
Which delegate would you use (always related to ProjectileStop)?
For which reason rebuilding the Blueprint could be useful?
Client always lags behind server. If you’re talking multiple seconds afterwards, then maybe something else is wrong though.
The corrupted delegate binding is stored in the blueprint. So if you create a new blueprint based on the same C++ class, which now only binds the delegate in BeginPlay, it shouldn’t have the issue and should work even if you remove the .Clear() call. If you make a habit of binding delegates in BeginPlay rather than a constructor, then you shouldn’t run into this again so you wouldn’t need to rebuild blueprints regularly.
Just to be clear though - I don’t think you did anything wrong at all, I think it’s just a UE4 bug that a delegate can get corrupted in this way.
I deleted the .Clear() from the BeginPlay() and created another Blueprint.
The “fresh new” Blueprint works well even without the .Clear(), whereas the old one used to give problems.
BUT… the AddDynamicOnImpact() function is still called twice with a gap of some seconds between the two calls. WHY? what the hell is going on…
[off topic]
OOOOOH WELL, what can I say?
It’s been two years and almost all the issues I’ve had with this Engine were due to Engine bugs.
I’m pretty tired of fighting against Engine bugs, instead of fighting against MY bugs
I’m tired of remaking Blueprints from scratch for every freakin’ thing!
Most of the time that I have a really weird bug, it’s actually my error, but it’s in a place that I wouldn’t even think is related.
In this case, I’d take a quick pass along every class to see if you forgot a Super call in any overrode method or constructor (especially GetLifetimeReplicatedProps and major events like BeginPlay!) to see if you missed one. That could be silently blocking some of Epic’s back-end code from running, which causes weird errors in other, seemingly-unrelated places. Pay close attention to important classes, like your subclass of GameState.
You are inside Visual Studio. You have all the debugging tools you need to figure this out!
First, after you bind the initial delegate, set a data breakpoint on the actual data structure of the delegate. This will show you if something “corrupts” the data.
Second, inside each call, follow the call chain up the stack, looking at the code in each place. You should be able to find the kind of code that calls the function in each case, and from that figure out why it’s being called.
(If the “source” of the call ends up being indirected through some asynchronous event, this requires more patience to track down, but it’s still totally possible.)
Note that, on the call stack, you will see which delegate is actually being called to generate your function call (this may go several levels.) You can thus put a breakpoint on where those delegates are set, to see where they get initialized.
The computer is 100% deterministic. It’s doing what it’s doing for a reason. The debugger allows you to inspect everything it is doing, so you can use that to work your way backwards to the source. What you need is the time and determination to do that.
can you check how you spawn that projectile? Might it be it collides with something on spawn and thing are happening much quicker then you are able to set it up for use? That’s just my wild guess, I might very well be wrong!
I have made more experiments with the “new” Blueprint @kamrann
I moved the .AddDynamic() method into the Constructor -> the function gets called twice and in each of which it passes the Authority check
I moved the .AddDynamic() method into the BeginPlay() function -> the function gets called twice and only once passes the Authority check
So in both cases the function is called twice with a delay of ~1 second. Is that normal?
I’d have that kind of determination if this were a bug of mine, not of the Engine.
Sorry, If I had had that determination for all the times I experienced Engine bugs, I would be dead by now.
