Drag[en]gine Wiki

User Tools

Site Tools

Trace:
dragengine:modules:dragonscript:statemachines

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
dragengine:modules:dragonscript:statemachines [2026/10/09 20:01] – [Examples] dragonlorddragengine:modules:dragonscript:statemachines [2026/10/09 20:02] (current) – [State Machines] dragonlord
Line 10: Line 10:
 __States__ and __transitions__ can contain __actions__ which modify game state. Actions are typically provided by [[behavior_elements|behaviors]] to control the behavior or behaviors linked to them. Actions are supposed to not fail and throw exceptions only if something is really wrong. Instead they should provide conditions to check if actions could be properly applied or not. If the state machine can not find an action it is treated as if it matches an empty action. It is thus allowed to define actions that do not exist. This can be used to run actions on behaviors which might not be present in an element class. To find problems with missing actions use the debug feature in [[behavior_statemachine|ECBehaviorStateMachine]]. __States__ and __transitions__ can contain __actions__ which modify game state. Actions are typically provided by [[behavior_elements|behaviors]] to control the behavior or behaviors linked to them. Actions are supposed to not fail and throw exceptions only if something is really wrong. Instead they should provide conditions to check if actions could be properly applied or not. If the state machine can not find an action it is treated as if it matches an empty action. It is thus allowed to define actions that do not exist. This can be used to run actions on behaviors which might not be present in an element class. To find problems with missing actions use the debug feature in [[behavior_statemachine|ECBehaviorStateMachine]].
  
-__Conditions__ can be paramtrized by adding one or more parameters to the rule. The conditions define themselves which parameters they understand and how they react to them. The name of parameters is free but it is recommended to use a naming scheme like this: ''<source>.<parameter>''. This groups parameters and reduces the chance of name conflicts. This is especially important since parameters are also reused for action rules. And while actions already define the ''source'' part rather well for conditions this is unknown.+__Conditions__ can be parametrized by adding one or more parameters to the rule. The conditions define themselves which parameters they understand and how they react to them. The name of parameters is free but it is recommended to use a naming scheme like this: ''<source>.<parameter>''. This groups parameters and reduces the chance of name conflicts. This is especially important since parameters are also reused for action rules. And while actions already define the ''source'' part rather well for conditions this is unknown. 
 + 
 +__Condition Groups__ allow to create complex, nested conditions. This can be used to represent mixed ''and''/''or'' condition trees as well as checking the same condition more than once but using conflicting parameters.
  
 States can have __enter actions__ and __exit actions__. __Enter actions__ run after activating the state. Exit actions run before switching to another state. Enter and exit actions both can have conditions which determine if the action is run or not. Enter actions can have a __state change__ assigned. If an enter action with a state change is run the state changes immediately to the specified state and all enter actions afterwards are ignored. This can be used to automatically transition into another state for example if a pre-condition is not fulfilled or an earlier action failed to run properly. In particular no action can be assigned in which case the enter action only serves the purpose to transition into another state if its conditions fail. In addition states can be assigned an __auto-transition state__. If all enter actions are processed and the state has an auto-transition state assigned the auto-transition state is immediately activated. This allows to create pass-through states which only run a couple of enter actions then transition into the final state. States can have __enter actions__ and __exit actions__. __Enter actions__ run after activating the state. Exit actions run before switching to another state. Enter and exit actions both can have conditions which determine if the action is run or not. Enter actions can have a __state change__ assigned. If an enter action with a state change is run the state changes immediately to the specified state and all enter actions afterwards are ignored. This can be used to automatically transition into another state for example if a pre-condition is not fulfilled or an earlier action failed to run properly. In particular no action can be assigned in which case the enter action only serves the purpose to transition into another state if its conditions fail. In addition states can be assigned an __auto-transition state__. If all enter actions are processed and the state has an auto-transition state assigned the auto-transition state is immediately activated. This allows to create pass-through states which only run a couple of enter actions then transition into the final state.
dragengine/modules/dragonscript/statemachines.txt · Last modified: by dragonlord

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
CC Attribution-Noncommercial-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki