What is the purpose and who's responsible for calling setStatus?

[asasine]

The TreeNode type has the protected void setStatus(NodeStatus); method however I'm unsure of its purpose and why it's protected rather than private.

The method is called by TreeNode::executeTick() after executing the virtual tick() along with pre-/post-conditions.

BehaviorTree.CPP/src/tree_node.cpp

Lines 131 to 134 in 3073f29

	// preserve the IDLE state if skipped, but communicate SKIPPED to parent
	if(new_status != NodeStatus::SKIPPED) {
	setStatus(new_status);
	}

Given this method is protected, it can by, and is, called by several derived types near the beginning of tick() implementations, typically control and decorator nodes, but also subtrees

BehaviorTree.CPP/src/controls/reactive_sequence.cpp

Lines 25 to 32 in 3073f29

	NodeStatus ReactiveSequence::tick()
	{
	bool all_skipped = true;
	if(status() == NodeStatus::IDLE)
	{
	running_child_ = -1;
	}
	setStatus(NodeStatus::RUNNING);

BehaviorTree.CPP/src/decorators/inverter_node.cpp

Lines 23 to 25 in 3073f29

	NodeStatus InverterNode::tick()
	{
	setStatus(NodeStatus::RUNNING);

BehaviorTree.CPP/src/decorators/subtree_node.cpp

Lines 21 to 27 in 3073f29

	BT::NodeStatus BT::SubTreeNode::tick()
	{
	NodeStatus prev_status = status();
	if (prev_status == NodeStatus::IDLE)
	{
	setStatus(NodeStatus::RUNNING);
	}

I'd like to understand the expected contract when deriving TreeNode; should derived types call setStatus within TreeNode::tick overrides or let it be invoked by the TreeStatus::executeTick function?

---

One tangible impact on this design is that trace files become very noisy for certain trees.

<ReactiveSequence>
    <PreconditionA />
    <Inverter>
        <PreconditionB />
    </Inverter>
    <ActionC />
</ReactiveSequence>

Every time a tree like this is ticked, even without any of the nodes changing statuses, the trace resembles this:

ReactiveSequence IDLE -> RUNNING
    PreconditionA IDLE -> SUCCESS
    Inverter IDLE -> RUNNING
        PreconditionB IDLE -> SUCCESS
        PreconditionB SUCCESS -> IDLE
    Inverter RUNNING -> SUCCESS
    ActionC IDLE -> SUCCESS
    PreconditionA SUCCESS -> IDLE
    Inverter SUCCESS -> IDLE
    ActionC SUCCESS -> IDLE
ReactiveSequence RUNNING -> SUCCESS
ReactiveSequence SUCCESS -> IDLE

In practice, all of the nodes in this example are synchronous IDLE -> SUCCESS, so the intermediary RUNNING clutters the output, making the trace files less useful than they otherwise could be.

[facontidavide]

If it was private, derived class would not be able to call it.

In the example you mentioned ( setStatus(NodeStatus::RUNNING)) we want to change the state before the end of the TICK, This could be particularly convenient for logging of asynchronous nodes that take a long time to be executed.

About the fact that RUNNING "clutters the output", I think it is a personal opinion. I find that useful.

So, I will not make it private because it is still useful for unit testing, but I may agree that removing those intermediate changes in some nodes might be considered

[asasine]

Regarding the convenience of logging asynchronous nodes, do you mean nodes whose tick take a long time to return, or nodes that return RUNNING from tick until eventually returning SUCCESS or FAILURE? I can see how identifying a long tick method would be assisted by the setStatus(NodeStatus::RUNNING) of the parent. The latter is aleady handled by executeTick calling setStatus.

Regarding the cluttered output, do you have a recommendation for figuring out "what is going on" in trees structured like my example? If PreconditionA and friends are nested subtrees with additional control nodes, the traces are filled with what boils down to "the precondition subtree synchronously succeeded" but said in many more words.