pbem game password problem

[PopskiPPA]

The game refuses my opponents (player 2) password when he tries to open turn 12. The message is "wrong password".
He can open earlier turns without problem, so I think he has not forgotten the spelling.
The files have always been sent compressed. After the problem occured I tried different compression programs, no change.
We replayed a few turns and had no problems until we came again to turn 12, his password was rejected.
I read the other thread that dealt with this problem and I don't think it is a problem of file corruption (harddisk/transfer) because it happens always at the same turn (my harddisk is checked for defects, none detected).
I cannot say for sure that we did no stupid things. It is possible that we used a slot that contained a started but not finished game, we had funny loads/quits/fails-numbers from the beginning.
I'm attaching the last few turns, so you can see that the password really changed. Password player1 argl731, player2 tobispiel
Is there a chance that we can continue this game? Maybe with the new password?

[Mobhack]

I have just run these through the debugger, and the passwords dont change between turns.

However - the save file you sent with the game you cannot load has nuked the "S" character with what appears to be an 88 hex (shown as a vertical black bar in my UK debugger) in tobi|piel. (I used the verical pipe there as it is not a regular character - but may be an umlaut or such on a foreign language keyboard??)

Running the game on fails on the path having changes as I am running on a different folder etc - but the extracted passwords on my machine are still A-OK at the point the path gets rejected - they have been extracted and decoded fine. And at that point they have been saved and encrypted to file and re-extracted back from disk, so that mechanism is OK.

So the only thing I can think of is a transmission error, or a memory error (RAM or Disk) on one of the machines.

Transmission error - if you are using different compression routines (e.g. one is using winzip and one winrar) or different versions, oddities can occur. Winrar allegedly can unzip zip files - but as it is not winzip, there may be differences in its zip file algorithm. (I use Winzip, and never RAR).
Also - it may just be a send error in your email programme - a resend may work (I have had recent problems with zips I sent to Don, that opened fine etc on my machine, even if I used the copy of the zip in the "sent items" folder, but gave CRC errors and so forth on his end, both of us using winzip. But we had regularly exhanged zips fine before, and the problem then went away after a day or so with no change and recent ones worked with no hiccups). This could be any link in the email chain - like anti-spam and virus checking add-ons as well as the email clients themselves. Me suspects the anti-spam and anti-virus stuff (including any the ISPs have) and that a later signature file update or suchlike fixed it behind the scenes!

I would try a resend of the known good save point, ensuring you have the same compression utilty. (if you are both on broadband - try sending the uncompressed file perhaps). Maybe try several such - if one "takes" then the transmission chain likely had a glitch.

You could also try sending via a different ISP/email client route - e.g if you have say a hotmail or suchlike account.

Memory error - a bad file block on the hard drive could cause corruption, as can a glitch in RAM. You would need to do a scandisk on both machines to eliminate lost clusters - and try again. Failing that - a scandisk with sector search for bad drive sectors (which takes forever so is best done as an overnight run).

RAM errors - extrememly rare these days, symtoms are generally a dead machine, not dead bits - you would need to find a utility that examines RAM (I think Norton has such?).

I would look at the transmission (compression and email client as well as ISP) area first. Especially if you have been doing RAR one way and ZIP the other.

Cheers
Andy

[PopskiPPA]

Thank you very much for putting time into this and the quick answer.
We will try the possible solutions and post the results.

Popski

[PopskiPPA]

Using different compressing programs or sending the files uncompressed did not solve the problem.

But delaying the arrival of paradrops and glider landings by one turn made the problem appear one turn later. So I started a new pbem against myself on the same map. The turn after the paradrop/glider landings the password of player 2 was no longer accepted. The paras/gliders were russian. It didn't matter if the russians were played by player 1 or player 2, the password of player 2 was rejected.

So the problem seems to be associated with paras/gliders and/or the map.

Just ran a quick test:

August 1946, visibility 30, USSR vs USA, meeting engagement, random map 150*150

I bought in this order for Russia:

3* unit 200 G-11 Glider
1* formation 161 Para Company [A], last section deleted
8* unit 200 G-11 Glider
2* formation 43, unit 70 Guards Platoon
2* formation 100, unit 139 Horsa (Poland allied)
1* formation 4, unit 127 Guards Tank Co, last two sections deleted
1* formation 4, unit 294 Guards Tank Co, last two sections deleted

The first three glider stay empty to soak up AAA, the tanks go into the Horsas. All are plotted to land after turn 1 on the left side of the map. Entry top left corner, exit bottom left corner.
The turn after the landing player2s password is rejected.
Just repeated the test with the landings after turn 2, same result, password rejected after the landing.

I repeated this multiple times, every time the same result.

So it seems there is a problem with paras/gliders. I don't think it is faulty RAM or the harddisk because I can reproduce the problem.
How likely is it for faulty hardware to always affect the password of player2 and only after the landing of paras/gliders?
There was no transfer in the test game, so no corruption possible.

I'm attaching the turns of the test game.
password player1 russia
player2 usausausa
path in both cases D:\WinSPWW2

Popski

[Mobhack]

interesting. it sounds as if it may be an array overrun, one of C/C++ little 'oddities' (sane languages like Pascal would throw an exeption at any attempt to address ouside an array's bounds).

I will look into this.

Andy

[Mobhack]

OK - it was array addressing, but due to a typo I must have made some time ago.

It was in the glider landing routine, and results in data overwriting the password block. Now fixed (MBT and WW2).

Very good catch - it was a subtle little thing, which needed careful step-through on the debugger to find.

Until the newest EXEs come out - passworded PBEM games with gliders should not be played.

Cheers
Andy

[PopskiPPA]

Thank you for taking my observation seriously.

One little request: would it be possible to change the scrambled password of player2 back to what it was before the gliders landed? It was tobispiel. I'm attaching the turn (played for the first time, not the repeatedly played turn during testing).

It would be nice to finish this game before we change the sides.

Thank you very much!

PopskiPPA

[Mobhack]

Sorry, but no.

A PBEM game is difficult enough to debug - one often has to go into the code and comment out lines for things the game is objecting to, and so on just to get the debug info. So actually changing that data - and getting it back on disk in a playable state (on the other players installation) from a game that has technically failed security, is decidedly non trivial. A PBEM game can really only be "debugged" by breaking it and the actual programme code.


Cheers
Andy