Flick() is an awesome proc, but I found out today that if any changes to the icon_state occurs during a flick, the flick() is overridden. So my suggestion is simple, we create a flicker() proc with beefier precedence in the renderer.
The format would be like so:
flicker(Icon/Icon_State, Object, Precedence)
Obviously the higher the precedence, the greater priority it's given on the object. This way if we're flicking an animation, or need to interrupt with a more a urgent animation, we can simply use a flicker() with a higher precedence.
ID:2847479
 Jan 12 2023, 3:01 am
|
|||||||
| |||||||
Oh, good point! It should totally just be an extension of Flick().
So it should maintain flick() default behavior, that way if we want to interrupt a flick, we can do so. But also, it should be overloaded to have an optional 3rd argument that sets the precedence. Brilliant! | |
In a large sense animate() has eclipsed flick(), and should be able to handle these sorts of issues better. I don't think a new type of flick would add any new functionality that animate() can't do better, and would just complicate the engine.
| |
The use case I'm thinking for an upgrade to flick() doesn't really fit into animate()'s function.
In my use case, at the end of my game's movement loop, the sprite's icon_state is updated. So for example, if I were to trigger a jump() function, the movement loop would check to see if I was in-air, then update to being "airborne". However, there is an in-between animation where I go from jumping into the air, and transitioning to "airborne." One would think that flick() would be the key, as I simply want to play a short animation before switching to the "airborne" icon_state. However, since this is in a movement loop, the next tick overwrites the flick() as it sets the icon_state to "airborne." Now, it's possible to have variables in place to get around this limitation, but it would be simpler to just be able to rig flick() to override any icon_state changes until after the animation has been completed. This would make it easier for even more complex situations, such as being attacked while in the air, where one's sprite may need to constantly be animated in an assortment of different manners. Perhaps I'm misunderstanding what animate() does, but it looks like it was intended to simply incrementally change a value that a mob possesses so it animates cleanly on the screen. This doesn't really help with complex sprite changes. | |
Animation should be able to handle the sorts of layered changes you describe, I think. The short animation before transitioning to an airborne state is a trivial thing for animate() to do.
animate(src, icon_state="launch", time=5) | |
If BYOND wants to add this specific case it could just be another argument to flick. No reason to give it a new name.