Hi,
firstly sorry for the ambiguous title but I really didn’t know how to explain my problem in one sentence 
Assume I have a class AOne that inherits AActor written in c++. This class has a property TSubobjectPtr<.USphereComponent> Sphere; that is used for handling overlap events.
Later in code I have more classes that derive from AOne. For example lets name them class ATwo and class AThree. Both of these classes are later inherited by blueprints ATwo_BP and AThree_BP respectively.
Now the problem is that I would like to handle the overlap event in blueprint in the same way for all AOne classes without duplicating the graphs in ATwo_BP and AThree_BP but have the common graph in AOne which is in code.
In other words what I’m actually trying to achieve is create a blueprint of AOne and derive from this blueprint in code, what AFAIK is not possible. So is there any way that I could put this common behavior into a blueprint and still be able to derive from it in code?
Thanks in advance.
As you said, it’s not possible for native class to derive from blueprint. Solution you may look for is to implement this common logic in AOne class. You can run common logic in code, then call your own event to inform blueprints about some overlaps etc. It’s difficult to give right answer without having project on the desk. Please read about blueprint imperoperability (BlueprintImplementableEvent, BlueprintCallable, BlueprintPure), this might help you.
Well it’s not about letting the designers know what is happening but about letting them extend the code based classes without actually coding. This example that I’ve written should be treated just as an example since the problem is more abstract. There could be something like a proxy between the code and blueprint that handles (at least) all the events in blueprint before passing them to code. The pipeline would look like this ADerivingClass_BP → ADerivingClass C++ → ADerivedClass_BP → ADerivedClass C++. Just an idea but I think it could be possible. I worked on engines that supported this kind of communication and it’s very convenient.
If you want to extend code use Template Method design pattern. To achieve this, use BlueprintImplementableEvent with a not void return value or a reference argument. Then if you create blueprint that derives from native class, you can implement this function as a blueprint graph.
But the native class that I want to extend is inherited by other native classes that on the end are derived by a blueprint.
You can use virtual functions and override them on native level, then if you want to switch execution to blueprint, use BlueprintImplementableEvent. You don’t have to call Super. Moreover you can use BlueprintNativeEvent, to define default implementation on native side.
It’s difficult to solve this problem without having any UML diagram or sample code.
Of course I can use virtual methods but the point is that I don’t want to… I don’t think you understand what I’m talking about. So imagine that there is a class AWeapon that is native now this is inherited by also native AGun, AGranade, AKnife etc. all of those have totally different behavior and that’s all cool and clear. But now imagine that designers (NOT PROGRAMMERS) want to extend the AWeapon class so that you can throw it, eat it, disassemble it and do whatever they want with it. And now they can’t do it inside the AWeapon they have to copy/paste all the logic for all of the inherited classes AGun, AGranade, AKnife and do it 3 times! instead of once for the AWeapon. I don’t even mention adding a new property to it which should really be trivial. And now what if another type of weapon comes into the game? They will have to copy it once more and remember to do it each time a new weapon type is added.
And yes I know I can code it but that’s the point that I don’t want to or I have no time since I have other tasks to do and the designers don’t want to wait for me, they want to be creative and create whatever they want. That’s an issue. It’s counter productive.
In my opinion it’s more philosophical problem than technical. You shouldn’t bother with programming at all, this looks like team has no vision of final product and try to experiment with hundreds of ideas. You should implement all types in blueprints: AWaepon, AGun, AKnife, then designers can freely extend your base classes with new functionalities.
Later, when your blueprint prototype will stabilize you can try to generalize problems and create native layer in C++.
This is a general rule for all projects in UE4. Use blueprints for rapid prototyping, test your ideas, then generalize and implement native layer in C++ to gain performance.
The other advice is that if you find some functionality that cannot be implemented in blueprint during the prototyping phase, try to create C++ component (UActorComponent) to encapsulate it. Then component can be used in blueprint by a designer.
I guess that this is the answer that I didn’t want to hear but I think you’re right. Thanks.