An open letter to QuakeWorld developers.

[ArchAngel]

Lets' be honest, 15 years on and QuakeWorld is still where it's at for fast paced Multiplayer gaming. Quake2 is dull, Quake3 tried too hard. QW on the otherhand got it so right that we had things like RocketJumping appearing before even ID knew what was going on. But it's appeal has wained now, people demand features like transparent water and realtime shadowing that totally disrupt the QW gameplay... sure maybe I am lurking below the water line on DM3 maybe I'm not... you can't tell so are you prepared to pepper the surface and find out? Maybe I'm round the corner in full view, without a strong shadow, you'll never know. But that's what made QuakeWorld... millisecond precision and a huge heaping of luck. But now we're starting to lose that. COD and the like are amazing if you want an immersive team play enviroment, but if you want pick-up -and-play kill-a-minute fun then we're left with QuakeWorld above all else.

Having said that QW is showing it's age, there are issues and it's stuff we can all put right.

Most suggestions for community based projects fail at the first hurdle. This is that someone has an idea an expect everyone else to do the work. I've turned down project offers for this in the past (a famous one included that has recently upset it's community), what I'm suggesting is a community project that benefits the community. One in which the participents are peers and take an equal share of the work.

What I'm talking about is extending QuakeWorld in an optional manner than allow clients and servers the greatest level of access to a shared set of resources. One where an FTE client can play along side a vanillia client and still not have one call cheating from the other.

I'm talking specifically about features such as the following:

LIT downloads - Sure BSP30 had them builtin but LIT has the marketplace. We need LIT support but with server downloading and checking to ensure people aren't running with a fullbright LIT file.

Master server support - Yeah bog standard QW has this but we end up with issues, like a lack of server browsing from within the QW client. Let's extend and standardise this. Discard requests we don't support and serve those which we do. Personally I'd like to see the Master servers support Trophies ala PS3 and XBOX360.

Faster downloads - The existing download is pitifully slow. Curl is an option but it's not quite right... we've gotta be able to improve on this.

These are my 3 big bugbears that can be improved without killing existing QW clients. I'm open to suggestions that can improve things for all, provided they don't break the existing protocol. Furthermore, I'm not just proposing that others work on this. I want to add these features to my own C# server which I eventually need to consider partitioning so that it will work well with Azure.

At the moment all I'd like to see is a statment of intent, a coallition of QW devs who feel that this would be a worthy aim. If that's you, give a shout below. I look forward to hearing from you.

[Spike]

> This is that someone has an idea an expect everyone else to do the work.

^^

> One in which the participents are peers and take an equal share of the work.

> What I'm talking about is extending QuakeWorld in an optional manner than allow clients and servers the greatest level of access to a shared set of resources. One where an FTE client can play along side a vanillia client and still not have one call cheating from the other.

Personally I've always been quite slow on the uptake of features that could be considered cheats, to the extent that realtime lighting required cheats to be enabled on the server.
Stuff like that means that cool stuff never gets used.
More recently however, I've stopped caring so much. If its available as a cvar then its available as a cvar and mods can spam requests to set them to a specific value (preferably via csqc, but whatever). If worst comes to the worst, the cvar controlling the feature can just be added to some ruleset and disable it.
My greatest cheat concern right now is in the form of modified data files, models, sounds, etc. If they're forced to only a specific model, then there's no customisation possible, no remodelling project, etc.

> LIT downloads - Sure BSP30 had them builtin but LIT has the marketplace. We need LIT support but with server downloading and checking to ensure people aren't running with a fullbright LIT file.

A few people want to move LITs into the bsp itself. Both tonik and mh have been investigating the possibilities here recently, or there's the older hack of embedding an entire pak within the bsp.
I'm more in favour of shoving the bsps into pak/pk3 files and just downloading the whole thing - this has the benefit of 'free' compression, meaning slightly faster downloads, but data has to be packaged properly for that to work, and servers need to support pk3s too.

> Master server support - Yeah bog standard QW has this but we end up with issues, like a lack of server browsing from within the QW client. Let's extend and standardise this. Discard requests we don't support and serve those which we do. Personally I'd like to see the Master servers support Trophies ala PS3 and XBOX360.

trophies and things require logins and things. Its a pain. Someone needs to fund maintainance of the master, etc.
Darkplaces has some sort of crypto signing thing going on, so that clients can be 'uniquely' identified. Not sure on the details.
Modern QuakeWorld clients do contain server browsers already, and they do automatically populate using a few separate master servers.

> Faster downloads - The existing download is pitifully slow. Curl is an option but it's not quite right... we've gotta be able to improve on this.

FTE, fodquake, ezquake and mvdsv all support 'chunked' downloads, which are generally meant to have a faster download rate (in liu of bugs or annoying minor incompatibilities). The original quakeworld download protocol is so pitiful because it uses the reliable channel for everything, waiting for the client to acknowlege each part before the next is sent. Chunked downloads are meant to have the client tell the server which parts it doesn't have yet, so the server can send unreliably and in every packet, although this may still not reach link saturation, depending on framerate.
I do want to revisit download acceleration some time, but mneh, the current version should be reasonable, and at least its fairly widely supported.

> These are my 3 big bugbears that can be improved without killing existing QW clients. I'm open to suggestions that can improve things for all, provided they don't break the existing protocol.

Modern quakeworld engines support two separate 'families' of extensions simultaneously.
zquake extensions, which are provided through unused bits of the network protocol and advertised via serverinfo/userinfo, created by tonik, these features typically work through qizmo. They're generally small things that don't need much extra data. Most of them focus on functionality to bring QuakeWorld up to the level of NetQuake (like more movetypes than just MOVETYPE_WALK), but there's also a few extra flags like understanding switching between spectator/player without reconnecting.
FTE extensions, which are negotiated before connection, and are ignored if unrecognised. The FTE ones are typically a bitmask of protocol features that state what the client supports. Other engines are free to add their own identifiers, like I think DP has done. Features which the other engine doesn't support are known before connection is established, with proxies unaware of the negotiation data, the client is still able to connect via qizmo, with both engines using the legacy protocol, which the proxy is able to support.
If you connect with a legacy client that is unaware of either of these extension families, nothing will be printed, you'll just not benefit from them. You'll probably not even notice, you'll just get slow downloads and stuff. :)

[Baker]

[JasonX]

[r00k]