Inside3D!
     

QSB network protocol
Goto page Previous  1, 2
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  

Should QSB 1.0 require a new network protcol?
Yes
100%
 100%  [ 14 ]
No
0%
 0%  [ 0 ]
Total Votes : 14

Author Message
reckless



Joined: 24 Jan 2008
Posts: 390
Location: inside tha debugger

PostPosted: Sun Mar 07, 2010 8:03 pm    Post subject: Reply with quote

definatly and about time Smile

compression would be nice to.
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Mon Mar 08, 2010 1:51 am    Post subject: Reply with quote

Downsider wrote:
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").
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Downsider



Joined: 16 Sep 2008
Posts: 478

PostPosted: Mon Mar 08, 2010 3:06 am    Post subject: Reply with quote

frag.machine wrote:
Downsider wrote:
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 Embarassed
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Mon Mar 08, 2010 11:38 am    Post subject: Reply with quote

Downsider wrote:
frag.machine wrote:
Downsider wrote:
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 Embarassed


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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Downsider



Joined: 16 Sep 2008
Posts: 478

PostPosted: Mon Mar 08, 2010 11:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Mon Mar 08, 2010 11:50 am    Post subject: Reply with quote

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.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Mon Mar 08, 2010 6:02 pm    Post subject: Reply with quote

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

Code:
/*
===============
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?
_________________
http://qbism.com
Back to top
View user's profile Send private message Visit poster's website
Downsider



Joined: 16 Sep 2008
Posts: 478

PostPosted: Mon Mar 08, 2010 10:06 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Mon Mar 08, 2010 11:38 pm    Post subject: Reply with quote

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.
_________________
http://qbism.com
Back to top
View user's profile Send private message Visit poster's website
Downsider



Joined: 16 Sep 2008
Posts: 478

PostPosted: Tue Mar 09, 2010 4:24 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group