The programming challenge in addressing the micro-warp issue: Where client (1) perceives player (1) and player (2) to be, where client (2) perceives player (1) and player (2) to be, and finally, where the server thinks both players are; the amount of traffic generated by this data being sent and received to both clients from the server, and possible verification / checksums of this data.
When the connection is interrupted, the server seems to have a great deal of trust in what the client reports when the next piece of date with the client position is reported. I'm confident the limitation is related to bandwidth - the more data going back and forth the more lag for dialup users. Too much double checking, and data verification creates too much traffic per user, multiplied by the number of users, creates more traffic overhead on the game server(s).
If the game were patched to where any discrepancy above a certain tolerance value between where the client next reports the position of player to be, and where the server last knew player position to be exceeds that tolerance value, a certain action could be taken; which is a challenge in and of itself.
Options with unacceptable consequences:
(1). Reset client(1) position to last reported position known by server: This could also be exploited by a player to avoid being shot down.
(2). Immediately end sortie for the player with a position discrepancy: Again, exploitable to avoid being shotdown, and also likely to generate a support nightmare for HTC.
Possibly the best option:
(3). Keep a running count of total position discrepancies for the player. If too many position discrepancies beyond the tolerance occur within a specific timeframe, then generate a popup message advising the player to close the game and reconnect after checking his or her Internet connection. This would generate more processor overhead on the server, but otherwise, might be an option to consider for the developers.
