In any case, sending inputs is the first thing you learn about client-server gaming. Its primary purpose isn't to reduce bandwidth, its to make sure you can validate what the client is telling you to do (in fact, you should probably periodically send positional information from server to client and/or vice versa anyway as a double check to confirm you're in sync with each other). It is prediction, and the specifics of how you implement it to get the very best apparent performance combined with the least amount of synchronization problems, that is the real magic. And everyone does this a little (or a lot) differently.
yes I read the whole post, some very nice stuff in it, believe it or not I just answered someone on blender artists about this very thing a few days back and now I feel a bit foolish for having answered that way. I didn't explain enough.
so, anyways yeah, you caught me I didn't want to say it was an anti cheating control as well. And as for prediction I actually thought there must be a way to get around without it and without too much lag, I'm sure there is such a way and am still actively thinking about it.
I do have some prediction code in the working though, but that's for another purpose I will not disclose at this time.
The basic way I'm thinking of doing it is to have the client store numbered keypresses (in 24 ms increments, or adding the time if it was lower) (and "go" with them) until it receives a confirmation from the server (of the same message type, no location info at all unless D/C and reconnect or sending initial starting location on a new map) after the server follows that instruction.
give the number store like 7 memory slots each capable of storing 15 keypresses this way and you've got over 100 key press stores, that means over 24 seconds of buffer space. yes it means the client will technically be faster than the server in some conditions but the player will never see it. This also supplies 24 seconds of pure movement before "lost connection from server" and all motion stop is triggered, yet the server's location of that player is the location you are redirected to after such a break.
well at least discussing it helps me write it out.
