No. Why would you think that?

From what I figure- the clients should only send updates when their state changes right? ie 1000xxxx (think up, right, down, left, 4 reserved bits) then lets say they walk up for some amount of time then they stop moving now we get a second packet 0000xxxx and the server stops them moving. Is this a good idea? It seems to have the least amount of traffic in a design that I can think up. The only thing I worry about is the server could potentially get hung up with someone flooding it with commands (repeated presses of a key like up thus sending many update packets) and as you can see from the server design that could cause lagg. Maybe I will need to code a lockout timer 5 commands per 5 seconds or something like that ideas?

I added a thread to run updates on the players and such; while the other threads if they find nothing will yeild their timeslice to the update thread to make sure things keep going smoothly(so I hope).

Posted before I realized I don't have all the threads posted....

So I have the following threads:

Check for incoming connections - yields there is enough time for it to come back only checking one socket in this case so it is quick doesn't need to check twice.

Check for data on existing connections - does not yield connections could have data any second now....

Pull commands off the stack and execute them - yields with no commands

Update players, NPCs, Monsters, bullets, etc

You have a thread that will always be checking out on the listener. You also have a thread that will always be checking for incoming commands from the clients/players.

TCP actually - The server doesn't "miss" packets although I could put an ACK in there to make sure the client knows the server got the data... The server queues commands up with an identifier and a char* with the command and params.

void Server::Initalize(short PORT)                                         //Calls mysocket::startup() and starts listening on a socket for incoming connections.
  {
      Port = PORT;
      Listener.Startup();
      _beginthread(Listen,0,(void *)this);
      _beginthread(Check_Connections,0,(void *)this);
  }

So I start two threads to handle communications and new connections. Now this main thread goes back to main and basicly goes and grabs commands off a stack the server is pushing commands onto. Now lets say people don't send any commands (Test_Server->Get_Command() == NULL) - there is nothing for my guy here to do so he yields that timeslice to someone who needs it.

while(!kbhit())
    {
        do
        {
            testcommand = Test_Server->Get_Command();
            if(testcommand)
            {
                HandleCommand(testcommand);
            }
            else SwitchToThread();
        }
        while(testcommand);
    }

It also does this while listening on incoming connections for a performance boost I hope.

and if you want to see how I handle commands:

Wondered why I kept reading things about 28.8kbps modems... that was written in '97.

But you say I am wrong go read that page yourself technically speaking that is what I had said earlier.

"•Schedule events in the future if you want them to happen simultaneously for all users. "

No, this is not what you said. If this is what you were trying to say then you've either totally misunderstood it, or you've worded it extremely poorly.

It is referring to individual events. For example, jumping: This can easily be scheduled a short time in the future whilst still feeling responsive by adding a "crouch" period. So, the user hits the "jump" key, he sees his character start crouching and so it feels to him like there is immediate feedback; however, the message then travels off to the server at which point the server (immediately, or as soon as possible given the network latency!) notifies other clients of the players intention to jump. The actual lift-off only occurs a short (say 300ms) later than the original player hit his jump key.

Other players will see the player jump at roughly the same time as the player himself jumps; however, if they look really closely, they might notice that he didn't crouch at all.

This is what it is talking about when it says "scheduling events in the future". A few things to note: if you try to employ this technique alone to hide all latency, then the game will start to feel clumsy. So this is just one "trick" in your toolbox of latency hiding techniques. You can't use it everywhere, and so it should not be a mechanic underlying your entire client/server communication engine, or else you will not have the flexibility to use other techniques.

No. Go away.

So you're saying the server gets the user input, processes it for physics, etc, and then sends the command for jump to every client including the user to jump. It would solve packet loss (somewhat keeping events in order) but 300ms is a lot of time.

Everything that article says about latency is as applicable now as it was when the article was written, because guess what, the speed of light hasn't gotten any faster, and this is what latency ultimately comes down to.

The 300ms example I gave was a specific case where one wishes to guarantee (or at least ensure a high probability) that a particular event will occur at the same time across all clients. ~250 ms is roughly the "worst-case" that any good modern multiplayer game will deal with gracefully, even to this day. As I already said, this is just one technique and is probably not even appropriate for jumping. I just gave this example because I hoped that it would be easy for you to understand as comprehension is evidently not your strong point.

I suggest that you give up now, as you're clearly not even intelligent enough to be capable of discerning good advice from bad. You really haven't got a clue what you are doing, and I don't even know why I'm bothering to post in this thread. I guess it was more out of pity because the primary contributor, other than myself, was verthex who is the #1 bullsh*tter on these forums, and so I felt it my duty give some useful information to counter his "noise".

So you posted a shitty article and now you know something. What experience do you actually have making client server games and if you've never made a FPS please don't reply. Thats what David is trying to make and so am I.

Hows this bullshit when everyones talking about it?

Translation:

I shall respect your wishes!

I think you're both reaching too high. Start with something simpler. Its pretty much the same as trying to make an MMORPG right out of the gate. You will fail. Probably multiple times.

It's just a very common occurrence. A beginner comes along and says "I want to make an MMORPG" or "I want to make a RPG" or "I want to make an FPS", and inevitably, they spend more time fighting with the simple issues like timing and bliting, and give up.

Of course if you go into it not expecting to make the "BEST GAME EVER!", and know you're likely to restart several times, that's ok.