Experimental D3D9 Build (2009-12-11)

[sabrebattletank]

Mine only runs in windowed mode.

[Commando]

One of my savegames refuses to load, produces a crash when trying to load.

00491C09  mov         eax,dword ptr [ecx*4+7CBFC0h]

'bzone.exe': Loaded 'C:\Windows\SysWOW64\mcicda.dll'
The thread 'Win32 Thread' (0xb5c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xac0) has exited with code 0 (0x0).
First-chance exception at 0x00491c09 in bzone.exe: 0xC0000005: Access violation reading location 0xfc7cf020.
Unhandled exception at 0x00491c09 in bzone.exe: 0xC0000005: Access violation reading location 0xfc7cf020.

[Ultraken]

That's in GetTilePtr(), indicating that something is looking up a terrain tile far outside the mapped area.  Do you have a call stack?

I can try loading your save file if you put it somewhere I can get it.

[Commando]

It'll take me a moment to upload it onto the betadudes folder.

[Commando]

Try this savegame.  http://www.bzuniverse.com/~betadudes/unprotected/game8.sav

[Commando]

That's odd.  Now it will load without dieing.  The only major change is that I restarted my computer and that my resolution was low instead of being maxed.  Now that I have my res back up, I'm going to try again.

[Commando]

It dies if my resolution is 1280x1024, or whatever bz1 maxes out at, but it is fine if it is at 640x480, weird.  My other savegames don't have this issue which is odd.

This issue is weird, sometimes the savegame will load, other times it won't.  I had some luck loading my save1 first then loading save8.  It loaded until I shut down bz1, then restarted it.  Once it restarted, I tried loading save8, again death on load.

I gave you the only info bz1 gives me.  It doesn't produce an AV dialog box.  Win 7 says the program stopped responding and gives me the option to close, and that's the only option, unfortunately.

[Ultraken]

BZ definitely needs a better logging and reporting system...

Anyway, I'll give the save file a run here to see what happens.

[Commando]

This is what was in the callstack info.

>   bzone.exe!00491c09()    
   [Frames below may be incorrect and/or missing, no symbols loaded for bzone.exe]   
   bzone.exe!0043f6cb()    
   bzone.exe!00404d0d()    
   bzone.exe!0044db40()    
   bzone.exe!00450220()    
   bzone.exe!0044cdc0()    
   bzone.exe!0044b3d5()    
   bzone.exe!0044b1d9()    
   bzone.exe!00401774()    
   bzone.exe!00428910()    
   bzone.exe!00401030()    
   bzone.exe!004561f5()    
   bzone.exe!00457100()    
   bzone.exe!0052614d()    
   kernel32.dll!76133677()    
   ntdll.dll!77b79d72()    
   ntdll.dll!77b79d45()    

[Ultraken]

Ah.  If you have the .pdb file in the same directory as the executable, you should be able to tell the debugger to load symbols using the Modules tab on the bottom left.  Just right-click on bzone.exe in the list and it should give you the option.

[Ultraken]

I loaded that save game and immediately got an invalid floating-point operation in Vector_Rotate().  One of the AI vehicles ("svlt1328_wingman") has a bad target direction vector since one of its weapons (an instance of "gtaggun") hasn't initialized its hardpoint world matrix yet.  AbleToHit() just ends up using whatever trash happens to be in memory.

That is a very serious flaw in the Weapon class, and I'm surprised that this kind of thing didn't come up more often.

[Commando]

Omething easily fixed?

[bb1]

Apparantly not easy to fix. He said very in italics...a grave adjective modifier indeed... You misused the italicizing to make it seem difficult to fix!

Aren't HPs rotated some direction from the real-world model? DX could clarify there.

[Ultraken]

It was an easy fix, but a dumb mistake on my part (in 1997, mind you) in a core system that could have produced all kinds of problems.  Fortunately, the window of opportunity for it to cause trouble was extremely narrow. 

Setting the matrix in the Weapon's constructor function was the solution.

[Josiah]

Sandmod map had a thumper that did that. HOld down and watch the hell and the crash.

no, it won't go away! You will have a 1000000000000000000000000000 ft mnt there for the rest of the mission! My guess is that all the shock waves get "tangled" up with each other, and can't continue shockwaving away from the explosion center.