Super on BlueprintNativeEvent cause infinite loop


I am a bit lost to implement the “Super” call BlueprintNativeEvent.

If I call the Super on the function I got an infinite loop.

I mean:

Let say in gamemode, ReadyToEndMatch
How am I suposed to called the Super function for my child class?


I ran into this same issue, I believe its not possible to call the super on BlueprintNativeEvents.

To workaround that I’ve just copy pasted the code…

You should just call the Super::MethodName_Implementation version instead.

As far a I know, this is true for replicated function but not for BlueprintNativeEvent.

If you call the Super::MethodName_Implementation the BP implementation won’t be called only the C++ part.

thanks for your feedbacks

The blueprint is at the bottom of the override chain. If you have a blueprint implementation, then that is what gets called first by the framework (it’s called by the generated implementation of the method, the one without the _Implementation suffix, which you don’t define yourself). Calls to Super in your own _Implementation definitions have no effect on that process.

If you were to invoke the method initially by calling the _Implementation, then yep, the blueprint would be skipped. I’m not suggesting that though. So long as you invoke using the base method name, that should dispatch to the last override (be it blueprint or C++), and then you are free to pass on up the chain using the line I gave above. This has always worked as expected for me.

That’s my issue in fact.

I called the Super::DefaultMethodName without the _implementation but I receive a Infinite loop.

All what you are describing is the behavior that I understood also but it fails. This is why I post it here.

FYI I’m in 4.19 (latest launcher version). That’s might be my issue ?


Sorry I didn’t explain well. Never write Super::MethodName(…), that will indeed lead to an infinite loop. When calling super, write Super::MethodName_Implementation(…). When actually invoking the function externally, always write Object->MethodName(…). That should ensure any blueprint override is called first.
Like I say, I haven’t seen any problems, and I’ve upgraded all my plugins to 4.19.


Ok so if I follow you, if I call Super::MethodName_Implementation(…), the BP implementation of my super class will be called and not only the C++ one?

if this is it, that’s not trivial but great to know.


You mention “BP implementation of my super class”, which suggests you may not be clear on the inheritance hierarchy. It goes from C++ base -> C++ derived classes -> First derived blueprint -> Child blueprints. So “BP implementation of super of class A” doesn’t really make sense, by definition that is also the blueprint implementation of class A.

It essentially goes like this:

Something calls Object->MethodName() in C++, or the equivalent from Blueprint.
Most derived implementation is found (since blueprints always extend C++, if there is a blueprint override then that will always be called rather than a C++ override of the _Implementation).
That implementation alone is called.

That’s all the dispatching process does. If you need an implementation to also invoke its parent implementation, you achieve that with AddCallToParent in blueprint, or Super::MethodName_Implementation in C++. AddCallToParent from the top-level blueprint would call the most-derived _Implementation that exists, which in turn could call up the Super chain.

So short version: most derived gets invoked; any super calls then work their way back up the inheritance tree.

Ok I got it now.

Everything is clear now and thanks for taking time to explain me the “hierarchy”.

I was confused by the fact that my BP will be called first then my C++ and I don’t why, I thought that the Parent Class can have a BP in between which is a non possible at all :frowning:

If I understand also properly AddCallToParent will go in the hierachy to find the code to run. It could be a parent BP or the C++ parent class.