3.2 Beta - crash to desktop replay zoom

[rickier65]

Recieved first PBEM turn from my opponent. After entering password had the zoomed map view for replay, tried to zoom out with mouse wheel, got message:

Parent Unit Error
Parent unit is invalid
Say yes to continue and then it crashed to destop.

I tried this multiple times with same result.

I could watch through the replay in the zoomed out mode without problem.


The email turn I was playing was generated on "laptop in 1024x768/32bit display mode
when I generated the PBL file". My mode was also set to 1024 by 768 on a desktop.

Rick

[JAMiAM]

ORIGINAL: Rick


Recieved first PBEM turn from my opponent. After entering password had the zoomed map view for replay, tried to zoom out with mouse wheel, got message:

Parent Unit Error
Parent unit is invalid
Say yes to continue and then it crashed to destop.

I tried this multiple times with same result.

I could watch through the replay in the zoomed out mode without problem.


The email turn I was playing was generated on "laptop in 1024x768/32bit display mode
when I generated the PBL file". My mode was also set to 1024 by 768 on a desktop.

Rick

Thanks for the error report. You're not supposed to try and zoom during the playback. We'll have to try and fix that for the next patch so that mouse wheel zooming is disabled during playback.

[murphstein]

I'm "the opponent" Rick refers to above, and had a similar problem with the replay of his first turn. During my replay of his first turn, the screen went blank (possibly after I touched my mouse in an inappropriate way) and the replay ended; when I tried to restart the replay, the appl exited. I happen to have VisualStudio installed and it should have caught an appl exception and opened the debugger; it did not, so I'm guess there's an exit() call or equivalent being exercised somewhere.

I have since opened the same Turn 1 PBL file and viewed the replay several times, zooming in and out with the wheeled mouse during the playback, without reproducing the problem. Go figure...

[dpm edit] Actually, the difference between the first (problem) and subsequent (worked) cases was that, in the "problem" case, I had other applications running; in the "worked" case, only the TOAW appl was running (aside from all the system stuff, of course).
Perhaps there's a system-modal method used where there shouldn't be?

I've also seen the unexpected exit behavior when doing a "File -> Save As..." operation in a PBEM game; the appl just exits without warning after writing the SAL file as requested. No, I did NOT pick the "Save and Close" option.

See also:

tm.asp?m=1569355

[JAMiAM]

ORIGINAL: murphstein
I've also seen the unexpected exit behavior when doing a "File -> Save As..." operation in a PBEM game; the appl just exits without warning after writing the SAL file as requested.  No, I did NOT pick the "Save and Close" option.

When playing a PBEM game, the application is supposed to close after saving a game, whether a mid-turn SAL file, or the end of turn PBL file. Earlier versions of TOAW had a cheat path when allowing the application to stay open after saving PBEM games. We just never went back and cleaned up the button choices to make them different for PBEM games.

[murphstein]

jamiam,

See the GameSquad New Player Workshop forum thread on PBEM issues under the Axis Players private sub-forum for more info on Rick's original problem at the top of this thread.

[JAMiAM]

ORIGINAL: murphstein

jamiam,

See the GameSquad New Player Workshop forum thread on PBEM issues under the Axis Players private sub-forum for more info on Rick's original problem at the top of this thread.

Thanks Dan. When Ralph isn't so buried, he can take a look at the file there and see what's amiss. It sounds like a bit of file corruption on that set of game files that you guys are passing back and forth, but he'll be able to more easily determine the likely cause. You don't need to send the password if Ralph's looking at it, since he can hack straight into it.

[murphstein]

Don't know if Ralph's looking into it, or even if it's worth looking into.  A coding error that causes the loss of a parent-reference sure sounds like something that would have turned up way earlier in the test cycle, so I'm willing to write this off as "file corruption during email transfer" and let it go at that (unless, of course, it happens again)... [:)]