War2.ru Slogan
News: If your graphics are broken you can fix with the new ddraw version.
** Read how to install it here **


Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Welcome to the forums! We're glad to have you here! :) You can register your account here, then feel free to introduce yourself in the Server.War2.ru board & let us know who you are on the server.

Server Update (reconnect to games when disced) 1404  37

Grunt Posts: 141 Karma: +3/-2 Hullo ***

MaStA{hR}

  • Grunt
  • ***
  • *
  • Posts: 141
  • Hullo
    • View Profile
Server Update (reconnect to games when disced)
« on: October 31, 2016, 01:58:26 PM »
Would it be possible to include this or would the coding not work for this game:

To reconnect to a game if you were disconnected?
Ogre Mage Posts: 1959 Karma: +109/-172 ********

CLAW the racist

  • Ogre Mage
  • ********
  • *
  • Posts: 1959
    • View Profile
Re: Server Update
« Reply #1 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)
Axe Thrower Posts: 303 Karma: +20/-0 ****

Lambchops

  • Axe Thrower
  • ****
  • *
  • Posts: 303
    • View Profile
Re: Server Update
« Reply #2 on: November 01, 2016, 06:09:42 AM »
To reconnect to a game if you were disconnected?

This is a 100% client issue and not to do with the server. In fact THIS ALREADY HAPPENS.

This is what is happening when someone lags and nearly drops, but then their connection recovers. While everyone is looking at the lag screen, they are disconnected. Then they rejoin the game.

You really want laggers to be able to rj when they finally drop?

The issue is (again) that a wc2 game is not happening on a server, it's peer-to-peer. There is no 'official' version of the game state, instead all clients must agree to what is happening in the game for it to continue, if one client is out of sync they will drop.

To join a game in progress a client would have to negotiate with all the active clients in the game and come up with an agreed version of the game state, then they would all have to accept the joining client. At that point all sorts of exploits could come up, like people drop-hacking one player to replace them with somebody else who is spoofing them etc.

In the end, if the rest of the clients have decided to boot you, its for a reason - in most cases its either because your connection is too poor to allow the game to continue with you in it, or because your version of the game state is different to everyone else's.

Axe Thrower Posts: 303 Karma: +20/-0 ****

Lambchops

  • Axe Thrower
  • ****
  • *
  • Posts: 303
    • View Profile
Re: Server Update
« Reply #3 on: November 01, 2016, 06:26:52 AM »
couldn't this be archieved by save game?

If someone wanted to do it, then yes, the save game mechanism is exactly what is needed. In effect you would be ending the game and saving it - which is then the 'official' version of the game state. 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.
Ogre Mage Posts: 2276 Karma: +41/-7 ********

tk[as]

  • Ogre Mage
  • ********
  • *
  • Posts: 2276
    • View Profile
Re: Server Update
« Reply #4 on: November 01, 2016, 09:39:45 AM »
I'm not sure if it works on all routers, it's probably isp related. . But when I lived in an apartment I used to get disconnected, drop screen would pop up.. then go for like 10 seconds, then disappear,  then pop back up for another 10 seconds until I eventually dropped.. I figured out I was able to tab out of war2, disconnect from my Internet connection, then auto reconnect and tab back into the game and keep playing without dropping
Ogre Mage Posts: 2319 Karma: +73/-1 ********

tupac

  • Ogre Mage
  • ********
  • *
  • Posts: 2319
    • View Profile
Re: Server Update
« Reply #5 on: November 01, 2016, 11:26:41 AM »
I'm not sure if it works on all routers, it's probably isp related. . But when I lived in an apartment I used to get disconnected, drop screen would pop up.. then go for like 10 seconds, then disappear,  then pop back up for another 10 seconds until I eventually dropped.. I figured out I was able to tab out of war2, disconnect from my Internet connection, then auto reconnect and tab back into the game and keep playing without dropping
This is why I made my lag defender, and the abuse of the screen shot key will cause the lag box. I can set the time to 0 and drop who ever is showing up without a waiting the 30 seconds.
Axe Thrower Posts: 303 Karma: +20/-0 ****

Lambchops

  • Axe Thrower
  • ****
  • *
  • Posts: 303
    • View Profile
Re: Server Update
« Reply #6 on: November 01, 2016, 02:24:46 PM »
I'm not sure if it works on all routers, it's probably isp related. . But when I lived in an apartment I used to get disconnected, drop screen would pop up.. then go for like 10 seconds, then disappear,  then pop back up for another 10 seconds until I eventually dropped.. I figured out I was able to tab out of war2, disconnect from my Internet connection, then auto reconnect and tab back into the game and keep playing without dropping

Yeah that sounds like a busy ISP downgrading the priority of your connection, but when you reconnect you're back at the top if the list. It's pretty common practice. I'd assume they must have been assigning you a static address for you to be able to continue in the same game?
Administrator Ogre Posts: 1019 Karma: +98/-9 *****

iL

  • Administrator
  • Ogre
  • *****
  • *
  • Posts: 1019
    • View Profile
*

iL

Re: Server Update
« Reply #7 on: November 01, 2016, 04:41:12 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.

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.

Yeah that sounds like a busy ISP downgrading the priority of your connection, but when you reconnect you're back at the top if the list. It's pretty common practice. I'd assume they must have been assigning you a static address for you to be able to continue in the same game?
Yes, i never saw such behavior, but could be quite possible: if the connection restores, traffic can just continue to go. Thanks to UDP protocol again.
Also, if there's an external connection (router to internet) restarting, your external ip should be the same to let it work.
Not sure about breaking and restoring internal connetion between router and client: is it possible to restore the connection if your internal ip has been changed? I mean, disc, ip changed from 192.168.0.2 to 192.168.0.3 and then your connection to war2 being restored. I think even this behavior is possible.
Ogre Mage Posts: 2276 Karma: +41/-7 ********

tk[as]

  • Ogre Mage
  • ********
  • *
  • Posts: 2276
    • View Profile
Re: Server Update
« Reply #8 on: November 01, 2016, 05:09:45 PM »
Static IP. wireless net gear router. IPv4 address stays the same
(ง︡'-'︠)ง "Bitchin!" ®©℗™ Dragon Posts: 6061 Karma: +135/-70 "It's going to be Legen-(wait for it......)-DARY!" **********

EviL~Ryu

  • (ง︡'-'︠)ง "Bitchin!" ®©℗™
  • Dragon
  • **********
  • *
  • Posts: 6061
  • "It's going to be Legen-(wait for it......)-DARY!"
    • View Profile
    • Clan EviL Official Page
Re: Server Update
« Reply #9 on: November 01, 2016, 08:33:42 PM »
Static IP. wireless net gear router. IPv4 address stays the same


This.


Sent from my Nokia 3310 using Tapatalk
Axe Thrower Posts: 303 Karma: +20/-0 ****

Lambchops

  • Axe Thrower
  • ****
  • *
  • Posts: 303
    • View Profile
Re: Server Update
« Reply #10 on: November 02, 2016, 05:24:08 AM »
Static IP. wireless net gear router. IPv4 address stays the same

I meant the external external address your ISP is assigning to you, that is what the other clients have.

Are you talking about reconnecting to your router or reconnecting to your ISP? Once the game is started changing your LAN address probably wouldn't be a problem, but changing the public address that your ISP is assigning to you would be.

If you were just talking about reconnecting to your router then probably its not your ISP, its a settings/firmware issue with your router.
Axe Thrower Posts: 303 Karma: +20/-0 ****

Lambchops

  • Axe Thrower
  • ****
  • *
  • Posts: 303
    • View Profile
Re: Server Update
« Reply #11 on: November 02, 2016, 08:47:49 AM »
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:111.222.123.2:6112:945B98D1"

The joining client then replys with "#confirm:join:945B98D1"

When the host gets time they generate an in-game message like "#restart:111.222.123.2: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 :) )

Axe Thrower Posts: 303 Karma: +20/-0 ****

Lambchops

  • Axe Thrower
  • ****
  • *
  • Posts: 303
    • View Profile
Client Update!
« Reply #12 on: November 02, 2016, 09:50:22 AM »
there is one WC2 mod that is head and shoulders above everything else absolutely screaming out to be implimented.

That mod is breaking the 128x128 map size limit. Historically I know this has been looked at before, but I dont see why it couldn't be done.

It also leads to another 2 mods that I would like to see, and they are :
 - Increasing the game display from the rather miserly 14x14 window we currently have
 - Breaking the maximum per game unit cap - cannot create unit - this one could possibly be quite easy.

Internally locations are mostly stored as 2 WORD size variables and often passed or referenced as a single DWORD argument so most of the game code already supports a map size of up to 65536x65536. There are, however parts of the code that impliment WORD sized absolute pixel co-ordinates, which restricts things to 2048x2048, but even this would be pretty cool.

Implimentation would not be trivial, but it could be almost all done just by modifying the existing code without actually having to add any new code in.

We would have to do this (at least!)

- Mod existing PUD editors to allow the creation of large maps.

- redefine the valid .PUD check so the clients will accept larger maps

- Mod things like any internal co-ordinate checks that may declare co-ords >127 to be invalid, it would be nice if these would all be based on the map size in the PUD file, but as there are currnetly only 4 legal map sizes there will probably be sections that are hard coded to make calculations based on one of these 4 sizes. All this code would ned to be chased down and modded or re-written.

- Increase any buffer allocations to allow for bigger maps, possibly parts of the executable's .data and .data? sections will also have to be redefined to allow more space.

- Check and mod the display code to allow for larger maps. Scaling for the mini-map is an obvious one, as is the buffer that keeps the background updated (this one is why you can see where trees are chopped even if you don't currently have vision there).

The main view code probably wouldn't have to be changed at all apart from any checks that just flat-out reject large co-ords.

.... Possibly by this time we might know enough about the display code to increase the 14x14 window size by having the internal routines draw the units to a larger buffer, then resizing that image and pasting it onto the existing screen buffer. There are also a bag of issues related to translating mouse input from this resized window.

--> This also leads to running the game at higher screen resolutions, which would be nice, but that would be another BIG mod. Where do you draw the line? It would be nice for it to actually be done before we are all too senile to enjoy it ;)

Breaking the unit cap should just be a matter of increasing the buffer allocation and finding any bits of code that impliment:

if n_units>MAX_UNITS {say "BLEH!"}







Ogre Mage Posts: 2319 Karma: +73/-1 ********

tupac

  • Ogre Mage
  • ********
  • *
  • Posts: 2319
    • View Profile
Re: Server Update
« Reply #13 on: November 02, 2016, 02:27:15 PM »
The most I've gotten to is war2 sitting at black screen when I used my maps bigger then 128x128. I think I nulled out the minimap and it no longer crashed. But I was stuck there and clueless. What do you think about that?
Axe Thrower Posts: 303 Karma: +20/-0 ****

Lambchops

  • Axe Thrower
  • ****
  • *
  • Posts: 303
    • View Profile
Re: Server Update
« Reply #14 on: November 02, 2016, 04:21:03 PM »
The most I've gotten to is war2 sitting at black screen when I used my maps bigger then 128x128. I think I nulled out the minimap and it no longer crashed. But I was stuck there and clueless. What do you think about that?

I think you gave up to soon ;)