The upcoming "Mission State Save" feature

[cfrag]

Dear @NineLine, @BIGNEWY and kind staff at ED,

   it is with great joy that I read about the upcoming "Mission State Save" feature in your March 7, 2025 newsletter. As someone with a vested interest in this feature put to good use (I have authored a bunch of missions, some of which seem moderately popular) and taken advantage of to make missions even better, I'd love to contribute my 2 cents if this is possible. Do you have anyone or location where people can contribute ideas, review drafts, or provide feedback of any kind?

When it comes to saving state, I'm truly interested if and how this would be reflected in DCS's mission scripting API, so mission/script authors (I regard myself as the latter) can ensure a smooth transition to the new feature. I'm sure that ED have their well-versed community contacts for this, I'm merely asking if and where people may contribute. For example, I think that it would help if MSE API introduced two events: 

• saveState - this event would be invoked whenever DCS wants to save state, and allows scripts to do their own thing. This could be invoked at any time
• restoreState - this event would only be invoked once, at mission (re-)start, before mission time starts (and perhaps immediately after a script invokes 'world.addEventHandler) to allow scripts to resume any state that they saved with saveState

Ideally there would be some other events like (startSave, endSave, startRestore, endRestore), but I think above two could help smoothen the transition. 

Also, in order to facilitate transition to saving state without missions having to 'de-sanitize' DCS, I believe we could greatly benefit if the save state feature (a singleton "state" perhaps) featured simple getter and setter methods for named text, e.g.

• saveState.putText(name, content) - puts the text content under the name 'name' into the save state that will be saved with the rest of the state, overwriting any existing previous content of that same name
• string saveState.getText(name) - returns the text put in the saveState under name 'name'. If no text was saved, returns nil. 

This simple mechanism should allow most script authors to save and retrieve their 'script' state along with the rest of the 'real' mission state, and be compatible with a fully sanitized environment. Of course, having a shared state where scripts can write to and read from would be the icing on the cake (allowing a fully sandboxed mission still to share data with other missions).

Above are merely the uninformed ruminations of a well-meaning, highly interested DCS enthusiast. So if there is some place where you would welcome further input/ideas, I'd be happy to contribute.

Kind regards, and I'm looking forward to the new Mission State Save,

-ch

 

[BIGNEWY]

Hey thank you for the feedback I will pass it on to the team with your ideas / requests. 

I think initially the save game feature is mainly for people who don't want to mess with scripts or API's. Once we have it released into the public I am sure you folks will all take a closer look at it and give us more feedback and ideas to think about. 

best regards

bignewy

[cfrag]

1 hour ago, BIGNEWY said:

I think initially the save game feature is mainly for people who don't want to mess with scripts or API's.

Understood, and thank you for looking into this, BN. That being said, most players don’t strike me as the kind of people who are interested in the difference. When they play a miz, they may likely expect the save state function to work, irrespective of the fact that a designer used a script or not. If they used a script, the miz is likely not compatible with restore. That may lead to some rough experience for your players, as „don’t use missions from userfiles with scripts“ seems a hard sell if you want to make userfiles more popular.

We‘ll see how this turns out, I fully trust ED’s strategy on this.

Edited March 8 by cfrag

[AdrianL]

The vast majority of server missions, supplied missions with 3rd party planes, campaigns and 'user file' missions all make extensive use of scripts.

So not taking scripts into account will make this functionality extremely limited 

[Mistermann]

On 3/8/2025 at 10:22 AM, AdrianL said:

The vast majority of server missions, supplied missions with 3rd party planes, campaigns and 'user file' missions all make extensive use of scripts.

So not taking scripts into account will make this functionality extremely limited 

Agree with both you and cfrag.  I'll also add that my main use case for this is/was sp campaigns.  Hearing this save feature won't work with them and now seeing it isn't designed for scripts is extremely disappointing.  

[BIGNEWY]

It is impossible to take every script into account, there can be so many combinations of scripts. But the save will not touch any scripts, if the scripts are in the mission they will be included in the save and be in the generated mission from the save.

As for request of the OP (cfrag) we will look at the functions requested, I think it is logical for us to see this getting public first and then accommodate some simple functions that we will collect with feedback as OP wrote himself it is only his guesses for now so until feature is release and its details seen we can't really expect precise requests now.

thank you