Phoron overlay still gets stuck

[PsiOmegaDelta]

How to reproduce

• Fill an area with enough phoron to create the overlay
• Scrub the area
• Note that occasionally phoron sticks around

Notes
Thought I saw a fix not long ago, seems the issue remains tho.

[Gamerofthegame]

Some time ago I found that clicking the tile would force it to update. I can't say whether or not it does so now, still, though that could be a fix.

[mloc]

When was this?

[PsiOmegaDelta]

This was yesterday, saw it happen earlier today as well.

Edit: Around 20:00 GMT.

[Gamerofthegame]

If you mean me, I couldn't say... Months ago?

[mloc]

Did anything special happen to those 6 tiles? If you stood in them, did they have phoron while the rest of the tiles didn't?

[PsiOmegaDelta]

I'm unsure, people were rightfully worried about passing through and I only vaguely remember that someone other than borgs /non-hardsuited people may have done so.
It certainly refused to be scrubbed away.

[mwerezak]

I've seen this happen at the end of the science maintenance tunnel right by aft-starboard solars, after a toxins meltdown.

[Wrongnumber]

Can confirm i've seen this in-game before. Var checks showed the actual amount of phoron left to be extremely low. Far lower than the overlay should be acknowledging.

[mloc]

I fixed one bug that was causing this in zones that had changed geometry very recently, but it should have been on the server yesterday.

[atlantiscze]

I can confirm this is common issue when toxins meltdown occurs. Phoron can be normally scrubbed, but the overlay will remain there. When scrubbed properly it's purely visual.

[mloc]

Can't reproduce. Is it always only showing up on certain tiles?

[PsiOmegaDelta]

I feel it might actually have be consistent in where it happens. Seen it twice in the corner mwerezak mentions, the science maintenance tunnel by the aft-starboard solars access.

[Gamerofthegame]

Quite a few times in the SE corner of the engine room.

[MistakeNot4892]

Just had this again after a phoron fire in Toxins on master.
http://i.imgur.com/T9jV9qa.png

[Vivalas]

I have also seen this happen once in the SW solars, it was one tile, and I freaked out and put a gas mask on. It is rather annoying bug. It only happens in certain areas I guess. I don't know if it is related to scrubbing or not, but toxins vents properly. I was the AI a long time ago (couple weeks) and there was a phoron leak in Toxins. The air scrubbers sucked the phoron out fine.

[PsiOmegaDelta]

Potential cause: It seems that dynamic lightning splits areas into sub-areas based on light strength.
To acquire all areas that belong to each other one need to iterate over the list related in var/area.

I've noticed this has caused some odd effects with the jukebox where different areas of the bar don't always get the same ambient music (mostly noticeable when going between the shaded smoking corner and the rest of the area).

[GinjaNinja32]

If this is dynamic lighting, it should be fixed on dev-freeze. Hopefully.

[Dennok]

No. This is not lighting. ZAS system add overlays to turfs in zone, or remove. Problem in removing after zone rebuild. some turfs forbid ebout his gas overlays. Also can be in percent overlay calculation.
In debug mode turfs wisch stuck owerlay is brown.

[GinjaNinja32]

Easy reproduction, works on current dev-freeze:
build this and smash the right-hand window

[atlantiscze]

I am currently looking into this. I have a feeling this is something with ZAS zones being merged/split and "forgetting" about the overlays. I'll try to run some tests to confirm this.

[mwerezak]

I can confirm that the cause of this issue is that the same overlays are being added multiple times to turfs. While extremely unsatisfactory for other reasons, the following alteration to turf's update_graphic() does solve the issue:

/turf/var/list/overlays_debug = list()
/turf/simulated/proc/update_graphic(list/graphic_add = null, list/graphic_remove = null)
    if(graphic_add && graphic_add.len)
        graphic_add = graphic_add.Copy()    
        for(var/image/I in graphic_add)
            if(I.icon_state in overlays_debug)
                world << "[src]: [I.icon_state] overlay collision!"
                graphic_add -= I
            else
                overlays_debug[I.icon_state] = I
        world << "[src]: Adding [graphic_add.len] overlays."
        overlays += graphic_add
    if(graphic_remove && graphic_remove.len)
        overlays -= graphic_remove

[Kelenius]

In that case, would replacing += with |= help?

[PJB3005]

It should, unless |= doesn't work on the overlays list

[mwerezak]

It would, but it would also be a bandaid fix. In an ideal world we would find out why the zone-level code isn't catching on to the fact that the overlays already exist on their constituent turfs instead of checking when applying the overlays to the turf (or rewrite the system so that the zone isn't responsible for that anymore).

Given how long this issue has been open, I think it would be better than nothing though.