Open tomtzook opened 9 months ago
For now, if encountered and this is a problem, cycle the trigger state. For a manual trigger, this simply involves calling activate
and then deactivate
(or the other way around, depending on the wanted state).
For a condition-based trigger, this is more problematic, as it requires cycling the condition. On option for this, is to cycle the source of the condition, or modify the condition with some variable to allow manually cycling it.
However, the actual cycling can only occur (and be detected) if the scheduler has noticed the change. So this is actually a bit difficult.
When attaching actions to triggers for a state which is current, the actions won't be used as expected until the next cycling of the action state.
For example, say the current state is
TriggerState.ACTIVE
, and someone invokesTrigger.whenActive
with some action, this action won't be started.The root for this is that the updates to attached actions are only done in
GenericTrigger.update
(called by the scheduler), which only updates the actions if the state has changed.Problem is, we can't simply act on the actions via the attach methods (like
Trigger.whenActive
) because it is only allowed (and possible) viaGenericTrigger.update
. So either we change this, or create some list which registers newly attached actions, and inupdate
perform special handling for them.