When It comes to OOP inheritance, the best practice is to take a moment to think about code structure and decide which classes should be be extensions of a common super-class. But in a wild hackathon or game-jam, we may be blueprinting too hastily for that, and we may find out different blueprint classes actually have to be child classes of a common parent class after they already exist and have existing blueprints in them.
In this case will have to Set their parent class as a different class than the class we chose when we initially created them, and also create calls to the parent class event functions if needed.
Setting a BP’s parent class:
Click Class Settings, and under Class Options, in the Parent Class drop-down select the wanted parent class (superclass).
Calling the Parent Class’s event functions:
When creating a BP class that is defined as child class in its creation this is done automatically
Right-Click the current class’s Event icon, and select Add call to parent function:
Connect the execution flow graph, and other inputs if necessary:
When Spawning new actors via the SpanActor Blueprint node, initial transform must be supplied to the SpanActor node, and not defined in the spawned Actor Class’s Blueprint.
Just found out the hard way, that when you spawn an Actor using the SpawnActor blueprint node, the transform data connected to the SpawnActor node is actually applied after the actors Construction Script and BeginPlay Event.
This means any transform you will try to apply in the spawned Actor’s Blueprint will be overridden and therefore not work.
The Delay node serves as a timer that will execute the connected blueprint after a predefined time in seconds.
An example of usage could be triggering a game event at a set time after the player entered a location.
You can use random values or other expressions connected to the Duration input to create a richer and less predictable interaction.