Mission State Save

[AndyJWest]

I posted this in another thread, but I think it bears repeating here:

Given its current limitations, I think it was a serious mistake to add the 'save' option to the menu by default. People who don't obsessively read the forums etc are going to use it, find that it doesn't work remotely they expect, and assume it is bugged. This forum, along with Steam and Reddit, is going to be swamped with 'bug reports' and complaints. The 'save' option should have been added as an option, to be turned on at the players own risk, and clearly marked 'work in progress'.

It is also a very bad idea to offer the existing mission title as the default file name for the new save. People are going to accidentally overwrite existing missions.

[bitboy]

Yeah it sounded and looked ugly when they announced it, IMO ED is using this a beta test for further Dynamic Campaign development.  Not exactly how I would do it. Not even touching for now, needs a lot of work, plus there are already community/author developed means of persistence or saved state that are far better.   

[Mistermann]

1 hour ago, waterman said:

1.  ED should provide some of their short demo missions they tested saved and were happy when restarted.

This is a very good, very reasonable suggestion.  Understanding the intent and documenting use cases for the community would go a long way. 

1 hour ago, waterman said:

2. What quality control testing was done ?

I know ... rhetorical question.  We all know the answer here.  Happy path tested a day an hour before the release.

1 hour ago, waterman said:

3. Maybe we need to lower expectations and just except that they are not capable anymore.

At this point, its our only real choice.  I am just tired of getting gaslighted by the mouthpieces about how much better quality is.  Or shut down because the opinion is counter to their messaging.  

1 hour ago, waterman said:

4. Now you shovel this alpha tested mess out.

"This is not the mess you're looking for ..." -Ben Kenobi

[scommander2]

Hi @cfrag, thanks for info  

[Minsky]

3 hours ago, cfrag said:

Units that were destroyed are removed from the mission, there is (sadly) no debris left in the places where a unit was killed. A bit disappointing, but OK.

It is definitely not OK to me, and I sincerely hope this decision is temporary.

Not only does this kill the sense of progress, but destroyed units often serve as landmarks around which subsequent attacks, or even entire missions, are planned.

I get it that too much debris can lead to degraded performance. (Although, given that the Save feature is currently useless for large-scale or prolonged missions, this should not be our immediate concern.) A basic garbage collector could be run at save, to cull debris older than X hours and/or units that were destroyed X saves prior to this one, once their quantity exceed a certain threshold.

Needless to say that the Dynamic Campaign must support debris persistence from a get go.

[buceador]

3 hours ago, waterman said:

6. Do your self a favour release an update with the new save option removed.

This would seem to be the best solution.

[BIGNEWY]

threads merged. 

please keep all the feedback here for now. 

We are reading the comments and taking notes. Please if you are giving feedback keep it constructive, if you can not please do not post. 

thank you 

[zerO_crash]

This is truly amazing! Finally! Great job ED and all staff!

[BIGNEWY]

Regarding the absolute time less which is currently in seconds, the team will look at changing this. 

[Dangerzone]

Just wondering if anyone can tell me what are the differences/benefits between using this vs DSMC or other existing save scripts such as Ciribobs save scripts?

Is this designed to be an official implementation of existing 3rd party functionality (like the VOIP system seemed to be for SRS - another way of achieving the same thing but simpler for general users and official?), or does it bring something new and not seen before?

Edited March 23 by Dangerzone

[Galwran]

14 hours ago, Minsky said:

It is definitely not OK to me, and I sincerely hope this decision is temporary.

Not only does this kill the sense of progress, but destroyed units often serve as landmarks around which subsequent attacks, or even entire missions, are planned.

I get it that too much debris can lead to degraded performance. (Although, given that the Save feature is currently useless for large-scale or prolonged missions, this should not be our immediate concern.) A basic garbage collector could be run at save, to cull debris older than X hours and/or units that were destroyed X saves prior to this one, once their quantity exceed a certain threshold.

Needless to say that the Dynamic Campaign must support debris persistence from a get go.

I agree. Luckily at least for ”important target units” such as SAM sites this can be fixed pretty easily with scripting. My interim solution is on page 1 or 2 of this same thread.

[gulredrel]

Hello,

appreciate the mission save option. Thanks for adding this to the game.

I almost exclusively use self created mission from ME.

Is there a new forum section regarding the mission save feature (incl. possible bug section)?! I guess this would be nice to have. 

Looks like "takeoff from ground" for inactive group of helicopters is not saved correctly. After saving the mission (regardless of in game or from the debriefing screen) the units now have been transfered to a helibase with "takeoff from ramp" command.
Please find original mission, and both saved missions attached.

Thanks

F-4E_Paphos_Training_Nikosia Airport_target_airstart_save_debrief.miz F-4E_Paphos_Training_Nikosia Airport_target_airstart_save.miz F-4E_Paphos_Training_Nikosia Airport_target_airstart.miz 20250323_F-4_save_test_destroyed_objects.trk

Edited March 23 by gulredrel
added image

[waterman]

 

Thanks looking into the Absolute Time More - Less issue that is a good start.

If you are going to insist on keeping this booby trap on the DCS Menus please read and do this -

DCS Needs To Provide Some Working Examples.

" Please include a simple Example using a user placed Train "

Its not a big ask and it is constructive.

More important its the right thing to do.

So we need missions before and after the save.

I can spend all week alpha testing this thing creating missions and testing them and posting the results.

I did that with the Train Problems with MT ages ago and was totally ignored no one even bothered downloading and looking at them.

Just fix them please its a sore that never heals otherwise.

Please DCS you need To Provide Some Working Examples in this before and after format -

Original_Test1.miz    and   Saved_Test1.miz

Original_Test2.miz    and   Saved_Test2.miz

Original_Test3.miz    and   Saved_Test3.miz

Original_Test4.miz    and   Saved_Test4.miz

" Sorry but it is like sitting down to play poker you have to show you have the money first "

De-encrypted that sort of means Show us it Works before we invest time and effort alpha testing on your behalf.

Please DCS Just Provide Some Working Examples you used .

 

Edited March 23 by waterman

[FupDuck]

Thanks for releasing this so we could test it. I've done some testing myself, and found many of the same things as cfrag in his post on page 2.

 

Since you are asking for feedback, my biggest ask would be the ability to save paid campaign missions. And I guess the ability to save a bit more info, like aircraft settings, munitions states, and special waypoint actions. Because without that stuff, not enough of the campaign info will get saved to make the save accurate enough to continue.

 

Thanks and good luck with future development on this!

[BIGNEWY]

6 minutes ago, FupDuck said:

Since you are asking for feedback, my biggest ask would be the ability to save paid campaign missions. And I guess the ability to save a bit more info, like aircraft settings, munitions states, and special waypoint actions. Because without that stuff, not enough of the campaign info will get saved to make the save accurate enough to continue.

Paid campaigns would require a slightly different approach, obviously the campaign creator would have to design the campaign with the save state in mind, or add check point saves like the Rising squall campaign has. Many campaigns are story driven so there are lots of things to be considered. 

 

Keep the feedback coming everyone we are taking notes and what we have seen so far is helpful. 

 

[GWdope]

Things that I believe as a mission creator should or must be included in the save state to utilize this feature to its full potential:

Scenery/Map object destruction state (map objects cannot be used as targets otherwise.)

Dead unit carcasses/creators (allows continuity of environment)  

Flag state (perhaps an option to make a flags state savable or not? without this many randomization functions cannot be persistent)

Save inhibit/allow mechanism (a way to create a "Checkpoint" in a mission where saving is allowed or automatic, this would allow mission makers to have more control and avoid issues.)

Automatic save file naming and location with link to original mission (this is a QoL feature that will make things easier for the end user. Perhaps a way to link an auto generated save file to the original mission so if a user starts the original mission they can chose the saved file or to start over. Basically how saving works in all video games.)

 

  

[draconus]

19 hours ago, BIGNEWY said:

Paid campaigns would require a slightly different approach, obviously the campaign creator would have to design the campaign with the save state in mind, or add check point saves like the Rising squall campaign has.

The whole save game should have a different approach from the start. Don't create new mission. Just save enough data in a new file that linked with original mission runs it again with the saved changes. That way campaign's protected files don't have to be changed or copied. Same with added mission content like sounds, pictures or liveries - they all stay with the original mission file. Adding checkpoints is not an answer because it already works and it's not a save game. Saving as a new mission could be an option, not main feature.

[GrEaSeLiTeNiN]

I understand it's WIP and very basic at the moment to the point it's not very useful at this stage and could mislead some (who don't read the forums) to think it will save what they think it will save. Just another example, I tried a quick simple test mission - Triggered states weren't saved. Last player plane position was saved but not its altitude or cockpit setup. 

[waterman]

After the Hot Fix Update - 

Absolute Time More  and Absolute Time Less are Great now.

Input is in   Hours : Minutes : Seconds and it auto converts to total seconds.

Nice one thanks .

[BIGNEWY]

1 minute ago, waterman said:

After the Hot Fix Update - 

Absolute Time More  and Absolute Time Less are Great now.

Input is in   Hours : Minutes : Seconds and it auto converts to total seconds.

Nice one thanks .

Good to hear thanks for the feedback

[cfrag]

18 minutes ago, BIGNEWY said:

Good to hear thanks for the feedback

Thanks for the hotfix @BIGNEWY, I believe that this can help a lot. I think that there's a small glitch in the interface: when there are ABSOLUTE TIME conditions in a mission, and the mission creator changes the mission's start time, it seems that these conditions are automatically updated - but at least their name's aren't (you need to click on each and every condition to have it updated). I'm not sure if this is required before save; I *may* have seen some not-updated ABSOLUTE TIME conditions after saving and reloading that lost their update, but I'm not sure.

In any event, if the ABSOLUTE TIME conditions all update immediately including title, I think that that removes all doubt.  

Edited March 26 by cfrag

[BIGNEWY]

48 minutes ago, cfrag said:

Thanks for the hotfix @BIGNEWY, I believe that this can help a lot. I think that there's a small glitch in the interface: when there are ABSOLUTE TIME conditions in a mission, and the mission creator changes the mission's start time, it seems that these conditions are automatically updated - but at least their name's aren't (you need to click on each and every condition to have it updated). I'm not sure if this is required before save; I *may* have seen some not-updated ABSOLUTE TIME conditions after saving and reloading that lost their update, but I'm not sure.

In any event, if the ABSOLUTE TIME conditions all update immediately including title, I think that that removes all doubt.  

For clarity can you show an example of this, not entirely sure it is a glitch.

[cfrag]

49 minutes ago, BIGNEWY said:

For clarity can you show an example of this, not entirely sure it is a glitch.

Original Condition, mission starts at 0800 on June 

Condition uses multiple conditions at same time just for clarity 

This is the condition, to start at time(0),converted to 08:00 

Changed mission start time to 09:00

Looking at the conditions: NO CHANGE

Clicking on the first condition: updates to 0900 (32400), while the others remain unchanged to now one hour before mission starts. That seems wrong to me.

 

Ignore the images that follow, for some reasons the are just there .

Edited March 26 by cfrag

[BIGNEWY]

32 minutes ago, cfrag said:

Original Condition, mission starts at 0800 on June 

Condition uses multiple conditions at same time just for clarity 

This is the condition, to start at time(0),converted to 08:00 

Changed mission start time to 09:00

Looking at the conditions: NO CHANGE

Clicking on the first condition: updates to 0900 (32400), while the others remain unchanged to now one hour before mission starts. That seems wrong to me.

 

Ignore the images that follow, for some reasons the are just there .

Thank you, 

I've spoken to the team, maybe there is some misunderstanding of how it works but it is working as intended, starting point of absolute time is 00 h 00 min of the mission start date, not the mission start time. 

thank you 

[cfrag]

10 minutes ago, BIGNEWY said:

I've spoken to the team, maybe there is some misunderstanding of how it works but it is working as intended, starting point of absolute time is 00 h 00 min of the mission start date, not the mission start time. 

Understood. What is the intended functionality if you set the starting point at 08:00:10 (ten seconds after mission start at 08:00:00) and then advance the mission start date by 1 hour? ME does do something to the conditions, and what it does seems not consistent.

Phrased differently: what is the intended functionality given:

• you set an absolute time condition that happens to be 10 seconds after mission start time
• you then move mission start time forward by one hour (e.g. from 0800 to 0900)
• Are absolute time trigger conditions updated, and if yes, when and how?

I assume that there is some intended functionality to auto-update ABSOLUTE TIME conditions, else they are just marginally less useless than the pure absolute time we have now. Mission designers need their conditions to trigger relative to mission start time. I believe everyone agrees that no automatic management of ABSOLUTE TIME condition with respect to changing mission start time wouldn't be helpful at all. I believe it's obvious that mission designers need some QoL management with their trigger time condition, hence the somewhat quirky, non-standard way that ME behaves now when you click on an ABSOLUTE TIME condition now after a change in mission start time, and it auto-updates that (and only that) time by the amount of time that the mission start time was moved. The idea looks good, the execution looks flawed.

Edited March 26 by cfrag