13,208
edits
No edit summary |
(Heading cleanup, use sentence case; + Related content: Source code, unfortunately I do not find any other documentation) |
||
Line 13: | Line 13: | ||
* Each state will have a name, and a condition expression required to enable the state. | * Each state will have a name, and a condition expression required to enable the state. | ||
* Each transition will have a name, and a condition expression required to transition into a new state. Transitions can also be conditional on the current active state. | * Each transition will have a name, and a condition expression required to transition into a new state. Transitions can also be conditional on the current active state. | ||
* Entering a state (firing a transition) can fire any number of binding expressions, as can leaving a state. | * Entering a state (firing a transition) can fire any number of binding expressions, as can leaving a state. | ||
* State machines will have a property indicating the current state. (And possibly an integer state index?) | * State machines will have a property indicating the current state. (And possibly an integer state index?) | ||
* A command will be defined to move a state machine to a new state - i.e explicitly fire a transition. This avoids creating signalling properties simply to fire transitions. | * A command will be defined to move a state machine to a new state - i.e explicitly fire a transition. This avoids creating signalling properties simply to fire transitions. | ||
* State-machines can also fire bindings on *any* state change. (This enables updating common properties or Nasal without repeating a rule on every state or transition) | * State-machines can also fire bindings on *any* state change. (This enables updating common properties or Nasal without repeating a rule on every state or transition) | ||
Line 33: | Line 28: | ||
* Unlike Nasal, the state-machine states will be automatically serialised to the property tree, so there is a greater chance of sane behaviour with replays or over the network. | * Unlike Nasal, the state-machine states will be automatically serialised to the property tree, so there is a greater chance of sane behaviour with replays or over the network. | ||
== Implementation | == Implementation notes == | ||
* We already have good support for conditional expressions, bindings and computational expressions in SimGear. The intention would be to build upon these so the syntax and logic is familiar to people. | * We already have good support for conditional expressions, bindings and computational expressions in SimGear. The intention would be to build upon these so the syntax and logic is familiar to people. | ||
* Good inspector / debug support will help, as for the existing components. Especially, logging when state transitions occur, and when a transition becomes enabled or disabled. | * Good inspector / debug support will help, as for the existing components. Especially, logging when state transitions occur, and when a transition becomes enabled or disabled. | ||
== Related content == | |||
=== Source code === | |||
* {{simgear source|path=simgear/structure/StateMachine.hxx}} | |||
* {{simgear source|path=simgear/structure/StateMachine.cxx}} | |||
[[Category:Developer Plans]] | [[Category:Developer Plans]] |