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.
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.
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]
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?