Midgame reconnection system improvements

[bibim]

The new midgame reconnection system could be very interesting if hosts had better control over it. In particular, I think the following two new features would improve things a lot:

1) taking back your unit when reconnecting:
When an ID is uncontrolled (the player who should be controlling this ID never connected, or disconnected, or resigned), other players of the same team should be able to take and control his units, as it works currently. However it would be nice if the engine could remember the original owner of these units (as in lineage mode BA modoption). That way, if the initial player reconnects then he is given back all his units (and the units built by his factories when he was offline etc.) once he has finished loading.
This can be a little tricky, for example if player A takes player B units, then disconnects, then player C takes his units (A+B), and then player A reconnects: should he take back all the units he had before disconnecting (A+B), or only his original units (A)?

2) ability to replace players:
It would be very usefull too if hosts were able to replace players through a new "replacePlayer" command on AutoHost interface. This command coud be used by AutoHosts/RelayHosts/LobbyClients to replace a player who was initially present in the startscript but who has disconnected or resigned.

The command syntax would be "/replacePlayer <oldPlayerName> <newPlayerName>" where:
<oldPlayerName> is the name of a player who still has units in game (taken by another player or not), but who has resigned or disconnected (or never connected)
<newPlayerName> is the name of a player who either:
- is in the game currently but is spectating
- isn't in the game currently but has been added through the existing "/adduser" command

If newPlayer is a spectator, then he takes the place of the oldPlayer instantly when the /replacePlayer command is executed, taking back oldPlayer units if they had been taken by an ally.
If newPlayer isn't in the game yet, then he will take the place of the oldPlayer once he has finished loading the game until current position (seeing only his team units, as if he was the oldplayer reconnecting).


If this is implemented, such things could happen:
- player A timeouts
- player B takes player A units and controls them while player A is offline
- player A reconnects, reloads the game until current state and takes back his units automatically
- player B disconnects because he can't play anymore
- player A takes player B units and controls them
- player C joins battle lobby and sees through !status output that player B disconnected
- player C calls a vote to replace player B
- player C joins the game in progress and replaces player B, taking back original player B units

[BrainDamage]

there's a bit confusion in your post: units are tied to teams, not players, and then teams are controlled by players

1) taking back your unit when reconnecting:
When an ID is uncontrolled (the player who should be controlling this ID never connected, or disconnected, or resigned), other players of the same team should be able to take and control his units, as it works currently. However it would be nice if the engine could remember the original owner of these units (as in lineage mode BA modoption). That way, if the initial player reconnects then he is given back all his units (and the units built by his factories when he was offline etc.) once he has finished loading.

problem here is that the same moment that a team has 0 units for all but 1 ( never used because it never makes gameover )
game end modes the team dies, so even if you'd give it back the units, it'd still be dead, it first would need an option to let teams alive even with 0 units as long as the allyteam is alive ( I was planning to move game end condition to a lua and implement this, but not sure when )

2) ability to replace players:
It would be very usefull too if hosts were able to replace players through a new "replacePlayer" command on AutoHost interface. This command coud be used by AutoHosts/RelayHosts/LobbyClients to replace a player who was initially present in the startscript but who has disconnected or resigned.

you don't "replace" a player at all, instead what you should ask is being able to make a midgame join not spectator and be able to assign him to an alive ( see previous remark ) team, while code-wide it would be easy to add, i'm not sure if it should be the host or a lua hook for the mod to assign players to teams ( or both? )

[hoijui]

i'm not sure if it should be the host or a lua hook for the mod to assign players to teams ( or both? )

as there is /cheat /team X already, this would not be a problem.

[bibim]

1) taking back your unit when reconnecting

problem here is that the same moment that a team has 0 units for all but 1 ( never used because it never makes gameover ) game end modes the team dies, so even if you'd give it back the units, it'd still be dead, it first would need an option to let teams alive even with 0 units as long as the allyteam is alive ( I was planning to move game end condition to a lua and implement this, but not sure when )

Ok then it would require keeping a team alive with 0 unit first.

2) ability to replace players:

you don't "replace" a player at all, instead what you should ask is being able to make a midgame join not spectator and be able to assign him to an alive ( see previous remark ) team

Hum, I know internally units belong to teams which then belong to ally teams. But why exactly it wouldn't be possible to replace a player, as in renaming him dynamically and changing his script password? This way it would be exactly as if it was him reconnecting, and the original player wouldn't be able to reconnect once replaced.

[BrainDamage]

i'm not sure if it should be the host or a lua hook for the mod to assign players to teams ( or both? )

as there is /cheat /team X already, this would not be a problem.

I'm wondering which should take priority, and what would be the more proper solution

Hum, I know internally units belong to teams which then belong to ally teams. But why exactly it wouldn't be possible to replace a player, as in renaming him dynamically and changing his script password? This way it would be exactly as if it was him reconnecting, and the original player wouldn't be able to reconnect once replaced.

but why doing such weird hack, when code-wise you can assign any player to control a team with much less efforts? ( or remove them )
not to mention, with the proper way, the team infos function would then show the correct player name

[zerver]

Important is that the player who is going to get his units back never dies so that he can see what the enemy is up to. One possibility would to be to create some special unit during /take if the player is currently reconnecting, to allow him to survive. A big risk for bugs here.

[bibim]

Hum, I know internally units belong to teams which then belong to ally teams. But why exactly it wouldn't be possible to replace a player, as in renaming him dynamically and changing his script password? This way it would be exactly as if it was him reconnecting, and the original player wouldn't be able to reconnect once replaced.

but why doing such weird hack, when code-wise you can assign any player to control a team with much less efforts? ( or remove them )
not to mention, with the proper way, the team infos function would then show the correct player name

Actually I didn't think it was that hacky, and I though it was easier to just rename the player (in a way that team infos function would return the correct player name) and use the currently existing rejoin system than implementing a specific "midgame join not-spectator" and assigning the new player to a team. Also, it would prevent the original player to reconnect as player once he has been replaced. But you already worked on this code whereas I didn't even take a look at it so I guess I'm wrong... Anyway, whatever technical solution is chosen, what is important is just to be able as host/autohost to allow a player to join or unspec midgame and control the units of a team (taking back the units if they have been taken by another team, or sharing them with other players of the team if there were already players in the team...).

So with your technical solution I guess the functionnality could be implemented by a command like this instead ?
"/assignuser <userName> <teamId>" where:
<userName> is either a currently connected player/spectator, either a user added previously with /adduser but not connected yet
<teamId> is the team number which the player must join, or "spec" to make him spec (to cancel a previous /assignuser call for example...)

The problem then would be if a user manages to connect between a /adduser and a /assignuser call: he would join as spec and would see all the battle before being assigned to a team... So maybe add a <teamId> optional parameter at the end of /adduser command, to allow both adding a user and assigning him to a team at the same time?

[BrainDamage]

Important is that the player who is going to get his units back never dies so that he can see what the enemy is up to. One possibility would to be to create some special unit during /take if the player is currently reconnecting, to allow him to survive. A big risk for bugs here.

I'd rather move game end condition to lua and enforce engine side to use infinite game end ( and remove the other modes ported to lua ), then letting a team survive with 0 units can be easily done

The problem then would be if a user manages to connect between a /adduser and a /assignuser call: he would join as spec and would see all the battle before being assigned to a team... So maybe add a <teamId> optional parameter at the end of /adduser command, to allow both adding a user and assigning him to a team at the same time?

This is what I had in mind, there should be a flag for spectator status too

[Google_Frog]

Important is that the player who is going to get his units back never dies so that he can see what the enemy is up to. One possibility would to be to create some special unit during /take if the player is currently reconnecting, to allow him to survive. A big risk for bugs here.

I'd rather move game end condition to lua and enforce engine side to use infinite game end ( and remove the other modes ported to lua ), then letting a team survive with 0 units can be easily done

+1

Then a player joining the game could be assigned to an allyteam which would provide normal allyteam features such as shared vision and allychat. From here the player could join a team on that allyteam and units can be transfered to the team via lua.

Specific taking and transferring behaviour is not required in the engine.
Gadget developers just need players to be able to exist on an empty team and rejoin to an allyteam.

[knorke]

it might be good if the lobbys gives a message if reconnecting even makes sense. for example i crashed because of "blabla update your drivers", clicked reconnect and waited through the fastforward syncing.
Then it just crashed again

and it should be possible to chat with the players still ingame while fast forwarding so everybody knows whats going on.

and maybe make it not draw graphics during fastforward, like the /skip command.

If this is implemented, such things could happen:

what if C was previously in the game as a spec? Then he leaves the game only to rejoin as a player but has already seen the whole map. I think only original players should be allowed to reconnect.

[SpliFF]

what if C was previously in the game as a spec? Then he leaves the game only to rejoin as a player but has already seen the whole map. I think only original players should be allowed to reconnect.

Or add a allySpec mode where a spectator can only see a given allyTeam. Then only allow allySpecs to take over a team member. Disallow any player who has "full specced" at any point in the current game (wether they disconnected at any stage or not) from taking over a player.

[Licho]

Just give control to lua, CA already had "teamspec" feature 2 years ago using hackish lua.
It also had "backup" - player with no units who can only see his alliance and can be given units if someone crashes.

[CarRepairer]

Yeah it was in CA for years and guess how many spectators chose to use it? Virtually zero.