Forum

Quakeworld Protocol

Discuss programming topics for the various GPL'd game engine sources.

Moderator: InsideQC Admins

Quakeworld Protocol

Postby Baker » Tue May 05, 2015 11:37 am

I'm slowly acquiring ZQuake into Mark V mostly because it has independent physics and can play NetQuake progs.dat, or at least the standard ones and Travail and I think I'll notice any limitations and possibly address as I proceed.

But I don't want to break true Quakeworld compatability, but already have some curve balls I'm not sure how to handle.

1) Mark V and Quakespasm do "game warp -quoth" or "game add -hipnotic" (or -rogue or in the case of Mark V, -nehahra too). Do I make a serverinfo or something?
2) Mark V tells the client the current skill level in single player. Probably a serverinfo key again, right?

Now here comes a trickier one:

3) I don't plan the bunnyhopping thing being enabled, this is likely detrimental to many single player maps that hadn't considered it (even if speed runners could do it in NetQuake). So the client shouldn't predict bunnyhopping, it should predict not bunnyhopping. Is there a way to tell the client about this?

There's one more. But I'm sure I can figure this out myself ...

4) I don't think DarkPlaces needs to "nqconnect" or "qwconnect" to a server. I should look through the DP source and see how it doesn't need a different command to connect to different types of servers.

Even though this is proving to be a ton of work, I get the benefit of:

a) Seeing how the Quakeworld timing works, especially for independent physics because I want this in NetQuake single player too because I don't want client and server to be dependent on each other,.
b) Get a better handle on sending a better baseline to clients.
c) Hands on with some of the usage other Quakeworld improvements.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakeworld Protocol

Postby Spike » Tue May 05, 2015 2:13 pm

Baker wrote:But I don't want to break true Quakeworld compatability, but already have some curve balls I'm not sure how to handle.

Enjoy writebytes. The network protocol is directly incorporated into each and every progs.dat.
FTE gets around that by implementing half of cl_parse.c and translating it serverside.
ZQuake gets around it by just using the NQ protocols, which basically makes your motivations sound quite silly.

1) Mark V and Quakespasm do "game warp -quoth" or "game add -hipnotic" (or -rogue or in the case of Mark V, -nehahra too). Do I make a serverinfo or something?

QW has no stat limitations. There is no (subtle) protocol change implied by the mission packs. It affects only huds. You can detect which hud should be used based upon the lumps contained within. Hipnotic and rogue being special in any way is silly (and by extension, quoth). Just implement it using multiple gamedirs instead.
Gamedirs are and are not serverinfo. Serverinfo provides listings in server browsers, but the real gamedir the client should use is provided via the svc_serverdata packet directly.
-game should be roughly equivelent to +gamedir, both should have the same effect (just at different times).
sv_gamedir isn't strictly needed, but if implemented overrides the *gamedir key the server specifies.

2) Mark V tells the client the current skill level in single player. Probably a serverinfo key again, right?

Assuming you're running some 'spprogs.dat' or somehow translate an nq progs.dat, yeah, just add that info to the serverinfo - the same way that deathmatch is communicated.

3) I don't plan the bunnyhopping thing being enabled, this is likely detrimental to many single player maps that hadn't considered it (even if speed runners could do it in NetQuake). So the client shouldn't predict bunnyhopping, it should predict not bunnyhopping. Is there a way to tell the client about this?

bunnyhopping is an intrinsic part of quakeworld's prediction logic (which is traditionally always enabled).
you can use pm_bunnyspeedcap 1 in any modern quakeworld engine to reduce the player's speed as they go around corners, crippling bunnyhops to just rocket jumps.
This will still break NQ mods, of course. You'll need to use actual NQ physics if you want to avoid that (see sv_nqplayerphysics in FTE, which disables clientside prediction).

4) I don't think DarkPlaces needs to "nqconnect" or "qwconnect" to a server. I should look through the DP source and see how it doesn't need a different command to connect to different types of servers.

Send both connect requests, see what comes back. You might find special commands handy to avoid needing to remember default ports, or to limit the request in the case of a server that replies to both (in this case, you'll typically find that an NQ 'handshake' completes as soon as you get an ack and thus typically strongarms you into using nq protocols instead - fte has a hack.. err.. extension to prevent the server from replying to certain nq connect requests, allowing it to favour qw protocols for fte clients).

a) Seeing how the Quakeworld timing works, especially for independent physics because I want this in NetQuake single player too because I don't want client and server to be dependent on each other,.

frankly, it doesn't. vanilla quakeworld has absolutely no timestamps in the network protocol. as a result, interpolation is basically flawed over the internet.
There's absolutely no reason you can't have independant physics in NQ. See DirectQ or pretty much any decent nq engine.

b) Get a better handle on sending a better baseline to clients.

vanilla QW baselines are identical to NQ baselines.
the vanilla QW protocol is crippled to 64 ents visible at once to avoid abusive memory requirements. tribes2-style networking as found in dpp5+ or fte's replacementdeltas protocol extension are both much nicer in terms of memory use, and don't have the limitations.

c) Hands on with some of the usage other Quakeworld improvements.

many of the quakeworld improvements can be considered regressions.
It takes a _lot_ of time to fix a QW engine to the point where it can cope with NQ mods correctly - and the only sane way to do it is by not being QW (fte's network translation has its flaws, and there are certain mods for which I still need to provide a way to disable it by forcing the server to no longer accept QW clients).
Spike
 
Posts: 2908
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Quakeworld Protocol

Postby Baker » Tue May 05, 2015 8:12 pm

Spike wrote:vanilla QW baselines are identical to NQ baselines.
the vanilla QW protocol is crippled to 64 ents visible at once to avoid abusive memory requirements.

Strike that from the list. Guess that isn't going to help me then. :( Sounds like I'll have to get my hands dirty with that after all, and build a frame buffer or something.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Quakeworld Protocol

Postby Baker » Tue May 05, 2015 10:48 pm

Spike wrote:Baker, if you want a solution to datagram size limitations, you'll need something like:
http://sourceforge.net/p/fteqw/code/432 ... deltas.txt
Note that its not fantastically different from how DPP5+ sends entities.
That doc *should* give enough info to implement the extension, and will work fine as an upgrade over either protocol 15 or 666 (you may still want 666 as the underlying protocol to provide the svc_clientdata stat changes).
Note that nq support for this protocol is still fairly new in fte, so if you want to test it with an existing implementation be sure to use the current test build of fte.

Anyway, point is that retaining entity state from one frame to the next, resending only when something has changed (which 666 does not do - entities are resent from baseline even when they're idle) will save you both bandwidth and fragmentation-induced packetloss.
QW apparently not then. I need as many entities as it takes and if it still sending all the entities, doesn't help me any.

I'm all in and I'm going to tackle this once and for all, whether it takes 3 weeks and I have to implement it in 5 waves.

I guess I'll be starting with something similar to DPP5 to get the entities deltas right and move my way up to something similar to DPP7.

My check list is:
1) First goal is getting the network traffic down. (DPP5 probably fits)
2) Connectionless connections. Optional. But probably will happen. I don't have quite as much network source code in Mark V as I used to have. ever since merging BSD socks and WinSock :D
3) Getting client and server time independent.
4) Prediction. May need to send all the *bmodels so client has them.

[Reposting an older Spike post.]
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am


Return to Engine Programming

Who is online

Users browsing this forum: Google [Bot] and 1 guest