Quote:
|
Originally Posted by Thanks Spiderman
That's fair enough, but what if the client didn't let you run through a body block in the first place? Isn't that just a matter of updating the client side?
|
The client isn't "letting" you run through a body block; the client does not think a body block exists in the first place. It thinks there's a big enough hole between the monsters that you can and did run through. The problem is that the hole your client let you run though doesn't exist on the server, so you're going to get yanked back the next time your client's display is reconciled with the server's reality.
The problem could be minimized by doing automatic resyncs more often, resulting in smaller rubberbands. But that comes at the cost of requiring really, really good connection speed and much more bandwidth, particularly on a-net's side. And that's expensive. Probably prohibitively expensive.
The problem could be eliminated by completely removing the client's ability to predict positioning and always wait for the server to send it a new state. But that would require ludicrously fast connection speeds and even more bandwidth. That's definitely prohibitively expensive.
A third option would be to try to make the client "smart" enough to recognize situations where you just went through a small hole between monsters and to ask the sever for a resynch whenever that happens. That would solve most of the rubberbanding issues without too much of an increase in connection speed or bandwidth requirements. Why doesn't a-net do this? I'm not sure if (a) they haven't thought of it, (b) they can't get just-went-through-a-small-hole detection working well, (c) it turns out that you pass through so many small holes that the bandwidth increase wouldn't be trivial after all, or (d) they're afraid of malicious/stupid people crashing the servers by getting into situations that cause their clients request a huge number of resynchs in a short period.