Hi all. I’m having an issue with semi-duplicate BeginPlay events made available in a blueprint that I derived from a C++ class. I made it fairly simple to start with so that I could test things as I built/learned and ran into this problem fairly early.
I created a C++ character controller with a UFUNCTION(BlueprintNative) tagged BeginPlay method. I expected to be able to simply override this in a derived blueprint, but now I have two versions of BeginPlay in my blueprint. At first I did not know this, so it took a while before I figured out why my blueprint wasn’t behaving as expected. It was also a little trial and error to figure out which was the correct version of beginplay node to use.
Here are some screenshots to outline the entirety of the issue including both blueprint and C++ code:
This would be a non-issue if I only planned on working on the project myself, but I will be teaming up with other people who will be using blueprints derived from my C++ classes, so it would be helpful to have a solution.
My question is two-fold:
Firstly, why am I getting two BeginPlay nodes?
Secondly, what is the best way to expose only the C++ derived version to designers using only the derived blueprint?
Any insight is greatly appreciated.
Thank you in advance!
Ah! Thanks! That’ll help!
I’m planning on writing some default code for setup so the designer wont have to worry about it (you can see some of it from the commented code. Just spawning some utility actors that are meant to be used for later behavior).
Still figuring out what we would want the C++ to be responsible for and what the blueprints would do exactly, but this at least seems like it makes sense.
Gonna try this out and will mark this as accepted if it works.
Hey, you implementation is a little unusual. There’s no need to make the BeginPlay_Implimentation. Override BeginPlay() with virtual void BeginPlay() override;
Now there’s no need to do anything special to expose the Begin Play, your overriding it and adding your own functionality. When you make a blueprint derived from your class, the blueprint is a child class of your c++, so just calling the Parent:Begin play will act as the Super and work as you expect. Any code added in blueprint on begin play will be called after your parent c++ runs its begin play.
Just a note, im not even sure if you need to call the parent:BeginPlay when your parent is a cpp file. I think it will run without the Super.
So I’ve changed things up, removed any keywords from UFUNCTION() (No more blueprintnativeevent, etc) and removed the implementation version of the function to reflect the changes, changing the implementation code to match.
virtual void BeginPlay() override;
Now I don’t have two blueprint nodes, but the parent code runs all the time, whether or not I add the “call to parent function” node in blueprint.
Based on this, it seems that there is still a separate beginplay function happening in the C++ code and while it’s no longer exposed to blueprints, I also don’t get to choose whether or not it runs now. Kind of leaves me back at square one.
Thanks @cmarston74. Based on that link, it seems in the end that the answer is “its just not possible to override the c++ beginplay event in blueprint”. sad. I guess we’ll have to work around it with workflow and education.
I now have a more rounded idea of how all this works thanks to the page linked in @cmarston74’s link provided as a comment on my original question: Overriding beginplay in c++ and BP - Programming & Scripting - Unreal Engine Forums
It seems that C++'s begin play event and the blueprint BeginPlay event are not the same thing. To set up C++ BeginPlay to be overridden, the way I originally had it with an extra node is essentially the only way. Unfortunately that means that we’d end up with a duplicate BeginPlay node.
To manage this, its probably best to just not try to override C++'s BeginPlay directly and instead manage the situation with correct communication and workflow. Having two nodes with such similar names in blueprint will do nothing more than open the door for bugs, confusion and work interruptions.
It seems the answer is “you can’t do that”.
Thanks for trying to help though!
If your enforcing the fact everyone starts with a single base class. Design your own interface for them to use that makes sense within your own project. Just because Epic chooses a name for something doesn’t mean it’s the only name. You just ha e to get your developers used to your interface which has to happen anyways. And if it saves then time and effort, they’ll gladly take a name change.
Another option to allow you to keep the begin play interface is layer the base class. Internally build a set up routine that performs your code. Create a base class blueprint that acts like an interface. In its begin play call your base class setup code. Have your developers derive off of your base blueprint class that calls the code routine. Then they still have the begin play method they can override in blueprints and it calls into your code side without them having to call it.