PBEM Battles with custom maps problem

[NickFlynn]

I recently tried to set up a PBEM using the custom map - "Desert area after rain." After I set up the map and purchased my forces, I couldn't open the game up again. Everytime I tried to open the file, WinSPMBT would lock up.

After fooling around for a while it seems that it only happens on very large maps (the one I was trying to use was 160x200.) I didn't have the patience to try it on all the sizes, but all of the 160x200 maps crashed the game when you tried to open the battle after saving it.

Is this a known bug?

- Nick

[Mobhack]

Hmm

I have managed to do this - wheter it is the map itself, or a custom map in general that causes the problem - I will need to investigate.

Does this also happen when you send the game to player 2?

Cheers
Andy

[Mobhack]

Looks fixed - but will need a bit of testing, should be in the next release.

For now - dont use custom maps in PBEM (secure or insecure mode).

Some custom maps may work, but others cause the problem on loading in PBEM.

Cheers
Andy

[NickFlynn]

It did indeed happen when I sent the file to the other player. After he told me, I tried it myself and then discovered the problem.

I really think it is map size related, but I guess I could be wrong. I wasn't able to duplicate it with smaller maps.

Although the map generator is much improved, I really do like running battles on custom maps.

- Nick

[Mobhack]

it will not happen with all maps, and the problem may well happen with other saved games.

It seems to be older maps (?) - and is caused by a probably redundant bit of original SSI code which fixes shell hole numbers. probably from way back in the SP1 to SP2 days, to convert these maps. Unfortunately - it did not do any array bounds checking on the 6 by 6 array of ID numbers it's using so if uninitialised map data goes in, BOOM.

I have added range checking based on the code which actually produces shell holes - and the original code only checked 1 parameter, whereas I am screening 6 or so now to see if the data presented is OK.

I'm also investigating the function's actual relevance - it seems to have become redundant in maybe 1996 or so !. Simply commenting it out in the load function causes no noticeable problems. So it probably only applied to SP1 maps, or some early version of SP2 methinks to "massage" old-form shell holes and rubble to the new improived model.

meanwhile - the only way to check if the particular custom map is not going to trip this broken function is to set up a quick PBEM with custom map as P1 (any nation pair and just buy a random formation) , load the map, and save as a secure or insecure PBEM. Then load up the saved game as if you were P2. if it loads and does not crash, you will be fine.

I believe this routine probably worked fine in Windows 98 and below (I only have an XP rig on line now, the 98 box is in a cupboard). Unless of course you are trying it in 98?. However - XP seems to be more "picky" about out-of-bounds memory adressing than 98 was.

cheers
Andy

[NickFlynn]

Wow, thanks for the info, and the quick response. You never worked at Microsoft, did you? *grin*

The quick "test" setup to confirm that the map won't crash has worked fine for me so far. Does the same problem occur when you create a scenario using a "bad" map? I haven't tried that yet. I'd assume that it does. Perhaps if I've got some time, I'll test out some maps and try to put a list together of the bad ones.

I am running XP.

Thanks again,
- Nick

[DRG]

This seems to be a "XP only" issue. I'm running WinME and it loads a save game using that map without the slightest problem.

Don

[Mobhack]

Microsoft, nope - Unisys, Phillips, NCR.

The problem is apparently XP only. 98 is happy as Larry to let you try to write to arrays that are out of bounds.

The custom map problem is not just in PBEM - I tried a stand alone game with that map, saved it at deploy and reloaded, and it crashed in XP.

I'll dig out the old 98 box and check it, but the fix looks as if it has done what is needed in any case.

Cheers
Andy

[NickFlynn]

Glad about the fix. I'm happy to have contributed in a small way to make a great game even better.

- Nick

[DRG]

Thanks for pointing it out to us

Don