Question about update logic about finitestatemachine HOT 2 CLOSED

Hi dazinator!

Good question. I had to emerge myself into the old code again, so to speak, since it's been some time I updated this library.
There are several answers to this and I really hope some of them make sense (and now that I'm reading the things I wrote again to check for mistakes I recognize that I possibly don't have an answer at all).

History. This is, basically, a library to hold states in games written in MonoGame, since that is where the pain that brought the necessity to write this beauty was from. I used this to negotiate the terms of a network-connection between n game-clients (one of them server) and to initialize the game-clients correctly. The pain was a huge if-else cascade at the beginning of my update-loop I, naturally, wanted to get rid of. And since most of my method being called in the update-loop, naturally, took the gametime as a parameter, so did the update-method you may build with the FSM.
The more general machine without any of the TimeSpan (or, previously MonoGame.GameTime) logic was available alongside this one for some time, but I decided to merge them at some point.

After(TimeSpan t). This only works if I integrate some notion of the update-time. And this
It's a convenience thing that helped me implement network-timeout-handling.
Since you pass the gametime to the fsm.update method and the machine switches states with the after(t) method, the next state has to get a modified (later) gametime than the one that just triggered. So I HAD to expose it in an update() construct for the user to even get the right gametime.
Long story short: If you're into After(TimeSpan t) then you're stuck with update(TimeSpan t).

Replacing that with your switch-suggestion would bring back the switch-state-machine in my update-loop.

I don't really understand the part involving DI to be honest. I know DI, but I don't think it comes into play here. If you pass the gametime to some of your game-objects (like Player), that's always the same gametime. If you pass it 'traditionally' or via a DI-mechanism is irrelevant (MonoGame has a DI mechanism built in, it's called GameService as far as I recall, but it's not used for the time). The consuming class ends up with the gametime object and that's where the FSM call starts.
Even if you passed the FSM to all your game-objects I wouldn't trigger it INSIDE that class's update method. I would send it a trigger and wait for the next call to FSM.update(t) since the update-loop would be the first thing you'd make parallel in your game at some point in time.
But I'm old enough that I realize the potential for misunderstanding here, so I probably got you wrong.

I think you are correct with every one of your assumptions. You may use it without using the update-method (the one you use to 'program' the machine, not the one updating the machine itself), but unfortunately you'd still have to call update, since that one does the transitions and you have to pass some TimeSpan as well. Even if you didn't use the After(t) or the Global.After(t) methods yourself.

I don't know if there is an easy way around this without removing the After-functionality and splitting the library again...

Maybe I could make an overload for FSM.update() without TimeSpan, but then I would have to throw an exception if the user calls update(t) or after(t) in his/her machine and I'd rather not have the developer choose those in the first place (change the model in the builder) and ... now that I think of it... I'm back to the two projects again...

from finitestatemachine.

Closing and archiving as reference.

from finitestatemachine.