The curious case of AActor function execution order

• Introduction
• BeginPlay() is... not BeginPlay()?!
• What this means in practice
• List of functions with similar behavior

Introduction

Overriding functions and calling their parent implementations are such fundamental concepts in inheritance that we hardly ever even think about them twice. And we definitely never anticipate any strange behavior!

Let's take a simple example: create a C++ Actor class and then inherit a blueprint class from it. Say, we override the BeginPlay() function in C++ to do something. And in the blueprint we may implement something like this:

Any reasonable developer would expect the execution order to be First thing → Parent implementation → Second thing. However, the actual execution order will most likely be First thing → Second thing → Parent implementation (though it could also be Parent implementation → First thing → Second thing). Or, if you forgot the call to Super::BeginPlay() in your native class, neither First thing nor Second thing would be executed. If you don't believe me, try it!

BeginPlay() is... not BeginPlay()?!

The key is that the BeginPlay() in blueprints is actually not an override of BeginPlay() in native!

One way to see this for yourself is to observe that the BeginPlay() function in the native Actor class has the following comment above it:

1
2

    // Called when the game starts or when spawned
    virtual void BeginPlay() override;    

However, in the child blueprint class of this actor, the BeginPlay() node has a similar but different tooltip:

Where does this text come from? Through the wonders of modern technology we can search the tool tip text in our IDE of choice and find out that the function in blueprints is actually ReceiveBeginPlay() defined in Actor.h:

1
2
3

    /** Event when play begins for this actor. */
    UFUNCTION(BlueprintImplementableEvent, meta=(DisplayName = "BeginPlay"))
    ENGINE_API void ReceiveBeginPlay();    

This function is called inside the normal AActor::BeginPlay() just before setting the actor as HasBegunPlay:

1
2

    ReceiveBeginPlay();
    ActorHasBegunPlay = EActorBeginPlayState::HasBegunPlay;    

What this means in practice

At first glance one would expect the blueprint implementation of BeginPlay() to override the native parent implementation. However, we now know that is impossible as they are two different functions. If your design requires a way to override native functionality you will have to create a custom function and use that in blueprints instead.

This also means that one can control the order in which the code is executed by being mindful of where the call to super is placed in the native implementation. To illustrate this point, the following code

1
2
3
4
5
6
7
8
9
10

    void AWActor::BeginPlay()
    {
        UE_LOG(LogTemp, Log, TEXT("%s() in native before Super::BeginPlay()!"),
            ANSI_TO_TCHAR(__FUNCTION__));

        Super::BeginPlay();

        UE_LOG(LogTemp, Log, TEXT("%s() in native after Super::BeginPlay()!"),
            ANSI_TO_TCHAR(__FUNCTION__));
    }    

with a print string on BeginPlay() in a child blueprint yields the following log output:

1
2
3

    LogTemp: AWActor::BeginPlay() in native before Super::BeginPlay()!
    LogBlueprintUserMessages: [B_WActor_C_UAID_7085C2B5FE9B684C02_1813221055] Event BeginPlay in blueprint  
    LogTemp: AWActor::BeginPlay() in native after Super::BeginPlay()!    

Note that without the call to super, the blueprint function will not execute at all!

Finally, you can still add a call to parent by right-clicking the event in blueprints and selecting Add Call to Parent Function; however, if the blueprint is a direct child of a native parent this call will do nothing as there is no parent implementation. If you inherit another blueprint class from the first one, you will see the call to parent is added automatically, since ReceiveBeginPlay() can now be meaningfully overriden. But again, note that you will only be overriding the parent blueprint behavior, and none of the native parent behavior.

List of functions with similar behavior

Above, I only talk about BeginPlay() to keep the explanation simpler. However, it isn't the only Actor function likely to cause headaches and bugs if one doesn't anticipate the blueprint and native functions to not match up. Here's a (hopefully) complete list of these rascals:

• BeginPlay() → ReceiveBeginPlay()
• EndPlay() → ReceiveEndPlay()
• Tick() → ReceiveTick()
• Destroyed() → ReceiveDestroyed()

If you comb through Actor.h you will notice over a dozen other BlueprintImplementableEvent functions that start with "Receive" and have user-facing names without it. However, they don't trick programmers into the same trap as their C++ counterparts also have different names.

PS I haven't checked it for sure, but I suspect this article is also relevant for some functions in ActorComponent as well, notably BeginPlay() and EndPlay().