QSB network protocol

[revelator]

definatly and about time

compression would be nice to.

[frag.machine]

I've always wondered why a new protocol was needed for something like movement prediction of the character and why no NetQuake engines support the prediction. Isn't just simply doing the same movement code that the server does on the client as well?

Short answer: no.

A bit longer answer: "doing the same movement code that the server does on the client as well" is not enough because you don't have in the clients all the info gathered by the server. You would need all the clients exchanging with each other their states. This is not practical, and actually not client-server anymore (because nobody would be authoritative like a server to say "hey client A, this rocket is not where you're supposing it is").

[Downsider]

I've always wondered why a new protocol was needed for something like movement prediction of the character and why no NetQuake engines support the prediction. Isn't just simply doing the same movement code that the server does on the client as well?

Short answer: no.

A bit longer answer: "doing the same movement code that the server does on the client as well" is not enough because you don't have in the clients all the info gathered by the server. You would need all the clients exchanging with each other their states. This is not practical, and actually not client-server anymore (because nobody would be authoritative like a server to say "hey client A, this rocket is not where you're supposing it is").

Well of course paradoxes and the like would be bound to happen, although not very often, would they? What additional information would the client need about it's surroundings?

I mean a very basic movement prediction. Something like colliding with only the world, as opposed to colliding with moving entities and players. Things like entities could be interpolated, though, over a course of like a hundred milliseconds, couldn't they? Is that how QuakeWorld handles events such as this? I notice that events like firing weapons and the path of rockets and such are not even predicted in QuakeWorld, as when I fire my weapon, if I were to rocket jump, I would have to click, wait a few hundred milliseconds, then press jump, or else the rocketjump will fail in a horribly embarrasing way

[mh]

I've always wondered why a new protocol was needed for something like movement prediction of the character and why no NetQuake engines support the prediction. Isn't just simply doing the same movement code that the server does on the client as well?

Short answer: no.

A bit longer answer: "doing the same movement code that the server does on the client as well" is not enough because you don't have in the clients all the info gathered by the server. You would need all the clients exchanging with each other their states. This is not practical, and actually not client-server anymore (because nobody would be authoritative like a server to say "hey client A, this rocket is not where you're supposing it is").

Well of course paradoxes and the like would be bound to happen, although not very often, would they? What additional information would the client need about it's surroundings?

I mean a very basic movement prediction. Something like colliding with only the world, as opposed to colliding with moving entities and players. Things like entities could be interpolated, though, over a course of like a hundred milliseconds, couldn't they? Is that how QuakeWorld handles events such as this? I notice that events like firing weapons and the path of rockets and such are not even predicted in QuakeWorld, as when I fire my weapon, if I were to rocket jump, I would have to click, wait a few hundred milliseconds, then press jump, or else the rocketjump will fail in a horribly embarrasing way

Collision testing is all done server-side, enabling it on the client would open up the possibility of walking through walls and suchlike which could be exploited for cheating.

If you're interested in the development of prediction, and why certain decisions were made, you could do a lot worse than read Carmacks .plan files from the time he was working on QuakeWorld.

I personally haven't looked at the QW prediction code in any great amount of detail, but I'd expect that the main reason why a new protocol is needed would be that the client needs access to a whole bunch of information that would otherwise be only available to the server.

[Downsider]

I meant enabling it on both client and server, MH. The clientside one being the one predicting, the server being the one correcting the client's prediction.

[Spike]

Ceriux:
if the mod is developed explicitly to use extensions, clients will _need_ extensions and that wipes out the player base.
If it doesn't use those extensions, then why bother with supporting those extensions. Someone has to be brave and popular with it too. :P

Downsider:
QuakeWorld predicts only players.
The client generates a new input frame periodically, and sends it to the server along with the time delta since the last packet. The server runs a player-only physics frame to apply that packet to the server state before sending a response.
Non-QuakeWorld engines run every client periodically. Only the last-known input state is used, and there is no durations or anything. Duplicate/doubled packets are ignored. As such, regular NQ servers cannot be predicted anywhere near reliably.
LH tried to get DP predicting regular NQ servers. Not sure what happened with that. DP servers use the echoed sv.time in the client's packet for prediction, the rest is like QW, just with NQ physics.

[qbism]

Can interpolate between message timestamps, and "extrapolate" to go beyond 0.1 sec. For any entity in motion I recall, players, rockets, etc.

Code: Select all

/*
===============
CL_LerpPoint

Determines the fraction between the last two messages that the objects
should be put at.
===============
*/
float   CL_LerpPoint (void)
{
   float   f, frac;

   f = cl.mtime[0] - cl.mtime[1];

   if (!f || cl_nolerp.value || cls.timedemo || sv.active)
   {
      cl.time = cl.mtime[0];
      return 1;
   }
   //qbism CSE 00-05-28 f can often be >0.1 on a high lag connection... try 0.3
   if (f > 0.3)
   {   // dropped packet, or start of demo

      cl.mtime[1] = cl.mtime[0] - 0.3;
      f = 0.3;
   }


   frac = (cl.time - cl.mtime[1]) / f;
   //Con_Printf ("frac: %f\n",frac);
   if (frac < 0)
   {
      if (frac < -0.01)
      {
         SetPal(1);
         cl.time = cl.mtime[1];
         //            Con_Printf ("low frac\n");
                              }
      frac = 0;
   }
   else if (frac > 1)
   {
      if (frac > 1.01)
      {
         SetPal(2);
         cl.time = cl.mtime[0];
         //            Con_Printf ("high frac\n");
                              }
      frac = 1;
   }
   else
      SetPal(0);

   return frac;
}

I haven't looked at this in a long time (from timefrag, ideas stolen from DP, fenix and others). Need to do some other stuff like movetrace in R_BlendedRotateForEntity to keep things out of walls. Has anyone carried this concept further?

[Downsider]

Well, if I'm not mistaken and I'm understanding the concept correctly, if it was only the world, and other clients were irrelevant, then movement prediction would be entirely feasible without protocol change, no?

[qbism]

Yes, this example is all client-side, no protocol change. It just keeps each entity moving in a straight line until it hits the world or reaches time limit.

[Downsider]

I meant prediction of the player's view, though, not other clients. Other clients can be interpolated fine, I can assume, without any protocol change or modification whatsoever, although to be accurate in being shot, their positions would have to be stored on the server over the last second or so, and then jump back in time or sommadat.

But thanks to all the posts in this thread I'm really understanding the concept now. I've also read a few articles and essays on the subject and feel confident that I can make a functional prediction system for my game, albeit with some changes to the protocol. Thanks, guys!