When the server told the client that turfs with visual contents were no longer needed, the client misinterpreted the message, causing visual glitches.
BYOND Version:512.1395
Operating System:Windows 8 64-bit
Web Browser:Firefox 56.0
Applies to:Dream Seeker
Status: Resolved (512.1396)

This issue has been resolved.
Descriptive Problem Summary:
vis_contents behaves in an unpredictable and seemingly random way when setting it's value directly to a list on turfs. There are also some kind of rendering problems.

This originally came up when I was trying to update our atmospherics system (ParadiseSS13/Paradise), using code similar to, but not identical to

I've been unable to reproduce the exact problems I found there on a test project- vis_contents was outright ignoring updates. Essentially, the difference boiled down to leaving line 119 (atmos_overlay_types = new_overlay_types) outside of the #if directive, therefore giving me something to compare vis_contents to; The only place atmos_overlay_types is set is inside the update_visuals() proc, after vis_contents is set to the exact same variable. And yet, using our debugging tools to compare the variables, the values were different- atmos_overlays_types had the correct list inside of it, and vis_contents was an empty list. These results were reflected in the visual rendering as well.

Numbered Steps to Reproduce Problem:
1. Make a map with icons which is suitably large (I have used 255x255 for my tests)
2. Start a loop that applies a 1-item list of some kind of stand-out visual to the vis_contents of each turf in the map, with suitable sleep() to avoid crashing
3. Include a world << message in your loop to confirm vis_contents has been set to the correct value (I use `world << "[json_encode(vis_contents)]"
4. Observe the inconsistent behavior as you walk along the map- some tiles flatly do not render at first, but if you move them out of range (specifically by walking to the right) and come back, they'll render correctly

Code Snippet (if applicable) to Reproduce Problem:
/world/fps = 60
/atom/icon = 'icons.dmi'
/mob/icon_state = "mob"
/mob/Stat() stat("loc", "[x] [y] [z]")
/obj/effect/New(loc, icon) {. = ..() ; icon_state = icon}
var/obj/effect/plmaster = new(null, "plmaster")
var/obj/effect/slmaster = new(null, "slmaster")

var/list/vis_contents_list = list()
icon_state = "turf"

if(prob(50)) p = 1
else s = 1

var/list/overlays = get_overlay()
vis_contents = overlays
vis_contents_list = overlays
world << "turf at [x] [y] [z] set to [json_encode(vis_contents)]"
if(vis_contents.len != vis_contents_list.len)
world << "ERR [x] [y] [z] [p] [s]"

. = new /list
if(p) . += plmaster
if(s) . += slmaster

. = ..()
src << "starting in 5 seconds"
for(var/turf/T in block(locate(1, 1, 1), locate(255, 255, 1)))
src << "cycled"

var/turf/T = loc
src << "p: [T.p], s: [T.s] | [json_encode(T.vis_contents)], [json_encode(T.vis_contents_list)]"

Expected Results:
vis_contents would consistently render correctly to the user

Actual Results:
vis_contents does not consistently render correctly to the user

Does the problem occur:
Every time? Or how often? Every time.
In other games? SS13.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)
The test project above functions correctly in 512.1391, 512.1392, 512.1393, and stops working in 512.1394 and 512.1395

I think the version number in the report is wrong. Also you mentioned using a test project, but I don't see a link to one. I'll need a project to test.
My bad, the code in the example above is the entirety of the test project code without the resources. Here's a link to a working project.

And, yeah, I managed to screw up the version number- I even double checked it and still managed to miss it.
I'll get on this Monday.
ED: Wrong forum and likely a duplicate of, but maybe a second test case will help somehow. Like that report, the problem is not present in 512.1393.

Descriptive Problem Summary:
Setting vis_contents on many objects at once causes crashes and incorrect display.

1. For a 15x15 or so region of turfs, add the corresponding turf in a same-sized region elsewhere to vis_contents.
2. Move the camera around near these turfs.
3. Observe incorrect display and sometimes crashes.

Full Repro Case for Incorrect Visuals
1. Compile with Dream Maker and run in Dream Daemon.
2. Connect with Dream Seeker.
3. Hold UP until the top of the world is reached.
4. Note the visible blue checkers. These should be obscured by their vis_contents.
5. Hold RIGHT until the right of the world is reached.
6. Hold LEFT until the left of the world is reached.
7. Note the blue checkers have disappeared, replaced by their vis_contents.

More Context
Encountered first while working in SS13, tgstation. The turf layout used is more complicated than the simple rectangles in the repro case, but not much larger in scale. In addition to the incorrect visuals in the repro case, the following behavior was observed:

- vis_contents not being visible, but overlays applied to objects in vis_contents being visible.
- Dream Seeker crashes when moving the player horizontally (but not vertically) near too many turfs with other turfs in vis_contents
- incorrect visuals (but not crashes) when too many objects have turfs in their vis_contents
- incorrect visuals fixing themselves if the client switches mobs while the problem tiles are onscreen (but staying broken if they are more than 2 tiles or so offscreen)
Lummox JR resolved issue with message:
When the server told the client that turfs with visual contents were no longer needed, the client misinterpreted the message, causing visual glitches.
In response to SpaceManiac
Having solved the other issue, I'm now certain this is a duplicate.