Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

QSB network protocol Goto page Previous 1, 2

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic

Should QSB 1.0 require a new network protcol?

Yes |

100%
[ 14 ]
No |

0%
[ 0 ]

Total Votes : 14

Author | Message
--- | ---
reckless Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger |

Posted: Sun Mar 07, 2010 8:03 pm Post subject: |

definatly and about time compression would be nice to.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Mon Mar 08, 2010 1:51 am Post subject: |

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 |

Downsider Joined: 16 Sep 2008 Posts: 477 |

Posted: Mon Mar 08, 2010 3:06 am Post subject: |

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

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Mon Mar 08, 2010 11:38 am Post subject: |

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

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 |

Downsider Joined: 16 Sep 2008 Posts: 477 |

Posted: Mon Mar 08, 2010 11:49 am Post subject: |

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 |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Mon Mar 08, 2010 11:50 am Post subject: |

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 |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Mon Mar 08, 2010 6:02 pm Post subject: |

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 |

Downsider Joined: 16 Sep 2008 Posts: 477 |

Posted: Mon Mar 08, 2010 10:06 pm Post subject: |

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 |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Mon Mar 08, 2010 11:38 pm Post subject: |

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 |

Downsider Joined: 16 Sep 2008 Posts: 477 |

Posted: Tue Mar 09, 2010 4:24 am Post subject: |

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 |

Display posts from previous:

| 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