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.
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.
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.
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
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.