Condition nodes are the simplest one. They can only return success or failure, so no need for halting transition.

When run, the hippo version will call an external (C/C++ function), which is expected to return either success or failure. Note that Condition node are supposed to be fast, hence they are linked to a Fiacre external function (i.e. not a Fiacre task which would execute in its own thread).

Action nodes are more complex, they can return running when the action is taking some time, hence they can also be halted.

The Action node Hippo version must provide two C/C++ function:

Decorator nodes only have one child, which is ticked/called by setting their caller field to the current BTnode, and then waiting until this caller field is back to None, which means the child has finished its tick execution. Of course, depending on the particular decorator (Inverter, ForceFailure, ForceSuccess, KeepRunningUntilFailure, RetryUntilSuccessful, RateController, Repeat, etc), the transitions from Child done to Success, Failure or Running will be adapted to the particular decorator. For example, the Inverter one will swap the Success and Failure transitions, while leaving untouched the Running one.

The Sequence node ticks/executes its child in sequence as they succeed, until one fails. It then returns failure. If all succeed, it returns success. If one child returns running, it returns running. Upon return of the tick this child is ticked/called again.

The Fiacre process has a local variable next_seq initialized at 1, which holds which node will be ticked/called when the current node is ticked/called again. From the Tick Node, we proceed to the Childnext_seq state, which ticks/calls the proper child. We wait until this child is done caller = None and check its returned status rstatus.

Note that setting BTnode[self].caller := None will inform our caller that we are done with this tick, and ready to be called/ticked again

The Fallback node executes/ticks its child in sequence as they fail, until one succeed. It then returns success. If all fail, it returns failure. If one child returns running, it returns running. Upon return of the tick this child is again ticked/called. As shown on the figure, it is the symmetric of the Sequence node, thus its behavior is just the mirror of the Sequence one described above.

The Parallel node can specify how many children m out of n (all children) must succeed for the Parallel node to succeed (the ParallelAll node specify they all must succeed n = m). From this, we see that the implementation just ticks all the node, and then keep track of how many fail, succeed or return running. If any final condition for success or failure is met enough BTnode[child1].rstatus = success) or (enough BTnode[childn].rstatus = failure, then one proceeds to the corresponding state (and possibly halt any running children), otherwise, this node return running. (enough …​ success) is true when success >= m and (enough …​ failure) is true when failure > n - m .

There are a number of situations where one can decide to halt a running branch (e.g. when a Parallel fails (or succeeds), what do we do of the still running children, similarly when a ReactiveSequence fails, one children may still be running. Hence, any node which can have one or more running children (e.g. the Parallel node can have multiple running children) must also provide mechanism to halt and to propagate the halting mechanism to its children. We have seen how it is implemented for the Action node. For all the control and decorator node, it is quite simple, we check which children is currently running, and if it is, we set BTnode[child].rstatus := halt_me and ticks it with: BTnode[child].caller := self. Upon return, we return failure (unless the halt has been initiated by the current node on a success, e.g., Parallel with success on m < n).