Using the Server reconciliation section I'm confused by a few things.
Now, at t = 250, the server says “based on what I’ve seen up to your request #1, your position is x = 11”. Because the server is authoritative, it sets the character position at x = 11. Now let’s assume the client keeps a copy of the requests it sends to the server. Based on the new game state, it knows the server has already processed request #1, so it can discard that copy. But it also knows the server still has to send back the result of processing request #2. So applying client-side prediction again, the client can calculate the “present” state of the game based on the last authoritative state sent by the server, plus the inputs the server hasn’t processed yet.
Why re-apply the last known server state and then the other states we know to exist that the server hasn't seen yet? Why not just validate that the last known server state is in our local list and it matches our local list values and then discard it and NOT re-apply it locally?
Also in the example's he's using he's sending "move 1 unit right" vs Valve's idea of "+move right" command. In this case this is more of a key down/key up commands being sent idea. If that's the case then yeah we'll be getting snapshots from the server of where it says we are, but we wouldn't be saving commands on the client like "I'm at 15,0,25 #1" to compare against. So what is this article really talking about here vs Valve's?