This, ...this damn game!

[c13Garrison]

Its so capricious and evil!!

I know its deceitful, so I save after every hallmark, every benchmark. Then, ...it gets really darn fun, and tense! And exciting, ...and its running so smooth, I don't save for a long while, but I don't think what a malicious & cunning foe she is! Such an awesome patrol I was enjoying, just staying alive a pure thrill and-

...CTD.

:/\\!!
...what an evil game. I hate it. ...I hope she takes me back in the morning. ..., is there a 12 step program for this abuse I put myself through? Maybe a glass of Highland Park will make it better.

...I love this damn game.

[in_vino_vomitus]

I never once had that problem until I started playing OM - I'm seriously thinking of restarting a Pacific campaign...

[HertogJan]

From what I've read, the more you save the bigger the chance of getting a corrupt save witch in trun 'can' give you CTD's.

So only save when:
A) There's no land close to you (within 20Nm should do).
B) There's no sonar, radar, Hydro contact.
C) You're on the surface going ahead standard.
D) If you used TC pause the game and wait 10sec then set normal time.
E) You've checked every torpedo has been loaded.
F) You're not still running silent.
G) You're in the control room (you start there anyway).

I found when forgetting one of the above chances are there will be a corrupt save somewhere in that campaign.


Obviously MOD soups can cause CTD's and are the most common reason for them but when taken every precaution very rare.
A hiccup from JSGME could also be the culprit and you'll never know if that has been your problem.

Got a couple of question's for you:
Did you try out different MOD's before you ended up with the soup you have now?
And, did you have JSGME check your files (via a snapshot) after changing those soups?

I understand if you'd rather not do this but I'd recommend a clean sweep, delete the JSGME/MODS folder and replace your Data folder if possible.
Than create a new MOD's folder and create a new snapshot of the new Data folder before installing/activating anything, then reinstall your mod soup one at a time.

Do not cut'n past the MODS folder out and in.... create a new one and put freshy unZiped MOD's in there, no copying them from the old MODS folder either!!!

As I see it JSGME is a pretty stable tool but combine it with a very unstable program like Silent Hunter you're gonna get hiccups and being very meticulous when installing/activating or deactivating/uninstalling mods gives you a better chance of succeeding in getting a stable platform.

Call me paranoid :hmph: but this keeps me from having CTD's and corrupt saves.

[BigWalleye]

Based on a fair amount of experience, I have found that there are only two things that lead to corrupted saves in SH4:

1) Overwriting an existing save. (Saving with the same name for the saved game without first deleting the previous save.) You MUST delete a saved game before you attempt another save using the same name.

2) Making ANY changes to the set of activated mods, except when "in port". This includes removing mods and re-activating THE SAME mods in THE SAME order! That means that swapping between , say, careers in TMO and OM can lead to corrupt saves in both careers. The only time it is safe to make any changes to the set of activated mods is between missions, in port.

I have saved many times under every single circumstance mentioned by HertogJan with no corrupted saves. In fact, since I learned of these two simple rules, I have not had a single corrupted save in SH4, except when I tempted fate and violated those rules (like to try a new mod before I finish the current patrol). There have been other posters here at SubSIm whose experience corroborates these rules. (In fact, that's where I learned of them.) They work.

[c13Garrison]

Thank you for the advice, and if my issues persist I will pursue a "clean slate" restart, and now I know how.

What I experience on my machine is that if I go to zone, sink some ships, then go home, the game is extremely stable. Where the errors start is when I have sinkings seperated by a great distance, such as currently Hokaido/Truk/Solomons, and I am near a bunch of ships/planes. My game crashed during a very large Japanese raid on Henderson Field, and my last save was in the middle of the Tokyo Express, which is no doubt why its not reloading. I'm currently going back in time through saves to see how I can get back to the career.

[HertogJan]

1) Overwriting an existing save. (Saving with the same name for the saved game without first deleting the previous save.) You MUST delete a saved game before you attempt another save using the same name.

Thats THE most important one :/\\!! how could I have forgotten that :nope:

) Making ANY changes to the set of activated mods, except when "in port". This includes removing mods and re-activating THE SAME mods in THE SAME order! That means that swapping between , say, careers in TMO and OM can lead to corrupt saves in both careers. The only time it is safe to make any changes to the set of activated mods is between missions, in port.

Although that speaks for its self I forgot that one aswel :shifty:

I feel like Homer Simpson atm "d'oh" :/\\!!!!!!!

I have saved many times under every single circumstance mentioned by HertogJan with no corrupted saves. In fact, since I learned of these two simple rules, I have not had a single corrupted save in SH4, except when I tempted fate and violated those rules (like to try a new mod before I finish the current patrol). There have been other posters here at SubSIm whose experience corroborates these rules. (In fact, that's where I learned of them.) They work.

I didn't either at first but got a weird one eventually, saved the game while leaving a area where I sunk a vessel (still had smoke rising and fire on the surface, ship has sunk 10min's before) I loaded the save a few days after and smoke was comming from my stern even when I was underwater and followed me the whole patrol.
A reload didn't do the trick so after the icon in patrol area turned gray I ended the patrol by going home and docked.
From that moment on I made sure I obeyed those rules and haven't had any problems... yet.


This game is so weird, have a 100 ppl install this game with the same MOD's and you'll probably get 25% different glitches.

[BigWalleye]

My experience has been that SH4 is the most stable of the three games (SH3, SH4, SH5). SH5 is so graphics-intensive that I am likely having problems due to the fact that I have at best a B grade processor, maybe B-. (certainly not top end.) SH3, especially heavily modded, requires careful handling, multi-saving, and a philosophical attitude when my last save goes pear-shape. SH4, on the other hand, seems pretty robust - by comparison. Of course, SH4 also lacks the sophisticated .exe patching of SH3 and SH5, and the load-time file modification of SH3 Commander. Much more potential for things to get corrupted there.

@c13Garrison: In-game CTDs in SH4, as opposed to corrupted saves, are something I don't have much experience with. Please post your mod list and operating environment (HW and OS), and maybe someone will spot a possible source of problems.

[Rockin Robbins]

And my experience of playing since 2007 is that corrupted saves happen. There is no pattern. There is nothing you can do to prevent it happening. I have NEVER deleted a previous save before saving another of the same name. I have NEVER paid any attention to what was going on when I hit the save button. I have even saved with a torpedo on the way to a target.

Every once in awhile I'll get a corrupted save. So I have two save slots: RR Cruise # and RR Cruise #a. I alternate back and forth, testing the last one after I make it. Then I can only lose the time between the saves. If I lose both of them, which has never happened, I can just rejoin when I last left port.

The rule not to change mods except when you are in port is a good one. Some of the mods must be changed in port. Boat skins, missions, HUD mods all can be switched out whenever the fancy strikes you.

Updating mods is chancy. Uninstalling and reinstalling the same mods in the same order is not an issue. Ever. If it does happen it is because your configuration before you uninstalled them was mod soupy and you were not mod soupy after reinstallation. Even then the soup must be in a very few critical areas.

Overall, SH4 is a very stable and quite dependable game, especially in contrast to SH3. However, just like Excel or Word, precautions must be taken because corruption happens sometimes. It is unpredictable. Superstition may make us feel more in control but it's pure fabrication. Our status is unknowing victim. Bend over please.:stare:

[c13Garrison]

I respect your very concisely rendered opinion RR, but the evidence of my computer's performance weighs entirely to the contrary. The longer the mission, the more complicated the tactical situation, the higher the likelihood of video freeze and failures to reload from save.

I was able to restart my game, though I missed 3 days of hell. 18 torps fired off Savo and 16 dead crewmen with only a single DD to show for it. The hellacious depth charging I survived took me 3 Real hours to manage my way out of, and though I have a boat back that is ship-shape in Bristol fashion, it would have been more noteworthy to have the horror back that we survived.

[joefremont]

I have never had any problems saving over existing games. What I have had problems with is when a patrol goes on for a long time. One patrol where I really noticed it was one where I started at Brisbane, sailed up to Guam to refuel and did four or five cycles of sailing out from Guam, using up my torpedoes on a convoy and then returning to Guam for refit. As the patrol went on it longer and longer to save and load the game and finally the saved games would not load at all.

Finally to rescue the campaign I went back to the last good save and then made a beeline back to Brisbane to finish the patrol. Once the patrol cache was flushed it worked normally again.

[Rockin Robbins]

I'll go along with that Joe. Also, it's worse if you save replays. Replays are dependent on mod configuration. If you change mods and then try to run a replay you'll probably CTD. It probably isn't useful to save replays then. That could contribute much to corrupted saves also.

Obviously there is a big difference computer to computer and my experience can be very different from some of you.

If you're having a lot of trouble, you might try a fresh installation of SH4 and all mods. Be sure to pick preserve game settings when you uninstall SH4. I've made a separate write protected directory "SH4 Pristeen" of the stock installation. If I'm corrupted I can just delete the contents of my \Wolves of the Pacific directory, copy all files and directories from \SH4 Pristeen, reinstall JSGME and all mods, restart and I'm ready to go with a guaranteed un-souped SH4. It wouldn't be too difficult to write a batch file to do the whole thing automatically.

[Rockin Robbins]

Alert! Aanker, in another thread brought up a point I had totally forgotten. The SH4 shortcut points to some funky call home and then call the game gu.exe. Change your SH4 shortcut to point to SH4.exe and you will eliminate lots of frustrating game malfunctions.

Ubi issued that instruction a couple of years ago and it's really easy to forget because once you do it you never have to look at it again.

Thanks aanker!:salute:

[Mikemike47]

I don't save for a long while......

And there's a problem right there. I usually save games, never overwrite as other subsimmers have said, an average of 30 minute of actual game play. I am in vastly open ocean at TC 2048 or 4096. If I am being hunted with lots of escorts, or amongst a convoy, then every few minutes.

For overwrites and when I do not want too many games saves, I delete the previously saved filename first that I want to reuse. Then I save the game data with the same filename as the previous overwrite. No corrupted or compromised data that way.

[BigWalleye]

Robbins, you are a respected and experienced member of the SubSim community (kind of a hero of mine, actually) and I hesitate to contradict you. But I must take issue with your post above.

I have NEVER deleted a previous save before saving another of the same name.

Perhaps you should. I have verified this with numerous controlled tests, where I saved a game by overwriting and as a new filename at the same time. The overwritten file gives a significant number of corrupt saves. The new filename gives zero. And I have done the test in reverse order, with similar results. If you doubt it, try the test yourself. It's easy to run and takes little time.

This is not superstition. This is empirical, reproducible data garnered from verifiable experiments.

Except for hardware or operating system failures, I know of no corrupt save problem that exists in either Word or Excel. Software is entirely deterministic. ("Every piece of software does something perfectly and repeatably." - J Gittleman) The corrupt saves in SH4 are neither random nor unpredictable. The necessary and sufficient conditions are not always completely defined. (They could be if we wanted to work hard enough.) But we can certainly bound the problem.

As you wrote, SH4 is a stable and dependable program, unlike SH3. Because of that stability, it is possible to test and isolate the causes of unwanted behaviors, and define dependable workarounds. We do not have to accept elaborate "witchdoctoring" conditions, but we don't have to accept "random behavior" either.

[merc4ulfate]

For those running OM if your CTD it is most likely a mod order. I use OM and never get a CTD. Sometimes I seriously think it is the varying video cards users have in their machines. Not all video cards get called and make calculations the same way. The game itself was never tested in beta on cards it is now being played upon so no one really knows how the code is going to preform given a specific situation and how the game was saved and how large of a gap there was between saves and amount of open information in the AOO during the simulation. This also is affected by your OS and every other piece of hardware called by SH4. Single core, Dual Core, Quad Core, Twin Dual Core, Installtion on the primary OS drive, R/W of the HD and many other factors can cause or inhance issues with software.

I have gone the route of over writing a single save maybe one hundred times and it doesn't get corrupt. I have gone the route of personalizing the name of the file and seeing it doesn't get corrpt. I have also seen both scenarios get trashed. There is no perfect software and as soon as you think it is perfect and install it into a machine with hardware it was never designed to play on it becomes imperfect.

If your running OM then I suggest this be your mod order and leave it alone after you installed it.

Generic Mod Enabler - v2.6.0.157

[Z:\Program Files\silent hunter\MODS] I never install programs on the same drive where my Operating System resides. Your OS shouldn't be sharing space with programs if for no other reason than if your OS craps out all your reinstalling is the OS not 100 other programs and lost data.

If your running OM with OMEGU It MUST BE in this order:

OpsMonsun_V705
OMv705_to_V720
OMv720_Patch5
OMEGU_v300
OMEGU_v300_Patch7

{FROM THIS POINT DOWN THE ORDER IS NOT SO CRITICAL}

OM_Med_Env
OM_Harder_Escort_L2
UBM Missions
Popular German Music From The 30´s

[BigWalleye]

I would not and did not say that any piece of software was "perfect." But, like the man said, every piece of software does something perfectly. Predictably. Reproducibly. Deterministically. (The joke, of course, is that that "something" may be a CTD! But, given the boundary conditions, it will always give the same result, desirable or not.) Your point about variations in hardware environment is valid. But, put the same code in the same environment and provide it with the same data, and it will perform in the same way. Exactly. "Perfectly." It will never make a mistake. It will never do something else. Even a "random number generator" will, if given the same initial conditions and inputs, behave perfectly deterministically. It is in the nature of software. The only way to make the software do something different is to change the inputs or introduce a fault in the hardware. And, in present-day hardware, the probability of a fault is extremely low.