Quote from: CLAW on October 31, 2016, 02:37:25 PM
couldn't this be archieved by save game?
We should direct our developer's attention (if we have any) on things that would largely impact our quality of life while being not so hard to implement (hardware ban hi)
Well, some kind of autosave could be a key. Also, autosavr could be a separate project not related to others (like hardware ban), so it can be implemented by somebody who wants (and can) to help.
Another question is if that is really useful: even if we have saved game, we have to join all the previous players together again. Not so easy task to make them do that.
Quote from: Lambchops on November 01, 2016, 06:26:52 AM
Then you would modify saved game state to show that the disconnected player is still in the game, then restart the game from the modded save. If you could automate the process it would in effect allow players to join a game in progress, but it could make the game suceptable to all sorts of exploits.
I'd say just to make saves periodically, considering disconnects. To let hoster know which save-file should be reopened. Game load could be a manual process.
To be honest, I've never used the save game feature for a multiplayer game, but modding/automating features that already exist in the game is much easier that trying to introduce entirely new ones.
I've always assumed the save game feature makes a file based on the existing game state with info about the players and the current state/actions of each unit - then you just start a new game based on a combination of that file and the original PUD.
Just did a few tests on my own and it seems pretty good at restoring the game state. i.e. spell effects/corpses/current actions etc. were all resumed.
With several players in the game i assume it only lets the same players join the restored game? I know the dialog says that only the host can save the game so I assume it is only saved to their computer, so when it is restarted the save game file has to be downloaded by the rest of the clients?
I don't imagine autosaving would be terribly difficult. Certainly it would be trivial with a macro, but that would be intrusive to an active player. Periodically calling the save game proc with an auto-generated file name (autosaveXXX.mlt) shouldn't be too hard though.
*In theory* allowing a player to join a game in progress could be achieved by something like this:
Trigger the clients with a pre-defined in game messages... with some sort checksum based on the stuff about the current game.
So the player wanting to join messages a player in the game /m player #join
The clients have a bit of code injected into them so if they detect incoming messages with a '#' prefix so if they get a "#join" message incoming they generate an in-game message that all clients see like "#request:JoiningPlayer:945B98D1"
The #request message triggers the host to message the joining player details game datails like "#invite:184.108.40.206:6112:945B98D1"
The joining client then replys with "#confirm:join:945B98D1"
When the host gets time they generate an in-game message like "#restart:220.127.116.11:6112:945B98D1"
The rest of the in-game clients reply with "#confirm:restart:945B98D1"
When all clients have confirmed, the host save the game then sends "#execute:945B98D1" both to the joining player and in game.
All clients then leave the game.
The host client mods the save game file to include the new player, and creates a new game from the save, while the non-host clients join the created game, along with the joining player.
The host would wait for all players to join the new game then start it and the game would continue.
Ideally the new game would be created and players would join without using the server game list mechanism, the server would only be used to relay message to/from the joining player.
This is, however, a lot of work for what is debatably little benefit.
What is the use of it? For a player to rejoin if they lag out? If they are lagging they will probably still lag when they rejoin, and if everyone agrees this can already happen with the existing game save if they do it before the player actually drops.
If the joining player wasn't already in the game what do they start with and where? 1 peon at an unused starting location? What if an enemy already has an exp there? How are they going to catch up anyway? Really, what's the point?
I suppose it might be nice for people to be able to join as watchers, but is that really worth it? What if a lagging watcher joins a game? What if people keep joining and leaving causing annoying pauses in the game?
The .MLT files are much bigger than .PUD files, and the game's download procedure is VERY slow... The biggest .PUD files are around 120KB. Using normal network protocols, this should take less than 1 second to download even on a slow connection, but as we all know whatever method the game client uses is MUCH slower than this. My test .MLT file it 530KB so it would seem using only existing features a game restart is going to take maybe 2-5 minutes (yuk).
The other thing about this mechanism is is that there is a massive security issue, in that while the game is being restarted, a single client has the one official version of the game state, so at that moment they can play God and change anything at all in the game.
This potential exploit, however has some interesting possibilities for creating RPG style campaigns and the like... i.e. when set of triggers in the game is satisfied, the game can be automatically restarted with any changes the designer wanted... introducing new cpu enemies, allowing certian units/abilities that were previously restricted. It's a nice concept, but for the probably thousands of hours it would take to impliment, at that point you may as well go play wc3.
For my money, there is one WC2 mod that is head and shoulders above everything else absolutely screaming out to be implimented. (see next post