First, I want to invite mh to particpate in engine development of https://www.moddb.com/mods/zircon-engine

I don't expect you to take up this permanently valid offer, but if the itch ever comes this door is always open.

Second, I want to thank Spoike for perpetually doing fun stuff in FTE. I acquired your chunked downloads into Zircon and because it is DarkPlaces it actually involved some gymnastics.

Extra thanks:

1. metlslime for hosting this site and also helping me learn engine development.

2. Sleepwalker for TrenchBroom.

3. Sock for terraforming the asshats in the mapping community into asshats in the mapping community that accept open source as a standard practice. Open source is just the "right thing to do".

3. dumptruck_ds ... whom I urge to "see the light" sooner rather than later. Spike and to some degree LadyHavoc wanted me to see the light, I resisted for too long. Now I see the light and wish I did years ago.

Did I use #3 twice? No I didn't, and fuck you for rudely pointing that out. How dare you, sir!

Also Merry Christmas.

This beer means I press submit. 

If we're doing a DarkPlaces fork, can we call it "BrownPlaces"?

Firstly, "Brown" is well in keeping with the Quake aesthetic.

Secondly, an engine name that makes people go "eeewwwww" tickles my sense of humour. 

I still like AMFQuake - Add More Frogs.


Anyway, all download protocols suck...
In order of FTE implementation...

QuakeWorld: sends packets synchronously, so gets slower and slower the more latency you have. 30kB/s? must be fairly local. 300ms of latency will leave you at around 5kB/s ish.

Original Chunked Downloads: Fixed quakeworld's sync issue and significantly sped up downloads between continents... but is slower on loopback/lan due to fixed-size chunks and not (capping to just 73kB/s vs 104kB/s according to my maffs... but without dropping to 5kB/s just cos the server's on the other side of the world)

DP's downloads: Async, but if there's any packetloss then it rewinds to the lost position and resends everything wasting a whole load of bandwidth (especially if your rate is set too high). Easy to implement though - hence why this is the one I added to QSS.

Out-Of-Band-Chunks: requesting multiple chunks per clc and sending any extras out of band allows it to achieve MB/s if your rate settings are high enough [or uncapped], but still doesn't make the best utilisation of bandwidth due to fixed-size chunks.
(It was actually mvdsv/ezquake that first did the out-of-band thing, but ezquake has no congestion logic and makes a fixed number of requests that kills slow connections and under-utilises fast ones, and mvdsv's rate throttling is flawed using some chunks-per-frame cvar rather than byte-rates).
`setinfo drate 0; sv_maxdrate 0` should uncap download rates with fte servers. `rate 0; sv_maxrate 0` will uncap non-download rates too, just in case I did the fallbacks badly. The client will adjust the number of chunks requested according to the number that never arrive (eg loss or serverside rate limits).

If you want to improve it more then...
a) switch from chunks to bytes. You'll get less header overheads when you're filling entire ethernet frames instead of capping to 1k. You'll also be able to control granularity a little better, as well as cope with ipv4's lower MTU guarentee.
b) move the rate determination to the server instead of the client, with the client sending acks(and inferring nacks) instead of requesting every single chunk. This would reduce the c2s traffic, but seeing as you're already spamming c2s unreliables anyway its probably not going to be that significant.
c) move the server's transmission into a different thread somehow so they can be transmitted over time, instead of bursting all at once and getting dropped by routers that are panicing about buffer-bloat, so other packets don't gain extra latency. you're unlikely to see much higher than 2MB/s otherwise.
d) oh look, you just reinvented tcp. Oh well, might as well just switch to http downloads instead to keep things far far simpler when its basically just the system's tcp implementation doing all the work... oh noes that's going to need different sockets and some way to match up port forwarding... The other option is (udp-based) http3, which would be interesting. libcurl should be able to do the clientside part just fine, but while there's libraries for the server part multiplexing with other protocols and dealing with whatever file access sandboxing/generation they use might get messy.
Side note: DP using sctp instead of its current netchan would be an improvement... apart from the extra port headers etc that are redundant cos of it being over udp. But hey, ignore the redundant stuff and you've an RFC to read to understand what's going on. Actual documentation! Who'd have thought it!
Other Side note: the Quake2 remaster has its own reliables mechanism... layered under the regularish q2 netchan... *sigh* yay for extra sequence number overheads.

But yeah, compat with existing (qw) engines is nice.
Also, you probably don't want to be congesting game servers with download data and harming other people's connections, so its probably best not to aim for balls-to-the-wall speeds anyway - DP DOES already support tcp downloads its just clumsily implemented and only for pk3s iirc (a feature denied by dp's udp downloads) but pk3s at least means you get the lits/shaders/textures etc too all important considerations if you've got q3bsp maps... and then there's the whole versioning nightmare thing.
Speed is not the only consideration here.

But yeah, chunked downloads does its job well enough, I'm just saying that there's scope to go noticeably faster if you fix issue c above, and without breaking compat.
Stoopid walls of text. :/ 

We made it through another year. Hope all of you are someplace safe, and having a good time with good people. 

 

 

Glad we're still here 

 

 

 

https://www.youtube.com/watch?v=vzSdfit4P3M 

what NIN riff is this? https://www.youtube.com/watch?v=wZfTt9IRNZE#t=2m28