vis_contents fails to render in some cases

ID:2359025
 
Apr 3 2018, 8:27 pm
Resolved
Visual contents of turfs weren't properly preserved in some cases on the client, resulting in cases where the visual contents no longer showed up after changing Z levels.
BYOND Version:512.1419
Operating System:Windows 10 Home
Web Browser:Chrome 64.0.3282.186
Applies to:Dream Seeker
Status: Resolved (512.1420)
This issue has been resolved.
Descriptive Problem Summary:
This is an issue that's hard to describe with words. As such, I've made a video of this issue in action here: https://www.youtube.com/watch?v=zToOEQ0RoLI

As seen in the video, when a turf is rendering a turf with vis_contents via vis_contents, moving the mob into the vision of the turf that was previously rendered via vis_contents will result in that turf suddenly failing to render it's own vis_contents. This issue occurs consistently, and makes implementing proper multi z-level rendering more of a chore than necessary.

Code Snippet (if applicable) to Reproduce Problem:
/turf/openturf/New()
    . = ..()
    vis_contents += locate(x,y,z-1)
    color = "#666666"

/mob/verb/moveup()
    var/turf/T = locate(x, y, z+1)
    if(istype(T) && !T.density)
        Move(T)
        world << "You moved up"

/mob/verb/movedown()
    var/turf/T = locate(x, y, z-1)
    if(istype(T) && !T.density)
        Move(T)
        world << "You moved down"


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.)
This issue seems to occur in every version of 512 I've tried.

Workarounds:
Here's the workaround I've been able to implement for this issue. It comes at the cost of moving down z-levels not being as seamless as moving up z-levels
/mob/verb/movedown()
    var/turf/T = locate(x, y, z-1)
    if(istype(T) && !T.density)
        Move(T)
        world << "You moved down"
        if(client)
            sight |= BLIND
            client.eye = locate(T.x, T.y, max(T.z-1,1))
            sleep(2)
            sight &= ~BLIND
            client.eye = src



I apologize in advance if I accidentally posted this more than once. I've been getting an "unable to save to database" error every time I tried to post this, so I've been making some adjustments to various bits of the post in an attempt to get this to actually post
Apr 4 2018, 10:08 am (Edited on Apr 4 2018, 11:22 am)
I don't really follow the issue here, and the video didn't make it clear to me. Do you have a test project you can send my way?

One thing I should explain about how vis_contents works is that it should never allow you to enter into an infinite loop. That is, whenever an object's vis_contents are being converted into icons for display, the object is temporarily marked as off-limits for recursing into vis_contents again. So if A contains B, B contains C, and C contains A, you'll get A, B, then C, you will get a second icon of A but you won't get a second B because A is still processing.
Apr 4 2018, 1:17 pm
https://drive.google.com/ open?id=1C84UWrJjxIkoJNkJI_kfjgMaTVU9bqed Here's the full project I've used for the video. Assets are from the TGstation fork of Space Station 13 and are licensed under CC BY-SA 3.0, etc etc.

To be more verbose as to exactly what's going on in the project, the openturf turfs handle their vis_contents by adding the turf below them to their own vis_contents when they get created. After adding multiple z-levels and layering openturf turfs on top of each other, the issue I described starts to manifest. When using the moveup verb, everything renders normally. The vis_contents of the openturf turfs being rendered inside of a higher z-level's openturf turf's vis_contents renders just fine. However, when using the movedown verb, all openturfs in the new location that were previously being rendered through an openturf's vis_contents in the old location will suddenly stop rendering its vis_contents. However, when using the moveup verb, the issue corrects itself and the openturfs that were previously not rendering correctly will begin rendering properly again.

The workaround I found takes advantage of that little tidbit by moving the client's view one extra z-level downwards, waiting for a brief moment, then moving the client's view back to the mob.
Apr 5 2018, 12:51 pm
Lummox JR resolved issue with message:
Visual contents of turfs weren't properly preserved in some cases on the client, resulting in cases where the visual contents no longer showed up after changing Z levels.