Reset messages

NOTE: this approach to reset messages is not the one we used in the end. This page is left here only for reference purposes.

Sequence nodes

Suppose given a node Sequence A1 A2. On the first execution the following 5 cases are possible:

1. (A1=Fail, A2=None (skill not ticked), result=Fail)
2. (A1=Runn, A2=None, result=Runn)
3. (A1=Succ, A2=Fail, result=Fail)
4. (A1=Succ, A2=Runn, result=Runn)
5. (A1=Succ, A2=Succ, result=Succ)

This return status will be cached in the BT data structure. On the next execution of the same Sequence node:

• In cases 1--3 no reset messages are ever needed (for every possible return value of the skills), so everything can proceed as usual.
• In cases 4 and 5, there are two possibilities:
  • Skill A1 returns again Succ. In this case no reset actions are needed, evaluation proceeds as usual.
  • Skill A2 returns Runn or Fail. In this case we must send a reset signal to A2, or (more generally) to each successive child of the Sequence node whose previous (cached) result was Succ or Runn (but not Fail).

(Notice that Cases 3-5 would also need a different algorithm in case of a "node with memory" (a.k.a. starred node); in any case, it does not seem necessary to provide such nodes as primitives -- they are trivially implementable via a binary fallback subtree).

Fallback nodes

Here the five possible cases after the first tick are

1. (A1=Fail, A2=Fail, result=Fail)
2. (A1=Fail, A2=Runn, result=Runn)
3. (A1=Fail, A2=Succ, result=Succ)
4. (A1=Runn, A2=None, result=Runn)
5. (A1=Succ, A2=None, result=Succ)

We should reset A2 in cases 2-3 if, at the next execution, A1 returns Runn or Succ.

Parallel nodes

Finally, for parallel nodes the following semantics seems appropriate: if enough children have returned Succ of Fail such that a decision can be taken, we send a reset signal to the ones which have returned Running. Notice, however, that no cached values are needed here.