Why don't you read some of the well written articles based on actual real games instead of dicking around? Just a friendly suggestion.
Re-inventing the wheel can be fun and meaningful but not when you outsource all the work to the forums.
Please see my last edit
On the other hand, it can be useful to learn by doing rather than by reading. Get a better understanding as to how people came to conclusions rather than just taking them for granted. But yes, I will read.
Edit: So it turns out I've already read the gafferon game articles, several months ago. They describe general techniques which I have incorporated already. However, I'm down to specifics.
The Valve article was very informative, and from that I have deduced 3 major points:
1) Perform a client-side collision check prior to sending a message to the server. This allows the current player to move in "real time", although they may jump backwards if the server disagrees with their collision check.
2) Draw entity updates "in the past". I'm a little fuzzy on this still. This is an example of what I've gathered (Player0 is the observer, Player1 is another player, T = Time in milliseconds)
T=0 - Server says Player1 is at coordinates 5,5
T=200 - Server says Player1 has moved to coordinates 7,7.
Rather than just draw Player1 at coordinates 7,7, perform a client-side smoothing to draw them transitioning from 5,5 to 7,7. If the server is sending updates at an interval of 200ms, then the "smooth" effect will last 200ms.
T=200, the player is still drawn at 5,5
T=300, the player is drawn at 6,6
t=400, the player is drawn at 7,7
This creates a constant 200ms lag.
3) Valve talks about incorporating a "lag compensation" where the server keeps a history of movements. In the example above, if you (Player0) fired a gun at Player1 at T=200, On the server side Player 1 is at 7,7 already although Player0 wont see that until T=400. To compensate, the server re-winds a bit to simulate what would have happened at that time and generates a "hit" if they would have hit.
I want to take this one step at a time. Here is what I have so far.
a) Client - Press "UP" arrow key.
b) Client Movement - This code is called every Xms. Get the client's "Moving In" direction. If moving, calculate collision client-side. If collision is fine, move the client, then send a "Move Up" message to the server.
c) Server - Get "Move" message from client. Flag the player as "move up".
d) Server Update - This code is called every Yms. Go through each player and look for flag to say they've moved. If they have and if they did not collide, calculate their new coordinates and send the coordinates to all players. If they do collide, send the coordinates to the colliding player.
e) Client - Get coordinates from server. Create a new thread to "animate" the movement of the moving player. This is done in a thread so that the client will not need to wait while animating other player's movement.
Part b) I'm not sure about this. Firstly, I'm only processing player input every Xms to restrict the amount of message I send to the server. It goes both ways though. If I'm trying to draw the inputting client in real time, it really can't have a delay. How am I supposed to update the client in realtime as well as limit messages sent to the server?
Part d) If this is checking at a regular interval (Yms) to reduce the number of messages sent to the client, it *will* be out of sync with the Xms for each client. Haven't wrapped my head around what this will cause for problems.
I am continuously looking for other articles about this but many seem to be a specific question about their code rather than the general model.