Is it doable - coop without force changing every player's map on exit

[LedZep]

I don't know if this has been discussed before, but would it ever be possible to make a more seamless coop in Quake 2 (or any other Quake engine game for that matter)? The issue arises when someone sets off a level change trigger and everybody gets sucked in to the next map. Not only is this annoying for people who aren't with the triggering person, but it can also be exploited easily by griefers through changing the map back and forth. There needs to be a way to make people find their own way across the campaign.

So how could one do this in a Quake game? I have an idea that's just about crazy enough to work. First off, here are the problems that Quake has with this:

- A dedicated (or listen server) in the vanilla Quakes can only run on one map at a time
- Multiple maps placed beside each other real-time would look weird from the outside because two BSP files are geometrically incompatible (the VIS data doesn't extend outward, etc). This means that when you look out from map A to map B, map B could appear glitchy as fuck since map B did not account for the geometry of map A at the time when it was compiled. It could also cause invisible walls and require hot-patching where the maps should join. Might as well just raise the caps and make one giant level at that point
- Loading two maps at once in real-time gets further complicated because clients keep their own version of the BSP in their memory. You would have to mod both the server and client code to make this work.

Despite these issues, I came up with a way a while ago that could potentially be realized through modifying the SERVER CODE ONLY (I am using Quake 2 as an example).

The trick is to mod a Quake 2 dedicated server in such a way that when running the program, you would actually be running multiple servers inside the one. It would have multiple maps loaded at once, multiple ent tables (for their respective maps), etc. HOWEVER, the client table is SHARED between all the maps.

Server map loading: At the start, when the initial map is loaded on one 'nested' server, the server would check through all the entities for map change triggers and spawn more nested servers if it hasn't already for the maps found. Once that next map is loaded, simply rinse and repeat. Continue doing this until there are no known new maps.

On map change: The client that sets off the trigger to change maps would get a "server level change" packet. THE REAL BEAUTY OF IT: the other clients don't get the packet and continue to play on their map unaffected. The server would then take note of the player that did go through the map change and send them information from the other nested server from then on. Clients who are on different maps would receive no updates of each other from the server. To prevent frozen ghosts at map exits, the server could spoof their location to someplace unreachable right before they get kicked to the next map.

Lag reduction: Piss simple - the maps (nested servers) that don't have any players inside them don't get updated.

To put it simply: Given a set of maps in a campaign (A.bsp, B.bsp, C.bsp), instead of running the program that IS the dedicated server on map A, you would run a program that would contain three dedicated servers running on all the three maps at once. The three servers would be completely separate except for the client table, which would be a table of all the clients on all the maps at once. The program would 'candy-wrap' the three servers' network code and selectively send information to clients of either server A, B or C, depending on which one the client is currently in (only the server has to keep track of that). If a client changes the map, they would get the server map change as normal. Little do they know, however, that when they load the map, the server is now treating them differently from all the other clients that were left behind on the old map.

Also, for the master server, you could just send them information of the server with the first map. Since the client table is one, it would show all the players, just that the map would stay frozen as the first one. This doesn't really matter, though, since there is no real way to show a quake browser that the server is actually made up of more smaller servers. The fact that it would show the first map in the info would mean that anybody joining the game would have to start at the beginning. You can fix this by making the player connect to the first map, and only once they are in, you would move them to a later point if they are too far behind from everyone else.


So... would this work by modifying the server only? Or would I run into some horrible problem if I ever attempted this?

[QwazyWabbit]

There's always the problem of preserving player state across the servers.

The name of Co-op means what it says: Cooperation. When someone jumps the map prematurely he's not being cooperative. He should pay a price and that price should be suspension between maps until the other players follow, the server shouldn't just pop maps at the crossing of the exit, but that 's just my opinion and it would take a code change.

As for spoilers, re-crossing the map exits multiple times should earn them a 24 hour kick-ban. This would probably be relatively easy to do in the TS realm with Wallfly but would take a server code change elsewhere.

Multiple servers are problematic. There are 64 maps in the base collection of the original Q2 game. It would take 64 server threads or processes to contain them all. You might be able to limit the server chain horizon to 3 or 4 maps, with the idea that only 3 servers would run or only the number of servers would exist to support the number of occupied maps but then the problem would be managing the idiots who would race ahead opening new maps just for the hell of it.

At Clan WOS, we developed off-world teleport entities and support code that allows for the creation of teleport pads that would connect a player who entered the teleport to be connected to a new server. This is a self-contained set of source files and a fairly simple mod to the game DLL. http://www.clanwos.org/forums/viewtopic.php?f=1&t=3198&start=15. The original concept allowed for launching into a completely different game client but I never implemented that capability because I wasn't sure how to quit Q2 and launch the new client simultaneously without complications. The beauty of the off-world technique discussed there was that it doesn't require any cooperation from the target servers and the entities can be added to maps using the r1q2 override capability without changing the map files.

The remaining problem of the multiple-server or teleport-to-server solution is carryover of player state, something already built into coop Q2.