580
edits
State machines: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Created page with "XML autopilot modules already support stateful components, especially JK and RS flip-flops. The intention is to add explicit state-machine support, where a state machine compo...") |
No edit summary |
||
| Line 1: | Line 1: | ||
XML autopilot modules already support stateful components, especially JK and RS flip-flops. The intention is to add explicit state-machine support, where a state machine component can be defined, with states and transitions between states. | XML autopilot modules already support stateful components, especially JK and RS [[Autopilot_Configuration_Reference#Flip_Flop|flip-flops]]. The intention is to add explicit state-machine support, where a state machine component can be defined, with states and transitions between states. | ||
== Design == | |||
* 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. | ||
| Line 16: | Line 18: | ||
As a particular specialisation of the above, will be an 'off-arm-active' state machine. This will be a state machine specialisation with three states, and fixed names, intended to model the common arm/engage pattern of many autopilot functions. | As a particular specialisation of the above, will be an 'off-arm-active' state machine. This will be a state machine specialisation with three states, and fixed names, intended to model the common arm/engage pattern of many autopilot functions. | ||
== Benefits == | |||
* Major benefit is moving imperative state logic from Nasal into XML. Ideally most autopilots could be created as a series of state machines (likely one for each control axis, plus some extras), some filters and components that perform computation, and small amounts of imperative Nasal within. In particular the amount of Nasal requiring to be evaluated each frame should greatly decrease. | |||
* Unlike Nasal, the state-machine states will be automatically serialised to the property tree, so there is a greater change of sane behaviour with replays or over the network. | |||
== 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. | |||
* Good inspector / debug support will help, as exists for existing components. Especially, logging when state transitions occur, and when a transition becomes enabled or disabled. | |||