I can take a look and see if integrating it into the rules system caused some wackiness, but I can tell you that we rarely have issues with false positives from the warp code. If the rules system is working correctly (which I will certainly check into), then you should be able to increase the threshold and make it more lenient, if that's a problem with it.
To address Fault's combative posts, the code isn't written in a shitty way, in fact, it's very straight forward (as far as detection is concerned): it checks the updated position point that the player sends to the server against where the server says the player is, then it checks the rules to see if that's an acceptable amount of movement or not. It's up to the ServerOp to decide what's acceptable for their servers, but the default values are the settings that we currently use.
As far as the 6 boxing thing is concerned, we don't allow that on our server, so it's not a problem for us, but yeah client lag can cause the client to not update its position with the server just as well as server lag can, so I can see that being an issue. If a ServerOp chooses to allow players to 6 box, then that will need to be taken into consideration when choosing the warp threshold values.
Cavedude:
I agree with your statement about moving the players back to his or her originating point (pre warp), and we've talked about doing that in the past, but haven't coded that in yet. It shouldn't be too hard to implement, and now that this code has been submitted to the community, if anyone else wants to code that up before we get a chance to do it, please post your update to it.
Thanks,
Dax
Threaded Mode
