I'm just adding a recoil effect from firing projectiles and when the character gets pushed back from firing it animations a step or so. What could would you use to removing the movement animation.
| |
Aug 22 2020, 7:52 pm
|
|
Raffile
 |
A different icon state for the pushback/recoil is a quick go-to.
|
just flick() it
| |
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.
| |
It does though... icon states with the same name can have one marked as "movement state" and it will automatically be shown during movement. Change the icon state, and that old movement state will not be shown. So you should have some kind of "took a hit" state that can be switched to when the player is being pushed.
Flick() is just convenient because it will only display the new icon state as long as the animation lasts. It is not necessary at all, you could have a single frame icon state that you switch to. All you need to do then is determine when to switch back to the normal icon state. | |
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.
| |
Chill dude. He is correct. There is no way to disable movement states via code.
| |
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. | |
Thank you for the breakdown. Seems like a very simple request/implementation, is there any particular reason why its been ignored? As of now I will adopted the nonuse of M-states with you. I know both Kaiochao and Ter13 have both developed various systems to bypass such limitations of the engine. But, with all the dramatic changes and additions being made, I feel features that are becoming obsolete or that we have to create our own frameworks for need to be implemented on the engine level. It does a great disservice to those who aren't able or have a hardtime implementing bypasses when we could just correct it in the engine. I understand if we don't have sound solutions, but if we do and its an obvious demand from the community we should put forth steps towards implementing them.
| |
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. | |
Fat Albert wrote:
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. If it's such a simple variable, implement it yourself. You will realize that in order to do that you have to at some point differentiate what type of movement is happening. It's not terribly hard but it should be clear why this isn't really in the scope of the M-state behavior. M-states show when the object is moving. What simple variable do you propose that would accomplish your goal? Moving_but_not_animating_unless_I_say_so? | |