Constant Crashing on Save

[whitefantom]

I'm relatively new to TDM and I'm nearly at the end of my third mission (Heart of Lone Salvation), but I keep running into a brick wall and I'm not sure if I'm even going to be able to finish this mission. Almost every time I try to save the game (either quick save or regular save), the game crashes to the desktop.

 

I had this happen a couple of times in the first two missions I played, and I had it happen a few times in HoLS in the beginning, but I'm near the end and 95% of the time my saves crash and I can't go any further (unless I finish the mission in one go with no saves, of course).

 

Here's the error I get when this happens:

 

WARNING: Door HeartDisplayDoorA is not within a valid AAS area

WARNING: Door HeartDisplayDoorB is not within a valid AAS area

WARNING: Door DoorWaterworks is not within a valid AAS area

WARNING: Door ChestLid6 is not within a valid AAS area

WARNING: Door dresser_doorB2 is not within a valid AAS area

WARNING: Door dresser_doorC2 is not within a valid AAS area

WARNING: Door bureau_doorB2 is not within a valid AAS area

WARNING: Door bureau_doorF2 is not within a valid AAS area

WARNING: Door bureau_doorControlF2 is not within a valid AAS area

WARNING: Door bureau_doorA2 is not within a valid AAS area

WARNING: Door bureau_drawerB2 is not within a valid AAS area

WARNING: Door bureau_drawerA2 is not within a valid AAS area

WARNING: Door bureau_doorE2 is not within a valid AAS area

WARNING: Door BoltHatch is not within a valid AAS area

WARNING: Door DoorWardrobeA2 is not within a valid AAS area

WARNING: Door DoorWardrobeB2 is not within a valid AAS area

WARNING: Door BannerLifter is not within a valid AAS area

WARNING: Door DoorWardrobeA3 is not within a valid AAS area

WARNING: Door DoorWardrobeB3 is not within a valid AAS area

WARNING: Door FootlockerLid_6 is not within a valid AAS area

WARNING: Door BustSecretLever is not within a valid AAS area

WARNING: Door SecretDoor is not within a valid AAS area

ModelGenerator memory: 55 LOD entries with 185 users using 33934 bytes, memory saved: 80477 bytes.

WARNING: idClipModel::FreeTraceModel: tried to free uncached trace model (index=0)

--------------------------------------

Shutting down sound hardware

idRenderSystem::Shutdown()

Shutting down OpenGL subsystem

...wglMakeCurrent( NULL, NULL ): success

...deleting GL context: success

...releasing DC: success

...destroying window

...shutting down QGL

...unloading OpenGL DLL

------------ Game Shutdown -----------

--------- Game Map Shutdown ----------

ModelGenerator memory: No LOD entries.

--------------------------------------

ModelGenerator memory: No LOD entries.

Shutdown event system

--------------------------------------

CRawBuffer::resize: realloc failed (from 33554432 to 67108864 bytes)

 

 

 

It's always this same error, though the exact number of bytes varies (most of the time, the first value is just 16 bytes, but occasionally it's a larger number in the megabytes like above). I even loaded a save and then immediately tried to save it again under a new file name, and it still crashed, so it seems like there's no rhyme or reason--one save works, but another save under the exact same circumstances (though a second or so later than the first) crashes to the desktop and gives this error.

 

I usually save under a new name every time, but it doesn't seem to make a difference whether I'm saving as a new file name or overwriting an existing save.

 

My specs are:

- Windows 7 x64 (8 GB RAM)

- Core2 Quad 2.67 GHz

- nVidia GForce 9800 GTX+

 

- Doom3 is from Steam, purchased about a week ago so it's the most recently-patched version

- Dark Mod v. 1.06

 

If I've left out anything important, let me know. And thanks ahead of time to anyone who can help!

 

--Jennifer

[Sotha]

Hm.. Memory issues?

Check your doomconfig.cfg for the following entries:

seta image_usePrecompressedTextures "1"

seta image_useNormalCompression "2"

seta image_useAllFormats "1"

seta image_useCompression "1"

seta image_preload "1"

 

Are they set like shown? If not, set 'em like this. It may slow down the mission load time slightly, but will improve ingame performance. It will also neutralize some memory crashes.

 

EDIT: corrected the mistake useCompression "0" into "1".

[whitefantom]

I checked DoomConfig.cfg, and the only thing that wasn't set as shown was useNormalCompression (mine was "0" rather than "2"). Everything else was the same as in your post. So I changed useNormalCompression from "0" to "2" and saved it. At first, the mission kept changing this value back to "0," so I had to uninstall the mission, change DoomConfig.cfg and save, then reinstall the mission, but I verified that after uninstall/reinstall, the value stays at "2."

 

Unfortunately, doing this didn't help. At this point, every save now results in a crash to the desktop (same error as previously posted). I've even loaded a number of previous saves from different points, and saving after loading even these older save now causes a crash.

 

The only other thing of note is that in my last two or three successful saves, certain sounds seem to be missing (ambient sounds, torch crackling sounds, and stone-sliding-against-stone sounds in particular that I noticed). I also had this happen earlier when I first got to the pump room, and after searching in the forums, I found one other person who'd had a similar issue and had ended up reloading an older save in order to restore those sounds. I did the same thing at that point and my missing sounds were back with no problems; now that I'm having this save problem, and I'm also noticing the disappearing sounds problem has come back, I'm wondering if they have any relation. I don't know anything about the inner workings of TDM, so there may be no relation whatsoever, but other than the now 100% crash-on-save rate, the missing sounds are the only other anomaly I'm experiencing.

 

--Jennifer

[Sotha]

Damn! I wonder if this has something to do with the savegame compression that was implemented some time ago. Maybe those people who know more about that could chime in?

[Mortem Desino]

This happens only when you save, and not load? Huh.

 

stgatilov knows more than I about what happens during savegame creation. It's interesting to see that this is a realloc failure, and it seems like it's happening without hitting any arbitrary memory allocation ceiling.

[whitefantom]

Nope, I've never had any kind of crash on load. The saves that are created when I get the crash on save are obviously corrupted files, so if I tried to load one of those, I get an in-game error telling me the load failed, but I'm then free to pick another save and load it without issue.

 

I haven't had a chance to install a different mission and see if I'm still unable to successfully save. I've had these same crashes on save from the very beginning, so I know it's not just in this mission, but it's gotten to the point where I'm not able to save at all. When I get a chance, I'm going to see if I still can't save at all even with another mission, or if it the frequency of crashes has something to do with the complexity of HoLS and being a good 4+ hours of gameplay into it.

 

--Jennifer

[Springheel]

The disappearing sounds are very strange indeed.

[Mortem Desino]

Yes, this appears as if the game was saving, and then bombed in the middle of the process while allocating memory.

 

Try setting g_flushSave to 1 (default "0") and report back if it stops crashing.

[whitefantom]

I assume you meant to change g_flushSave in DoomConfig.cfg, but when I looked at the file, there was no such setting in there. After uninstalling the mission, I added a line at the bottom of DoomConfig.cfg: seta g_flushSave "1". Then I reinstalled the mission, but I still got the same crash on save. Also, when I went and checked DoomConfig.cfg after the crash, the line I added was gone (I'd specifically uninstalled the mission before changing the file to make sure my changes would stay saved, but that didn't work this time).

 

Possibly you meant for me to change this setting somewhere else; if so, where should I make the change?

 

I did try installing a different mission to see if I had the same problem, and I was able to save successfully after loading an old save from the end of Tears of Saint Lucia, so it looks like the problem is strongly related to something in this mission (it's not just this mission, though--as I said, I've had this same crash a few times in all missions I've played so far, but at this point in HoLS, it happens every time I try to save--so the problem isn't unique to this mission, but the current severity definitely seems related to it in some way).

 

--Jennifer

[Mortem Desino]

I should have been more specific. I meant you to change it in the console (ctrl-alt-~). This cvar change is instant, so no restarting is neccessary.

[whitefantom]

I wasn't sure exactly what I should type into the console, but I tried the most obvious thing: set g_flushSave "1". In order to confirm I'd set it correctly, I made a guess that simply typing g_flushSave by itself would show me its current setting, and luckily I guessed right--it told me it was set to "1". Unfortunately, after dismissing the console and trying to save, I got the exact same crash and the exact same error. :-(

 

This issue doesn't seem to be responding to anything. It's also strange that I still get the same crash on save even after loading previous saves that had worked fine with no problems at the time.

 

I've seen in passing while looking over the forums that some people have had issues with bodies being moved and contorted when loading previous saves, and in case it's relevant, I have the same issue. I'm not a ghoster--I enjoy blackjacking pretty much everything I possibly can in a mission (and I love that in TDM it's actually a challenge again to make a successful KO), so I have a lot of bodies lying around by this point in the mission. I haven't gone around to look at them all, but is it reasonably possible a contorted body has been moved in such a way to create this situation where saves consistently fail? I'm pretty much grasping at straws at this point, trying to think of anything that might be making a difference, and besides the missing sounds, this is all I can come up with.

 

--Jennifer

[Mortem Desino]

No one is quite certain about the ragdoll problem. I believe it's an unrelated issue because it occurs with or without savegames.

 

Okay: still crashing means it's not necessarily a buffer problem. Go and set g_flushSave back to 0 (console: g_flushSave 0)

 

Next goofy experiment console cvar change: tdm_savegame_compress 0

[whitefantom]

That did it!

 

I set tdm_savegame_compress to "0" and was able to save without any problem. Of course, the size of the file went from 8.5 MB to 42 MB, but at least it worked. :-)

 

The change isn't permanent, though--when I exit the game, the setting goes back to the default. Is there a way to make this permanent (preferably only for this mission, since the issue doesn't seem to affect all missions the way it does this one)?

 

And now that we know it's apparently related to the save game compression, is there a way to fix it without having to disable compression at all?

 

--Jennifer

[Mortem Desino]

Doom 3 will try to write the cvar change to DoomConfig.cfg. If the change isn't staying permanent, it's probably due to write-privileges. Check the right click-properties of DoomConfig.cfg (both the mission folder and darkmod folder) to make sure that they are not read-only.

[Sotha]

That did it!

 

I set tdm_savegame_compress to "0" and was able to save without any problem. Of course, the size of the file went from 8.5 MB to 42 MB, but at least it worked. :-)

 

[..]

 

And now that we know it's apparently related to the save game compression, is there a way to fix it without having to disable compression at all?

 

--Jennifer

 

So it WAS the savegame compression! Good find! Someone ought to let stgatilov know about his. I'll add it to the v1.06 bug thread.

 

Now the weird thing is that it seems to be somehow system / setup specific as it always fails for you, but I've never had any issues with saving with compression on.

 

Hopefully it is just a simple bug which the coding heroes can crush easily...

[whitefantom]

Now the weird thing is that it seems to be somehow system / setup specific as it always fails for you, but I've never had any issues with saving with compression on.

 

Actually, it was more of a progressive problem for me, and primarily just in that mission. I did have the same crash a couple of times in other missions, but in HoLS, the farther into the mission I went, the more frequent the crashes got, until I reached the point where it was happening every time I tried to save. But When I installed a different mission, I was able to save with no problem (and when I reinstalled HoLS, the problem was back). So it's probably a combination of my setup and some aspect of HoLS that manifested the problem and caused it to get worse farther into the mission. It's possible it may be so situation-specific as to be almost impossible to reproduce.

 

--Jennifer

[Springheel]

Glad you got it working.

[nbohr1more]

Hm.. Memory issues?

Check your doomconfig.cfg for the following entries:

seta image_usePrecompressedTextures "1"

seta image_useNormalCompression "2"

seta image_useAllFormats "1"

seta image_useCompression "0"

seta image_preload "1"

 

Are they set like shown? If not, set 'em like this. It may slow down the mission load time slightly, but will improve ingame performance. It will also neutralize some memory crashes.

 

 

Actually the above is correct except:

 

seta image_useCompression "0"

 

must instead be

 

seta image_useCompression "1"

 

If you haven't already, I would try disabling UAC and see if re-enabling Savegame compression still crashes...

[Tels]

Actually, it was more of a progressive problem for me, and primarily just in that mission. I did have the same crash a couple of times in other missions, but in HoLS, the farther into the mission I went, the more frequent the crashes got, until I reached the point where it was happening every time I tried to save. But When I installed a different mission, I was able to save with no problem (and when I reinstalled HoLS, the problem was back). So it's probably a combination of my setup and some aspect of HoLS that manifested the problem and caused it to get worse farther into the mission. It's possible it may be so situation-specific as to be almost impossible to reproduce.

 

--Jennifer

 

Glad you got it to working, lets hope sstgatilov can reproduce and fix the crash

 

Btw, very nice artwork and appropriately themed, but I guess by chance http://www.deviantart.com/print/4888347/

[Sotha]

Actually the above is correct except:

 

seta image_useCompression "0"

 

must instead be

 

seta image_useCompression "1"

 

If you haven't already, I would try disabling UAC and see if re-enabling Savegame compression still crashes...

 

Whoa, that's a big mistake on my part, sorry. Thanks for fixing it, nbohr!

 

You should flip the compression on (to 1) in any case to avoid memory problems and a more smooth gameplay.

[Bikerdude]

--Jennifer

Btw you don't need to put your name on the end of every thread (I used to do this for ages(but never with my real name btw, until I realised I wasn't righting a letter etc...)

 

[whitefantom]

Btw, very nice artwork and appropriately themed, but I guess by chance http://www.deviantar.../print/4888347/

 

Thanks. :-) It's not really by chance, though--I did that painting as mock cover art for a book I'll probably never get around to writing, and the main character is a thiefy sort who was heavily influenced by Garrett. :-) (The model for the painting was actually my husband, who's never played any of the Thief games and felt rather silly posing for this cover ;-) ).

 

--Jennifer

[whitefantom]

Btw you don't need to put your name on the end of every thread (I used to do this for ages(but never with my real name btw, until I realised I wasn't righting a letter etc...)

 

 

 

Old habits are hard to break--I've signed my name to my posts for fifteen years. I know it's not necessary, but by this point, it's just kind of...a thing. ;-)

 

--Jennifer

[whitefantom]

Actually the above is correct except:

 

seta image_useCompression "0"

 

must instead be

 

seta image_useCompression "1"

 

If you haven't already, I would try disabling UAC and see if re-enabling Savegame compression still crashes...

 

 

 

I'll disable UAC next and see if I can save with compression. For what it's worth, I already have Steam, TDMLauncher, and Doom3 all set to run as administrator, if that makes a difference.

 

And a big thanks to Mortem Desino, Sotha, and everyone who gave input on this issue. I was finally able to finish HoLS without problems, and if this problem ever comes back, at least I have a workaround. :-)

 

--Jennifer

Edited July 17, 2011 by whitefantom