[erlang-questions] gen_statem and multiple timeout vs 1

[Fred Hebert]

On 10/04, Vans S wrote:
>Picture a game where you autoattack every 1000ms, if you use Halt 
>command your autoattack stops and movement stops.
>The return will look like [{named_timeout, infinity, 
>auto_attack}, {named_timeout, infinity, move}].  In this case if we 
>were not autoattacking butmoving and halted we would crash. Which is 
>bad.  It adds unneeded complexity.
>

I'd rather see this implemented by seeing one track the timers they use 
(with their Refs), and their action from the message is dependent on 
their state (halted or auto_attacking). What you're advocating is doing 
that tracking by hand based on some other unrelated state, and you're 
actively fighting one of the states that could exist in your FSM!

At the very least, that sounds better than adding yet more features into 
the gen_statem behaviour, which is gathering requirements at a fairly 
rapid rate so far.

>
>For example, if we have a moral boost buff that lasts 10,000ms, and we receive another 10,000ms moral boost buff that stacks, we want to increment 
>the current 10,000ms moral_buff timeout by 10,000ms more.  Maybe on named_timeout callback pass the list of all Timers registered, or at least [{Name, TimeRemaining}] ?
>

This is a state machine behaviour! If you're buffed, this should be 
represented in your state explicitly rather than implicitly within the 
state machine mechanisms!

Think for example that you upgrade a node's code. One thing to consider 
is that after the upgrade you may add or remove timers. However, the 
code change mechanism does not allow you to manage that kind of stuff: 
you can only modify your own state and data, but not play with the event 
mailbox.

To be able to change your logic around timeouts during a pause would 
require you to move them to your own FSM's data and to ignore old 
references, no way around it.

There's a benefit to handling that kind of stuff explicitly, and if 
timers are integral to your system progressing, you should probably take 
a more direct approach to it. Hell, you could even start a related 
'timeout' FSM that sends message at specific intervals to your own FSM 
and manage that one, rather than doing it all through the more 
restrictive interface.