flick() breaks overlays/underlays

ID:113868
 
May 29 2011, 4:46 pm (Edited on May 29 2011, 5:12 pm)
Not a bug
BYOND Version:482
Operating System:Windows XP Home
Web Browser:Firefox 4.0.1
Applies to:Dream Seeker
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
Using flick() on an atom with overlays/underlays will break overlay/underlay animations.

Numbered Steps to Reproduce Problem:
Add an overlay with a looping icon_state to an atom.
Have that atom flick() a different icon_state.
The overlay's animation loop will jump out of sequence.

Demo:
http://files.byondhome.com/SuperAntx/flick_src.zip

Expected Results:
The overlay/underlay should not be effected unless it has an icon_state matching what is sent through flick().

Actual Results:
Whatever the overlay/underlay is currently looping through will flick() regardless of the icon_state.

Did the problem NOT occur in any earlier versions?
I'm not sure but, I remember at one point overlays/underlays could have their animation completely unaffected by flick(). A lot of people have even asked for a way to flick() overlays themselves. This bug may be related to a recent update. Still broken in 481.
Jun 2 2011, 7:48 pm
I've noticed this in our current project and HiroTheDragonKing will see it soon when he tests the current build. I have a punching animation for the player and when the actual punch is flicked it breaks the shirt overlay I have on the players.

It doesn't happen 100% of the time but I can't seem to forcefully reproduce causing it or fixing it.

Also, yes, the overlays do have named animations with proper timing for the flicking state.
Jun 7 2011, 10:18 am
As I understand it the issue is just that the sequence of the overlays changes from its current point of animation to instead be based on whenever the flick started.

This is a toughie to resolve, because the way flicks work currently is by creating a temporary copy of the main icon and all overlays and applying the changes of the flick to everything, then for the duration of the flick only the copies are shown. This also impacts images, in that /image basically completely overrides flick() and can't be affected by it.
Jun 7 2011, 10:44 am
It's something which really aught to be addressed because it makes me cringe seeing professionally drawn spell effects have their animation sequences completely butchered.

The best solution I can think of would be to have some sort of variable I could set on an /image object to have it just ignore flick(). That way I could have looping spell buffs on targets without them getting mixed up with their other overlays, things like clothing and weapons which must obey flick().
Sep 14 2011, 9:47 am
Closing this as a non-bug; flick() changes really fall under feature requests.