by Spike » Thu May 19, 2016 6:34 am
if you want the entire quake world loaded on a single seamless server, you're going to NEED some sort of instancing, if only because of QC's float precision and quake's player limits.
fte does actually already have an instancing mechanism, accessed by the 'mapcluster' command. if you use that console command, the server enters a gateway mode. Connecting players are redirected to a subprocess that it starts up as needed. these subprocesses can redirect clients to other subprocesses, which will presumably be running different maps, or they can send each other messages (via the main gateway process).
multiple processes allows you to limit the number of players in any one place without violating the quake protocol too much, however, it still needs some protocol changes, mostly so that the client can more reliably be handed over from one server/instance to another. it also avoids needing to rewrite EVERYTHING to make it thread safe, etc.
ideally you'd extend it to connect additional control nodes together, one per physical host, so that you can spread the instances across multiple machines instead of putting the entire load on a single machine, but I personally never got that far. and so far I've only written any code for it to run in windows, because I'm silly like that.
combine this with worker threads loading the content for the next map in the background, and you should have shorter load times (although tbh if you're not using replacement textures then this is hardly a real concern nowadays).
there's no reason you can't have one subserver running coop and another running deathmatch, of course. however, if you do want coop, one issue is with runes - you'd need to redo the startmap somewhat significantly if you want to be able to visit every map properly.
and yeah, then you start to need to add friends lists (and thus probably logins), and ways to teleport to people, and ways to block trolls.
anyway, I did write the basics for this sort of thing, I just never polished it. here be dragons.
.