Question about QuakeWorld
Moderator: InsideQC Admins
5 posts
• Page 1 of 1
Question about QuakeWorld
How is movement handled in QW?
Is it entirely clientside, then positional packets sent to the server?
Is movement logic done on both client and serverside, and it simply sends key inputs?
Is there a way to replicate it using CSQC, rather than a total rewrite of the network code?
Is it entirely clientside, then positional packets sent to the server?
Is movement logic done on both client and serverside, and it simply sends key inputs?
Is there a way to replicate it using CSQC, rather than a total rewrite of the network code?
-

Downsider - Posts: 621
- Joined: Tue Sep 16, 2008 1:35 am
movement is calculated both clientside and server side.
clientside is just a prediction with the unacknowledged movement frames applied to the last-received server state.
the actual predicition for the standard player physics is exposed via a builtin named 'runstandardplayerphysics', which... runs the engine's standard player physics. For a QW engine, this is QW physics.
For an example of running prediction within csqc, consult FTE's csqctest mod, in fte's trunk/quakec/csqctest subdirectory on the svn.
prediction.qc is the file that updates the current origin, while player.qc is responsible for getting the current player origin from the server and animating the player locally (the way player.qc is set up is to faciliate local animations (read: q3 player model replacements or potentially skeletal animation blends)).
clientside is just a prediction with the unacknowledged movement frames applied to the last-received server state.
the actual predicition for the standard player physics is exposed via a builtin named 'runstandardplayerphysics', which... runs the engine's standard player physics. For a QW engine, this is QW physics.
For an example of running prediction within csqc, consult FTE's csqctest mod, in fte's trunk/quakec/csqctest subdirectory on the svn.
prediction.qc is the file that updates the current origin, while player.qc is responsible for getting the current player origin from the server and animating the player locally (the way player.qc is set up is to faciliate local animations (read: q3 player model replacements or potentially skeletal animation blends)).
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Now, as far as I know, and correct me if I'm wrong, the Source engine uses methods similar to this?
Now, why can a player download and use a speedhack if this is the case? Wouldn't only his clientside prediction show up further ahead, and one it gets the corresponding packets from the server, it would be shot back to where he should be?
Also, is it possible to communicate client -> server variables with CSQC?
Now, why can a player download and use a speedhack if this is the case? Wouldn't only his clientside prediction show up further ahead, and one it gets the corresponding packets from the server, it would be shot back to where he should be?
Also, is it possible to communicate client -> server variables with CSQC?
-

Downsider - Posts: 621
- Joined: Tue Sep 16, 2008 1:35 am
the movement frames contain a duration. if you change that duration, you can tell the server that 500 seconds passed within a single second.
The server needs to protect against that a bit, although with major packetloss, its possible to get false positives.
and... stuffcmds. :s
localcmd("cmd blah\n");
:(
there's a sendevent builtin too
The server needs to protect against that a bit, although with major packetloss, its possible to get false positives.
and... stuffcmds. :s
localcmd("cmd blah\n");
:(
there's a sendevent builtin too
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest