ID:1033011
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
It would be great if we could supply an argument to flick that would cause the flick() call to be ignored if the same icon_state has been requested to the same object.

Syntax / Format:
flick(icon or state, atom, override)
if override == 1
flick to this icon_state animation right away, regardless of what is happening
if override == 0
flick to this icon_state animation only if we are not currently playing the requested icon_state animation


Example:

The following example will keep trying to flick m into the attack icon_state as fast as world.tick_lag
turf/wall
density = 1
Enter(mob/m)
if(ismob(m))
flick("attack", m) //we will never actually see this animation as long as the mob keeps trying to enter the wall
return ..()


The following example is a work around:
mob/var/tmp/flicked = ""

turf/wall
density = 1
Enter(mob/m)
if(ismob(m))
if(!m.flicked)
m.flicked = "attack"
flick("attack", m)
spawn(8) if(m) m.flicked = ""//wait the length of the animation and then reset flick... have to check if m is still connected and alive though
return ..()


This requires an extra variable to keep track of on every single mob you'd want to have this type of functionality.

Requested functionality:
turf/wall
density = 1
Enter(mob/m)
if(ismob(m))
flick("attack", m, 0) // optional argument indicates we do not want to override the animation if it is already in "attack" icon_state
return ..()


Thanks for reading and considering.
+1
++ Could've sworn I posted my support on this already, oh well.
Tiny bump :>
+
It's an extra, optional argument for flick(). Read again?

What I gather from this request is that, when you're spamming punches, you aren't shown as the first frame only. Useful, I suppose.
Bump, Can we please have this?

Another thing is we need a flick bail...

flick(-1, src) //cancel current flick


Another thing to maybe include is the ability to flick to a movement state and ignore it as an animation, essentially just canceling the current flick, setting the icon_state to that movement state, and resting on frame 1 like by default.
Cloud Magic wrote:
I don't understand why you can't just design a system yourself that would do this. I don't think I'd ever find myself using this. "AN EXTRA VARIABLE FOR EVERY ATOM? OH LORD"

It's not possible to write it your self because:

1. When you set the icon_state, the first frame is not guaranteed to be frame 1 at the time of changing it. This is because BYOND uses a global frame index.

2. You can't interrupt a flick unless you flick with something else. So, if you want to stop a current animation and switch to a movement state, its impossible.

If you're still having trouble understanding what this is all about, here's a scenario...

You have a game with social animations. Characters have a speaking, walking, and breathing animation. Let's say a character begins to say something but immediately starts moving shortly after the talking animation has already begun to animate. The walking animation is a movement state, and only animations while moving... We want the movement animation to interrupt the talking animation, and we only want the talking animation to play for its entire duration and then stop, and it must start on frame 1 because the animation was designed that way. If we set the icon_state of an atom while its flicking, the change isn't visible until the flick is done, and if we flick over the current flick with the movement state, it will actually play the moving animation even if we are not moving at that exact tick(lets say we just took one step!). We also want to return to a idle animation loop when we're not stepping. This becomes even more complicated if some animations have a "beginning" "middle" and "end" state. For example, a "talking stance" where we show the character going to a more comfortable standing stance before speaking, then a "middle" state of the actual talking loop, and finally an "end" state where we pass back to normal standing stance from talking stance.

This isn't possible to accomplish with the current system because even if you know the lengths of all the states, its not possible to override flicks, and if you disregard flick altogether, setting icon_states will never guarantee your starting frame. We also have no way to cancel a flick elegantly because the only way to stop a flick is to flick with something else.
Update: I found something interesting, you can set icon_state, and then flick the atom with the atom to cancel a flick...

flick("jumping", src) //ok now we are animation
src.icon_state = "stand still" //set the icon_state in the background
flick(src, src) //stop jumping!