Resume SP mission crashing

[chocolate]

Update April 2008
The problem is with using addon islands.  I patched up to 1.11 and, after reading all the notes here (thanks) I experimented.  I still could not resume, but now my units started floating above the ocean and fell to their deaths.  I copied the mission over to Sahrani island and tried again.  Now I could resume without problems.   I even copied my island addons into the game addons folder, but it made no difference.

Resume/retry only works with BIS supplied islands.   By the way...I was using stock units with no addon units.

Same is true with the new 1.12 beta patch.   I  have not tried on a BIS island with addon units.


--------------
I have been scripting for 5 years, so know how to do it.  This problem stumps me.

I can create missions in the editor that will load and play in SP but always crash to desktop when I hit
the resume button.

Does anybody know a fix for this?   Anybody know why CTD happens on resume?

I have the US version patched to 1.08 with the hotfix applied.  No problems running 'their' built-in missions and resuming. Windows XP HOME fully updated, 2GB RAM, 256 MB video ATI card.

[h-]

Do you use large amount of units and/or a lot of global variables?

Both are known to corrupt the save file and cause CTD.
Should be fixed in the next patch though (no idea when that's due..).

[chocolate]

Thanks for the reply.  Yes, I have a LOT of scripting and units.  I tried just merging the mission to a blank map and running without the scripts -- same result.  The mission file is 139 k, that's all.

That patch is way overdue now.

So, again, thanks for the reply.

[Arkon]

Hi chocolate

This may be of interest to you for your particular problem, but if not it is of general relevance.
Most of the testing was done with our Campaign "The Sahrani Run"

++ Armed Assault bug - commonly known as SAVE GAME BUG? ++

This has caused countless problems for players in the past and for us when trying to debug our Campaign!

Firstly this should be referred to as a "LOAD" bug and not a "SAVE" bug because we've established that there is nothing wrong with the saved files, in our tests at least. That includes all three types of saved files : the autosave, the exit save and the manual save.

There are two scenarios that appear to happen when resuming the campaign after starting the game;

   1) Corruption of Variables, states, AI state etc (who knows what else)
   2) Crash to the desktop on resume
         
The culprit turns out to be some kind of bug that affects a RESUME after the game is fired up. Although one may initially think that the SAVEGAME file itself is corrupted, this is not the case. In our tests the problem does not happen once the saved game is loaded in a particular way:

WORKAROUND for 1)

Run the game, select the campaign, then RESUME. Immediately after it's loaded (error or not) you can either back out to where you will be offered a RESUME again or a RETRY or simply hit escape and choose LOAD (if you made a manual save).


WORKAROUND for 2)

Thankfully crashing doesn't happen that often due to this problem but it DOES happen and when it does it's a big pain because you won't be able to do anything about it other than use the technique we've outlined below for beta testers.

This involves making a copy of your saved files after you exit the game because you will have to restart the campaign and once you do the engine will remove any manual saved files as well as the autosaves.

If however, you've made a copy you can start the campaign, ALT-TAB to windows, Copy your backups into the save folder. Then all you need to do is hit ESC and LOAD. This will allow you to resume and won't crash the game.


THE BOTTOM LINE !!

To Sum up: Never play a resumed campaign after starting Armed Assault. Always get into the habit of reloading after the resume using any one of the 3 saved files. Autosave.ArmASave, continue.ArmASave or save.ArmASave
(We believe that following the above advice is relevant for all misions/campaign's)

We will soon start a thread on our findings when we have concluded our tests

Hope this helps

Regards

Arkon

[Baddo]

Just wait for the next patch is my suggestion. You could end up doing a lot of work to fix a problem BIS has already addressed.

[louiscar]

Do you use large amount of units and/or a lot of global variables?

Both are known to corrupt the save file and cause CTD.
Should be fixed in the next patch though (no idea when that's due..).

Yup as Arkon's message states, it's not a save bug. I've tested this situation several times and discovered that all three save files are perfectly fine. It's definitely something to do with the process of loading immediately after the game has started. If you can get the mission to load or start again and use the saved files, they load ok.

[h-]

Ah, so it's not the same as in OFP then (in OFP the save games got corrupted)..

[louiscar]

It was the natural conclusion especially as the crash or corruption is reliable under the loading conditions.

The curious thing is what is Arma doing in the loading process immediately after start up that is different to loading afterwards. The only thing I can think of is the Map load and caching.

The corruption may or may not be predictable but it's hard to tell exactly what user variables will go missing.

Things like player damage get reset to 0 every time but his kit is intact. Go figure!

#EDIT-removed the unnecessary quote  h-

[LeeHunt]

Though its definitely a bug in the saved game and should be fixed (though they never fixed it in OFP, word of warning); this bug was a bit of a blessing in disguise.  It forced me to write my mission more "efficiently."  Its tempting to use variables all over the place but the bug opened my mind up to new scripting methods and better use of triggers etc.  I ended up making Punishment Battalion much more lag efficient and "cleaner" by eliminating nearly 150 variables (probably only 50 in the 21 MB mission total).  For example, I used "Exploding Triggers" (http://www.ofpec.com/ed_depot/index.php?action=list&game=ArmA&type=tu&cat=xyz) to reduce the need for variables and i also deleted every trigger and object name after it was used.  Just food for thought....

[louiscar]

Code: [Select]

Though its definitely a bug in the saved game and should be fixed (though they never fixed it in OFP, word of warning); this bug was a bit of a blessing in disguise.

It's true I guess, but I do wonder what BIS were doing for 5 years between OFP and ArmA, because so many problems from OFP were carried over. I did have expectations of some great changes but alas ....

Code: [Select]

I used "Exploding Triggers"

Hmmm, I like that idea. I'll take a look at that.