Lost contact with screen objects?

ID:2177680
 
Nov 26 2016, 6:07 am
Resolved
In some rare cases, screen objects did not update properly following a garbage collection on the client. The server mistakenly thought the objects' appearance was not changing.
BYOND Version:511.1364
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 54.0.2840.99
Applies to:Dream Daemon
Status: Resolved (511.1365)
This issue has been resolved.
Descriptive Problem Summary:
I've been playing around with a raycaster which uses a lot of animated screen objects. At some points, the game seems to lose touch with the screen objects and they stop moving. Oddly, if I move my character back to the exact spot where it was when they were lost, they will get picked up again and start moving. If not, they just sit there not doing anything anymore.

Low quality .gifs as I didn't know how long it was going to take to happen...
This is me just moving in a circle. When the screen objs stop moving, I keep moving in a circle and they seem to get picked back up when I return to the same place.


In this gif, when the screen objs stop moving, I change direction and they dont get picked back up, they just sit there.



I'll package up and send you code if you'd like. I'll see what I can trim down first. I'm guessing I can probably pull out a demo
Nov 26 2016, 8:10 pm
Boy, this is gonna be a tough one to nail down. If you can find a way to make this happen on a reliable basis (e.g. a specific set of movements that are automated) that would help a lot.
Nov 27 2016, 12:35 pm (Edited on Nov 27 2016, 12:45 pm)
Sent you a link to the source. Just run it and press either 'a' or 'd' until it happens. Might take 30 seconds or so.

The code that draws the rays is just in DrawRays().
Nov 27 2016, 12:45 pm
It seems to only happen if you move repetitively, either in a continual circle, or alternating forward and back. If I move around randomly, it doesn't seem to happen.
Nov 30 2016, 7:29 am
I got one other person to test it so far, and it does happen for them as well. At least I know it's not just me :P


Nov 30 2016, 7:59 am
The weird thing is it hasn't happened for me yet. Isn't there something you could do like a pre-programmed movement loop that would show the issue, to take all variability out of it?
Nov 30 2016, 7:27 pm (Edited on Nov 30 2016, 8:17 pm)
I just went in and changed client/var/rot to 1, compile, run and dont touch anything. The rays rotate and the glitch does happen after about 25 second and every 25 seconds or so after that.

EDIT: Got a few more people to test it and it is happening for them as well. Happens with or without hardware rendering, although it takes quite a bit longer to happen without, and the whole thing runs MUCH slower.
Nov 30 2016, 8:36 pm
That did it--that and changing the fps to 30, which was much more manageable. It didn't want to run smoothly enough at 60 and I think that was half the problem. Now that I've got it to happen, I think I can get on it properly.
Nov 30 2016, 8:38 pm
Good, I'm not nuts :) Well...
Dec 1 2016, 9:22 am
So far I've found that this does trigger at the time of the client garbage collection. Weirdly however, the problem actually appears to be on the server end! I'm trying to figure out now why the screen objects are not being marked as updated.
Dec 1 2016, 11:58 am
I found the problem, and it's incredibly weird.

The list of screen objects last sent to each user contains an appearance ID, but that ID is not refcounted. When looking at whether a screen object has changed, the server compares that ID to the object's current appearance ID. Normally, there is no chance at all that an appearance change would have the exact same ID.

What's happening in your case is that once the client garbage check hits, the server is told it can let go of a bunch of appearances it isn't using anymore. So it starts reusing old IDs. Shortly after this point, your refresh of the rays is happening such that there's more than one var change occurring in a map cycle. So for instance, ray #1 changes from appearance 5100 to appearance 800, 5100 gets recycled because nothing has seen it yet, and then another appearance var is changed which changes 800 back to 5100 again. The server then goes to check which screen objects have changed, and it doesn't see any difference because appearance 5100 hasn't changed from the last time.

I think the most sensible fix for this is to refcount the appearances in the last_screen list. That should eliminate the problem entirely, because then there will be no way for an appearance to be recycled with the same ID.
Dec 1 2016, 12:12 pm
Lummox JR resolved issue with message:
In some rare cases, screen objects did not update properly following a garbage collection on the client. The server mistakenly thought the objects' appearance was not changing.