I was not aware that a flick() superseded a current flick(). That gives me a lot of ideas. Good luck with changes to flick, though, as any changes to flick() have been largely ignored.
And while not ideal, writing my own animation system has been something that I've known I would have to do if I ever actually started an action game. And I definitely see your point about synced animations, but there are a lot of situations where flick() isn't ideal, or just doesn't work.
Hiro the Dragon King wrote:
I was not aware that a flick() superseded a current flick(). I had no idea either. It just sounded like something that should work so I tested it out =) That gives me a lot of ideas. Good luck with changes to flick, though, as any changes to flick() have been largely ignored. If there was a greater demand for these features, I think they'd get more consideration. It's not that hard of a problem to remember when flick was last called for each object and include that as part of the appearance. When the server tells the client about an object, it just has to say "this is it's icon, icon_state, layer, etc. ... and 12 ticks ago this other icon state was flicked". And while not ideal, writing my own animation system has been something that I've known I would have to do if I ever actually started an action game. I don't think there's any way around it. It sounds like with a few minor changes it'd be pretty simple to write that. |
You should be able to use flick() to interrupt animations:
Only the first 5 ticks will play. The second flick() doesn't play an animation because the state doesn't exist, but it does stop the first flick which will cause src to be shown using its specified icon and icon_state.
If you can flick looping animations (I have no idea if you can do that, I try not to use flick() much. I just set the icon_state and care if it starts in the middle of the running animation), you can do something like this:
Then you'll just have the problem that flicked animations aren't shown to people who weren't close to the object when flick was called (but that's something that should be fixed anyway).
This all might not be what you'd call ideal, but it doesn't exactly make sense to have animations start based on the time the icon_state was changed (aside from the backwards compatibility problems). If you have a building game and you turn a dirt tile into water, you expect all water tiles to have their water animations in sync no matter when the icon_state is changed.