Fixed as part of the 'super jump' fix. Pre patch, when client and server data got out of synch, the server data prevailed. When you combine prediction data with collision being client side, you could lag through walls because, based on your heading and speed, the server thought you should be at a given location, and the server didn't know there was a wall blocking you. Now, however, when they get out of synch, the client data prevails, with some sanity checking- ie. your in a given spot moving at a given heading and speed. You lag out. When you re-synch, the server accepts the clients version of your location, so long as it makes sense- so you can be anywhere within a given range- based on how long you were out of synch. So you could be where the server thought you should be, you could have stopped moving (so your closer to your last known location), or changed directions mid steam, so your distance might be correct but your location/heading might be differrent- however you can NOT be further away than it would be possible to travel in a given ammount of time. If you can't run across the zone in 1 min., you can't 'lag' yourself, insert new data into memory so the client thinks your across the zone, and then re-connect and expect the server to belive you. But as long as its a belivable location based on the time you were unaccounted for, it will accept it.
So, while its still possible, its more complicated. You have to position yourself reasonably close to the target wall/door. You have to locate your loc in memory. You lag yourself, change the data in memory, and then reconnect, making sure you would have had time to travel to your new loc, had it been physicaly possible. Personaly, I have yet to be able to attach a debugger to the client and sucessfuly search for data in memory without getting diconected from the server, so finding your loc (assume its going to be a dynamic offset) is a bit of a pickle.
|