Outdoor/Indoor Server Synching with Suggestion
This is a suggestion for Funcom's live code team. Pass this on if you will Cz or Cosmik.
I've noticed a lot more problems in indoor missions lately. Invisible mobs and mirror walls to name a few. This is probably due to a more unstable network connection recently. However, some changes to the client/server code might mitigate the problem.
First off, let's take a look at outdoor synching as a baseline (which is still working robust enough as is). The dead reckoning currently used is working well the majority of the time. However, when the client and server desynch, you generally have let the client win. That is, unless the client somehow crossed outside the 9 active 40m squares. In that case, the server wins (has to) and pulls the client back. That's a good design, and given the 120m width of our active region, warping is kept to a minimum. Someone's gotta be awful lagged or the network congested pretty badly for the client to traverse even half that distance.
Now, the problem is that with indoor missions, the active region is far less than 120m wide. It looks like it's actually two adjoining rooms distance. Considering that rooms can be quite small, and can be traversed quickly (especially those 4-door rooms, or L joints), it actually happens quite frequently that the client moves out of the active region. The hall of mirrors is a classic effect. In those cases, the only solution is to retrace your steps and hope that you get back into an active region.
But here's whats puzzling me. Sometimes, if we haven't moved too far out of the active, the game resynch's itself. Unlike the outdoor situation though, the client wins. I understand the design choice here, as warping indoors is somewhat undesirable. However, given the fact that the client needs certain information as it switches active rooms (i.e. mob descriptions), warping the server to the client's position has been causing more problems than it solves. We're getting invisible mobs (the client missed getting the mob descriptor).
What I'm suggesting now, is to just treat indoor desyncs the same way as you do outdoor. That is, if it ever occurs, let the server win. Warp the client back to where we SHOULD be. That'll take care of the hall of mirrors. And since the server has always been the one deciding what the client sees (i.e. mobs, chests, etc), there won't be any surprise disappearances.
If you're worried about users being jarred by the warping experience, it's still better than thinking everything's okay until you reach that mirror door barrier. Not to mention that it's impossible to target an invisible mob as it currently is.
I know this probably rolls back a lot of the code that you've placed in to make things theoretically smoother. But network realities dictate otherwise. Sometimes, simpler is better.
Tap
