Skip to content

Reset messages

Alberto Tacchella edited this page Jul 26, 2018 · 6 revisions

The following is a sketch for the proposed mechanism for sending "reset messages" to skills.

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)

Here it seems that we should reset A2 in cases 2-3 if, at the next execution, A1 returns Runn or Succ. Is this what is expected?

Parallel nodes

Apparently no reset actions are ever needed here, since the children are executed simultaneously. (?)

Clone this wiki locally