If you use a simple BT service (see bottom of this post), you can clearly see that its first tick will happen before activation. I consider this behavior a bug because it works against common sense, which assumes [Activation → Tick, Tick, Tick → Deactivation] instead of [Tick → Activation → Tick, Tick, Tick → Deactivation] lifecycle. Activation is commonly used to set up various variables that are later used in ticks. With current behavior, user has to explicitly guard Tick with an artificial “have we activated yet?” check.
Hi Slonopotamus,
I attempted to reproduce what you are seeing in a new 4.6.1 project but so far I haven’t been able to. This is the result that I’m getting. The Tick is only started after the Activation is called.
Are you seeing this behavior in your personal project? If so, can you try reproducing it in a new project?
Tick happens this way:
UKismetSystemLibrary::PrintString
UKismetSystemLibrary::execPrintString
UFunction::Invoke
UObject::CallFunction
UObject::execFinalFunction
FFrame::Step
UObject::ProcessContextOpcode
UObject::execContext_FailSilent
FFrame::Step
UObject::ProcessInternal
UObject::CallFunction
UObject::execVirtualFunction
FFrame::Step
UObject::ProcessInternal
UFunction::Invoke
UObject::ProcessEvent
UBTService_BlueprintBase::ReceiveTick
UBTService_BlueprintBase::TickNode
UBTService::OnSearchStart
UBTService_BlueprintBase::OnSearchStart
UBTService::NotifyParentActivation
UBTCompositeNode::OnNodeActivation
UBTCompositeNode::OnChildActivation
UBTCompositeNode::FindChildToExecute
UBehaviorTreeComponent::ProcessExecutionRequest
And then, node activation happens this way:
UKismetSystemLibrary::PrintString
UKismetSystemLibrary::execPrintString
UFunction::Invoke
UObject::CallFunction
UObject::execFinalFunction
FFrame::Step
UObject::ProcessContextOpcode
UObject::execContext_FailSilent
FFrame::Step
UObject::ProcessInternal
UObject::CallFunction
UObject::execVirtualFunction
FFrame::Step
UObject::ProcessInternal
UFunction::Invoke
UObject::ProcessEvent
UBTService_BlueprintBase::ReceiveActivation
UBTService_BlueprintBase::OnBecomeRelevant
UBTAuxiliaryNode::WrappedOnBecomeRelevant
UBehaviorTreeComponent::ApplySearchUpdates
UBehaviorTreeComponent::ApplySearchData
UBehaviorTreeComponent::ProcessExecutionRequest
Answering to myself, this bug should be fixed by following commit:
commit dcb419aca08133c5315ca253b4127323fe034221
Author: Lukasz Furman <Lukasz.Furman@epicgames.com>
Date: Thu Dec 18 07:57:13 2014 -0500
removed initial Tick event from behavior tree service - this should be implemented using OnSearchStart,
fixed task search using outdated info when more important request was accepted
#ue4
[CL 2392367 by Lukasz Furman in Main branch]
Is this issue resolved now for you? I’ve had it since the start of 4.7 I think, possibly earlier, and still have it using 4.7.4.
This commit isn’t included in 4.7.x. You can either wait for 4.8 or cherry-pick it in your custom build. This issue isn’t hard to workaround.
Okay thanks. I wondered, but it seemed such an obvious one I thought it would have been included if resolved. No problem waiting, just wanted to check that it hadn’t been overlooked.
In 5.4.4 this problem still persists. I have switched to using ReceiveSearchStart in place of ReceiveActivation but why even have ReceiveActivation at this point? Does it serve some purpose beyond deceiving users?
And assuming there’s a genuine answer, how is it possible for the service to tick before being activated?