mULTIPLE server connections

[r00k]

How hard would it be to be on two servers at the same time?

I mean if one server held the contents of a single map and then there was a transition point...to another map on the other server.
Kinda past the handshake socket assignment.
You would have to initialize both connections at the same time.
server to server private port,

[Baker]

Two of everything ... yikes ...

2 maps, 2 network connections, 2 client intentions, 2 scoreboard trackings, 2 client world type of interactions, 2 list of preached ents, redesign the clear models and memory stuff to check 2 places ... prepare to receive a "reconnect" map change message at stupid times potentially, 2 copies of client times, something to tell client where console input and commands are going ... how are you going to keep server aliases straightened out like what if the 2 servers are running different mods????? Maybe +hook is one impulse on server X and another on server Y.

Oh ... and hope the other server connection doesn't time out while textures are loading. So keep alive ... keep alive ... maybe (?).

/I am not Spike but still a quick mental exercise of this hurts ... the idea is cool. I've thought of the idea of ONE server having multiple maps running, but wow the reverse is far worse it appears ...

[ceriux]

a half-life mod called msc started with this idea for map travel since it's an rpg mod, in the end it didn't work out so well..

[Spike]

depends what you're actually trying to achieve with it.
at the most basic, its 'merely' a case of changing the 'cl' structure into an array instead, fixing the renderer/mixer to not flush too much, and moving all the various cl_entities etc arrays into the cl structure/array.
the more globals you have, the more effort it will take.

of course, you have additional issues like svc(nq)_serverinfo clearing the hunk destroying the hunk of the other connections.

for splitscreen, fte uses a single connection. the server merges the pvs of each player on that connection so ents are properly visible for every player. stats, angle changes, centerprints all have some svc_selectsplit or something before them to ensure they update the correct player. but as there's only a single connection, there's only one set of precaches, only one serverinfo, only one set of baselines and only one hunk - only the obvious parts need to be changed.
note that this breaks viewmodelforclient.
nq would be slightly easier to implement this as it doesn't have lots of prediction code. frankly, input is the hardest area. You'd have to use something like rawinput to get specific identifiers for each device for separate players.

So yeah, avoid globals, because it makes stuff like this hard.