A different icon state for the pushback/recoil is a quick go-to.

There has to be another way. I remeber doing strafing for some of my games back in the day, and I don't remeber my character walking when moving sideways. I will try, use flick(). But, a movement animation variable would be very nice. considering how important movement is to interactions. I'm very surprise BYOND doesn't have one.

Im aware of how to do that, but I feel I shouldn't have to do that when I already have a state for that. Many mob icons have two states for movement already. The movement state and nonmovement state the name for these states are typically blank. Its redundant to create another nonmovement state with the same exact graphics because I can't turn off the movement animation with a simple variable. I shouldn't have to add this redundant state to all my overlays and to all my mob icons just so the recoil doesnt animate steps. One thing we try to do as developers is to create ways to do things more efficiently, and if there really isn't a way to turn movement animations off with code which I find hard to believe, then I will suggest it as a feature request.

A variable to scale animation speed (so 0 would disable animations) has been pretty highly requested. It's not really practical otherwise.

Technically, you can use icon procs (mainly icon() and icon.Insert()) to convert states to M-states. You can then automate the process of converting an icon file into one with a strafing state (you can save /icon objects as icon files with fcopy()), and apply this process to all of your mob and overlay icons.

Personally, I don't use M-states because I'm aware of this limitation ahead of time. You have more control over whether your character is playing the animated movement state if the movement state is actually a non-M-state with a different name. Basically, icons have separate icon states: "standing" (or blank), "walking", "running", "jumping", etc.

The more control you want over any given feature of the BYOND engine, the more work you have to put in to not use the built-in feature at all. The extreme end of icon animation control is only having single-frame icon states, animating them at runtime using animate(), giving you full control over the animation speed and avoiding duplicate icon frames in the file. Maybe not practical, at least until someone comes up with a good framework for this kind of stuff, but the option exists. Just don't use a feature (M-states) if it's not what you want.

I mean, the idea behind directing animation play rates at the server level is something that's really difficult to integrate, because by the time the server has notified a client of the change, the client is at an indeterminate point in the animation.

Because icon state animations are handled on the client, what these changes actually mean visually for each client is difficult to say at best.

The abstraction of networking BYOND allows also comes with inherent sacrifices. It's... Just sort of a beast of a problem.

Animate()-based single-frame animations and cycling play-once animations are a good enough option, but again, every implementation has its own inherent costs and benefits.

It's why I'm loathe to release the many frameworks I've designed, because those that don't design them often don't understand how to leverage them effectively, and I don't like feeling like I've set someone up for failure down the road.