Arcane Dimensions (quakespasm 0.91.0)
connect play.quaddicted.com:26000

Rubicon Rumble Pack (quakespasm 0.91.0)
connect play.quaddicted.com:26001

The Elder Reality by PuLSaR (quakespasm 0.91.0)
connect play.quaddicted.com:26002

Root Of All Evil by DeeDoubleU (quakespasm 0.91.0)
connect play.quaddicted.com:26003

There are not yet many maps available. I'm working on getting darkplaces clients to connect. fteqw seems to work fine in general but has some awful connection stutter when running AD. 

To see RRP on there - I'll add proper COOP support as part of the patch. 

regarding AD+FTE, either massively increase your rate (sv_maxrate) far beyond default settings (its all those particles), or set temp1 0 to disable said particles.
(sadly changing rate settings can be a bit annoying, especially for nq clients that have no concept of rate limiting necessitating hitting a bind on each map change - 'cmd rate 50000' should do it, combined with sv_maxrate 50000 in the server's settings)

rather than 100 different servers, I'd suggest running just a few with some sort of dynamic gamedir changing addon hack enabled.
doing so should help encourage potential players to actually play with each other (longer term) instead of it basically ending up as single player.
plus, having a choice of 20 can be a bit of a turnoff compared to a choice of 3.
however, setting up such a thing would also take a bit of time to do properly, and be engine-specific, so meh. 

I'm working on getting darkplaces clients to connect.

DarkPlaces doesn't do FitzQuake protocol 666.
DarkPlaces probably doesn't support FTEQW's enhancements to QW
QW doesn't do Quake progs.dat except FTEQW
FTEQW supports most of DarkPlaces protocol 7.
Quakespasm doesn't communicate the running gamedir to clients.

Perhaps using DarkPlaces as server using DPP7 would allow both DarkPlaces and FTEQW to play.

In theory ... 

This is a very important initiative. Makes mappers design for coop and it's new gas for us.

Gives new gas to Quaddicted and its map archive as well, I think. Can work as a live "quake injector" if engines download the levels (assuming you have the mod on your system). 

I do understand what spike meant and I already have a system in place that lets clients change the map.

Changing the mod on user-request should'nt be a problem either. The "game" console command should do it although I'm not sure if it does everything correctly. Even so, I could just restart the server instances with different args.

There won't be many servers when I'm done. Maybe some for sourceports that are not compatible. Maybe some with QW physics.

I just posted the current state in case someone wants to play already.

If I find a reliable way keep track of which clients are connected I could easily implement a small engine independent voting mechanism.

I will integrate some more maps and keep testing different ports in the next days. 

Tried to connect with Darkplaces, there is a console dump probably an illegable server messsage of sorts.

But its a good idea, and I am pretty sure some engines support multiple progg.dat , so it ought to be possible to have 1 server do all those mods I believe...depending on the engine, which I guess is Fitzquake. If that were so, you could create one single start map sort of like the Runequake coop servers have, with screenshots of all the mods. 

Quakespasm uses FitzQuake protocol 666 as the client. DarkPlaces doesn't support FitzQuake protocol 666. A DarkPlaces client won't be able to connect to Quakespasm server.

Vote-map: There is a QuakeC tutorial on how to add that capability to a mod link. This means modifying Arcane Dimension's QuakeC and recompiling the progs.dat. 

Hehe, I like the protocol number, very Quake for sure.. 

http://www.celephais.net/board/view_thread.php?id=61077&start=406

I added 3 coop starts to the initial start position. Although they're untested it should still help to avoid so much telefragging on level load.

This is a quick and dirty change, the map wasn't really built with coop in mind and in many cases locks the player into or out of areas. 

Another thing I found can be done with some qc work is put a timer on each spawn entity, say time + 2, and basically make that spawn spot invalid for that period, and either loop the potential new player by making them wait that much time, or what also will work is merely walk down the entity list on the server and pick an ent randomly which has a FL_ITEM flag in it. The majority of the time items are placed in safe player sized locations , so it ought to be ok. If you want it as close as possible to the coop spawn, you can do a distance check I suppose. Also if there is an "info_player_start" that can be used as a backup too. Seems lots of map makers leave those in there after the map is released. Consider it a "plan B" of sorts...of course the best way is to code in more spawns. 

that coop should always be planned for. Even if I have a spot that traps a singleplayer, I typically include a way for coop players to get in with the first player who gets trapped, either with a teleport that opens up or a height push.

I love the idea of coop servers! Would be a great way to test my coop heavy mod features such as the balance of monster_<name_here>_coop and item_<name_here>_coop for items and monsters that only show up in coop. I try to make sure that each map I make is well balanced for both singleplayer and coop.

I once made a coop only map that traps players until their friends can release them. :) 

With a bit more foresight I'd have put in shortcuts to everywhere from everywhere and had them dynamically update as the leading player progresses.

But this would have been very difficult to do since the critical path loops over and around itself and is modified by the progression itself.

A better option would be to fix coop mode itself - allowing the mapper to populate the map with respawn points, the closest of which to the living player(s) gets used when respawning a dead one, rather than just using the coop start. 

I had a chute in Terracity which the teleport location was in and diverted paths to different teleport destinations as the map progressed. I can't recall if I did the same for coop spawns individually but I believe I did specifically so coop players could get right back in the action quicker from the starting room. 

That being mentioned at the time - was a cool solution.

In warp I did it by just adding lots of teleports all over the place - the idea was to make the explored space easier to navigate the longer you played.

Didn't do a particularly great job of it, I'm sure it can be improved as a methodology. 

I could have used info_notnulls with a use of InitTrigger and a touch of teleport_touch and killtargetted each teleport with a relay and then used another relay to target the next notnull. Would have prevented a bug where the player occassiomally got stuck in my chute and also would have eliminated the increasingly longer teleport times required by longer and longer falls.

Make more coop maps. Keep the ball rolling!