When you flick something in vis_contents, it always uses the south icon_state for that flick even if the vis_contents uses the flag VIS_INHERIT_DIR
Numbered Steps to Reproduce Problem:
1. Have a mob that has a vis_contents sprite with vis_flags to include VIS_INHERIT_DIR
2. Turn the mob any direction other than south
3. Flick the vis_contents sprite and notice it always flicks the south facing sprite ignoring the mob's dir
See discord for example project.
Code Snippet (if applicable) to Reproduce Problem:
/world
fps = 25 // 25 frames per second
icon_size = 32 // 32x32 icon size by default
view = "15x15"
maxx = 1
maxy = 1
maxz = 1
/mob
step_size = 8
icon = 'mob.dmi'
icon_state = "base"
var/atom/movable/vis_obj/overlay_holder
/mob/New()
overlay_holder = new()
vis_contents += overlay_holder
x = 1
y = 1
z = 1
world << "Arrow keys to turn"
world << "Click mob to flick overlay_holder"
/atom/movable/vis_obj
icon = 'mob.dmi'
icon_state = "overlay"
vis_flags = VIS_INHERIT_ID|VIS_INHERIT_DIR|VIS_INHERIT_LAYER|VIS_INHERIT_PLANE
appearance_flags = RESET_COLOR
/atom/movable/Move(NewLoc, direction)
dir = direction
/client/MouseDown(object, location, control, params)
flick("overlay_flick", mob.overlay_holder)
Expected Results:
vis_contents getting flicked should respect the mob's dir. In example case, the green arrow should point the same direction as the other arrows.
Actual Results:
vis_contents getting flicked always uses south facing sprite. In example case, the green arrow always points south even if the red arrow is facing another direction.
Does the problem occur:
Every time? Or how often?
Always
In other games?
Yes
In other user accounts?
Yes
On other computers?
Yes
When does the problem NOT occur?
If you flick something that isn't in vis_contents (such as the mob's sprite) it will respect direction.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Unsure. This issue replicates in 514.1589 too so it may be a long standing bug.
Workarounds:
Manually implement the behavior of flick, or don't use vis_contents if you need to flick.
