Mission State Save

[waterman]

Hi its time to reveal Another Absolute Time more trigger booby trap ?

Take a deep breath !

 

I just did 4 very simple experiments using the Absolute Time more trigger.

Default Caucasus Map and no Mods are used.

Note - these .miz files are saved using the original Mission editor Save as method.

.miz Files are all attached have fun.

 

- Absolute Time More Trigger 1.miz

1. If you set the mission start time at 8.00am

2. I set a unit ( Car Daimlar Armered ) to late activation "It is "not" set to visable before activation''

3. Activate unit with an Absolute Time more Trigger at 8.01 am

4. run mission and unit appears at 8.01 am as expected.

------

- Absolute Time More Trigger 2.miz

5. now i changed mission start time to 9.0 am

6. Absolute Time More trigger remains at 8.01 am

7. Run the mission and the unit is activated before mission start time and is working in the game.

------

- Absolute Time More Trigger 3.miz

8.  now i clicked on the Absolute time More conditions and the units time defaults to 9.0 am mission start time ( does not reset it to 9.01 am )

9. Run the mission and unit appears at mission start time 9.0 am it has not added the extra 1 minute you set earlier .

-----

- Absolute Time More Trigger 4.miz

10. I changed Absolute time More condition to 9.01 am

11. Run the mission and unit appears at 9.01 am as expected.

-----

12. An interesting thing is it will use the old trigger time you set when you increase the Mission start time - but will not let you type in a time that is before the actual mission start time.

Hope this helps DCS with the developement process.

Absolute Time More Trigger 1.miz Absolute Time More Trigger 2.miz Absolute Time More Trigger 3.miz Absolute Time More Trigger 4.miz

Edited March 27 by waterman

[evanf117]

(Bug) helicopters set to uncontrolled or client and set to take off from ground cold or hot change location once a mission is saved to the nearest airport parking. making alot of missions unplayable after save

(missing feature) destroyed vehicle's are removed when saving mission. they should be replaced with a static set to the dead state, other wise missions feel empty once units are killed and then the mission is saved and re-loaded

save test Track.trk
Save Test.mizSave Test out.miz

[BIGNEWY]

On 3/21/2025 at 11:48 AM, GameOver said:

That’s great news that we now have a save and load option in DCS—well done! However, like many other users, I’m really looking forward to a fully functional Save and Load system.

Ideally, this would work like a traditional save feature: I fly a mission where I need to destroy multiple targets. I destroy one, but I need to stop playing, so I save the game, turn off my PC, and later, when I return to DCS, I simply go to a Load Game option, select my saved mission, and continue exactly from where I left off.

This should work for any mission or campaign in DCS, not just specific scenarios. There should also be a dedicated Load Game tab or icon on the main screen for easy access.

Additionally, we should be able to create multiple saves, such as:

• One save for my F/A-18C mission in Arctic Thunder
• Another for my F/A-18C in Flaming Sunrise
• A third for my AH-64D Outpost mission
• A fourth for my F-16C in Last Out, etc.

That way, we can easily return to any saved mission whenever we want.

I know others have likely shared similar thoughts, but I hope this feedback helps ED in developing a great Save and Load feature for DCS!

Thank you for your feedback GameOver, we are looking at the comments here in the thread and will make a plan going forward, hopefully we can tweak it some more, however it may not be possible to have a full save of everything, in DCS there are simply to many moving parts, and it may not be achievable.  

[BIGNEWY]

On 3/21/2025 at 7:15 PM, cb1968 said:

After a cold start of the F4, I saved the game after I had started taxiing. Reloading the save file reset the mission to the beginning of the cold start. Is this expected?

Yes expected, after take off it would save you in the air. 

thank you 

[BIGNEWY]

On 3/23/2025 at 12:31 PM, gulredrel said:

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 28.11 kB · 6 downloads F-4E_Paphos_Training_Nikosia Airport_target_airstart_save.miz 28.12 kB · 5 downloads F-4E_Paphos_Training_Nikosia Airport_target_airstart.miz 29.82 kB · 5 downloads 20250323_F-4_save_test_destroyed_objects.trk 1.06 MB · 5 downloads

Thank you for the good info, a report has been made for the team to investigate

[BIGNEWY]

On 3/20/2025 at 1:00 PM, cfrag said:

Simple State Saving Scripting API - A PROPOSAL

Hi all, as suggested by @BIGNEWY I will put this proposal into this thread for us all to discuss:

With the advent of Mission State Save in DCS, we now have a jumping-off point for mission scripts to persist their data without the requirement of "De-Sanitizing" DCS. This could potentially greatly increase the scope of missions and enhance single- and multiplayer game experiences. 

The current (new) Mission State Save feature does not support a scripting API, and I would like to submit a first draft of an API for everyone to comment on, and (hopefully) ED to implement in a later version.

MISSION STATE SAVING SCRIPTING API
The goal of this API is to allow script authors to interface with, and harness DCS' new Mission State Save feature. Using this API, a script author can serialize a script's current state, and then use the API to persist the script's state into the saved mission. Note that for this simple API, script state de-/serialisation is entirely left to the script author, and they should use existing methods (e.g. net.lua2json() and others) to save and recover a script's state before invoking the state saving methods. 

So, how could this work? I propose the following as a first attempt:

HOW TO SAVE A STATE
DCS sends out a new Event "STARTSAVE" which is invoked whenever DCS gathers data in preparation for persisting the mission. So every time that a mission's state is saved, the STARTSAVE event is passed to all subscribed scripts to allow them to collect, and store, data into a special location that is stored with the saved mission. Scrips can sign up to receive this event by subscribing via world.addEventHandler(luaTableName)

When the Event Handler is invoked by DCS, it passes an Event record with the invocation that contains at least the following data 

Event = {
    id = STARTSAVE -- value tbd, ED's choice
} 

The attribute Event.id holds a constant that identifies this as a STARTSAVE event, and this constant is to be defined by ED as part of the new API 

This event can be invoked at any time, and it is invoked once during every mission state save process. 

Should a script receive the event, it can encode ("serialize") it's current state (i.e. all information that is required to restore the script to it's current state) and then use the new state singleton's methods to add its state information to the mission information. Please see the example below for details.

THE PROPOSED NEW STATE SINGLETON
A new state singleton in Mission Scripting Environment provides simple, limited methods to allow a script to add its relevant information to the mission's state for saving. It also provides the means for retrieving a script's information (e.g. to set a script's state on startup). Currently, I propose the following methods:

function state.setState(string name, string state)
This puts the string state's value (a string) into the currently running mission's state information dictionary under index name. If there already is information saved under that name, that value is replaced by the new state. if you omit or pass NIL as state value, the state information for name is removed. If you pass NIL as name, nothing happens.

string state.getState(string name)
This retrieves a state saved in the mission's state information dictionary under the index name, and returns it as result. If there is no information saved under that name, it returns NIL. If you omit or pass NIL as name, the method returns NIL.
A mission script would invoke this method once, when the script starts up.

SCRIPT STATE SAVING IN ACTION (EXAMPLE)
Let's look at the simplistic scrip 'myscript' that keeps track of a player's number of landings in myscript.landings and number of kills in myscript.kills. We are only focusing on the script's state saving and restoring abilities.

THE SCRIPT (hidden for brevity)

  Reveal hidden contents

myscript = {} -- saves 'landings' and 'kills' to savestate
-- init vars
myscript.landings = 0
myscript.kills = 0

-- event handler 
function myscript:onEvent(event)
    if event.id == STARTSAVE then 
        myscript.saveState()
    end
end

-- saving state 
function myscript.saveState()
    -- we want to 'serialize' the important variables of this script
    local data = {}
    data.landings = myscript.landings
    data.kills = myscript.kills

    -- now we have all important info in 'data', let's make a string 
    -- out of it (use the word "encode" or "serialize" when you want to 
    -- to sound important.
    local sData = net.lua2json(data) -- magic!
    
    -- save it to the mission's state 
    state.setState("myscript", sData)
end

-- restoring state 
function myscript.restoreState()
    -- see if my state was saved previously 
    local sData = state.getState("myscript") -- ask the state 
    if sData then 
        local data = net.json2lua(sData) -- more magic!
        myscript.kills = data.kills -- copy back important values
        myscript.landings = data.landings
    end 
end

-- the remainder is run when the script executes for the first time. 

-- say hi 
trigger.action.outText("hi. I'm about to restore my state", 30)

-- restore any state 
myscript.restoreState() 

-- subscribe to events 
world.addEventHandler(myscript)

-- and we are up and running 

HOW IT WORKS
The script loads and executes via DOSCRIPT action. It first initilizes the state variables 'landings' and 'kills' to 0.
Next, it says "hi..." via outText() so we know that the script is being invoked (merely debugging info)

    trigger.action.outText("hi. I'm about to restore my state", 30)

Then, the script invokes myscript.restoreState()
Here, it looks if any information is available to restore a past state. 

    local sData = state.getState("myscript") -- ask the state 

If the mission that is currently running is a saved mission, information is available, and state.getState() returns a non-nil value to sData.

If sData is non-nil, the method invokes net.json2lua() to convert sData (which contains serialized data from the saved mission) into the value for data. 

    if sData then 
        local data = net.json2lua(sData) -- more magic!

We then retrieve the values for the script's kills and landings state variables.

        myscript.kills = data.kills -- copy back important values
        myscript.landings = data.landings

Finally, we subscribe to DCS' event mechanism to be invoked for world events, and relinquish control back to the mission.

    world.addEventHandler(myscript)

LATER DURING the mission, the player saves the game, and this in turn causes DCS to invoke the event handler myscript.OnEvent() with the id field of the event record holding the value STARTSAVE. In that case, the event handler invokes myscript.saveState()

    if event.id == STARTSAVE then 
        myscript.saveState()
    end

in saveState(), we collect all relevant state variables (here the values for myscript.landings and myscript.kills) into a single table called 'data'. 

    local data = {}
    data.landings = myscript.landings
    data.kills = myscript.kills

Once we have collected all relevant datat (i.e. data that we want to save), we use net.lua2json to convert the Lua table 'data' into a simple string. 

    local sData = net.lua2json(data) -- magic!

We save that string into the mission's state by invoking state.setState() with "myscript" as index name, and the to-string-converted data as 

    state.setState("myscript", sData)

Aaaaand that's all, folx! With this simple addition to MSE most script authors could add simple state saving to the majority of their scripts. The proposal utilizes a new event ID (STARTSAVE) and a new singleton state for all actions, which hopefully will allow most script authors to quickly add state saving ability by adopting above pattern. Using lua2json and json2lua is a bit geeky, but since ED has removed two known bugs inside those methods, they should be safe for 99% of scripts.

FURTHER ENHANCEMENTS 
I submit an enhancement for DCS missions that can allow safely writing and retrieving arbitrary text (a string) information similar to state.setState() and state.getState(), except that it works in a global context (i.e. it is part of DCS, not just the mission). Using this global set/get method, missions can collaboratively share data using shared names. The onus of ensuring that there are no conflicting names is on the script author.

function state.setGlobalState(string name, string state)
This puts the string state (a string) into the DCS-GLOBAL state information dictionary under index name. If there already is information saved under that name, that value is replaced by the new state. if you pass NIL as state, the state information for name is removed. If you pass NIL as name, nothing happens.

string state.getGlobalState(string name)
This retrieves the state saved from the DCS-GLOBAL state information dictionary under the index name, and returns it as result. If there is no information saved under that name, it returns NIL. If you pass NIL as name, the method returns NIL.

table of string state.GetGlobalStates()
Returns a table of all names that are currently valid indexes into the GLOBAL (shared) DCS state dictionary. 

YOUR THOUGHTS?
That's already my entire proposal for an initial, simple scripting support of mission state save. It relies on the script author to be able to determine and encode/serialize the script's state, and requires only minimal support from DCS. I assert (without proof  ) that providing this kind of simple support removes any requirement for de-sanitizing DCS and still provide 99.9% simple script persistence. By adding GLOBAL state support, DCS could also provide a shared, collaborative context for script authors to share and retrieve states across missions.

What do you think about this?

 

Thank you Cfrag, 

we have noted your feedback internally in a report and we will look at the possibilities. 

 

[iskander3449]

Good system working good for me but i have some small suggestion to enchance the mission state save

Save destroyed uni/Static :  could be very good make respawn a destroyed as wreckage , instead of just make them dispawn. would give so much more live in scenario

Save destroyed Building : Quite explicit

Save Craters and other sign of combat

Save game log : keep showing in the log tab casuality of both side and keep the history of your  air/ground victory

Thank ED for your work !

Edited March 29 by iskander3449

[Draken35]

First of all, thank you for this feature! It might seem like a premature release and not that useful currently, but I see it like an opportunity for the community to help guide its development, specially since we don't have the Open Beta anymore.

I did not pay much attention to it because of the current limitations, but, yesterday, at the end of a 2 hours MP session in a sandbox that contains manually placed and dynamically generated ground units, we were talking about the save feature and I decide to save the mission and take a look just out of curiosity...

Well, I just did and I am (pleasantly) surprised that the dynamically generated units (using Moose in this case) were saved! Now, the sad part is that they did not keep the name used when generated but a generic "vehicle1-##".  I think, that if the dynamically spawned units were to be saved with their proper names it would be a big win for the scripting community. 

(Names are important since they contain prefixes that are used in the scripts to setup thinks like IADS and EWR networks)

 

[hreich]

How do u use mission save state ? Are there any tips how to best use this feature to have some sort of continuing campaign/operation, that i can jump in /out and then play again when time permits...Would this be usable in a mission cretaed by for example DCS liberation / retribution style of campaign?

[draconus]

32 minutes ago, hreich said:

How do u use mission save state ? Are there any tips how to best use this feature to have some sort of continuing campaign/operation, that i can jump in /out and then play again when time permits...Would this be usable in a mission cretaed by for example DCS liberation / retribution style of campaign?

Read the OP:

No, it won't work with campaigns or any missions apart from simplest and basic setups currently.

[cfrag]

23 minutes ago, hreich said:

Are there any tips how to best use this feature to have some sort of continuing campaign/operation, that i can jump in /out and then play again when time permits

That may be a future ambition of state save, it is currently very far removed from that ability. The current version to me appears immature, rough and incomplete. I'm not sure if it will ever support save/continue for individual flights, we are waiting for ED to announce planned capabilities. At this moment, my experience with save state has not been positive, so I will withhold further comment, except that you should make very, very sure that when saving a state you do not accidentally overwrite your original mission (currently it is the default, be careful). 

[hreich]

Shame...I think the release of next version of another simulation will sway me away from DCS, if this save state function doesn't upgrade itself ASAP...

And one other question coming to my mind...if i save a mission state with carrier, and advanced waypoint options are not saved, so for example carrier TCN and ILS information is also not saved? What about radio ATC freq - is that saved? 

Edited April 1 by hreich

[draconus]

On 3/22/2025 at 2:53 PM, AndyJWest said:

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.

It already started:

[_JMax]

Well the "Save Mission" addition is an exciting feature that was hoping would make DCS more playable/practical. The biggest buzz-kill in the game is investing the time in a mission,then having to start all over again on the bits you have gotten through already multiple times.The "Save Mission" button is missing the "Save Mission" part.

But I am glad that this seems to be recognized as a must for the future of the game.I am pretty confident the programmers will figure it out so that when you click "Save Mission",that is just what it does.DCS must be far more complicated than other games... In fact I cant imagine not having a save game feature in other games.

[Galwran]

The AI "forgetting" the previous waypoints is a real bummer.

For example, we have se a simple patrol route: WP1->WP2->WP3 and then switch to WP1. So the AI will start the route again after WP3 and will keep doing the loop until RTB.

If I save after the AI has passed WP1 and then load the game, there original WP1 will not be there. Instead the route will now start at old WP2 and the looping route will be different.

I think that the original WP1 location should be saved, (maybe as a different variable?), but so that the routing still works.

[cfrag]

27 minutes ago, Galwran said:

If I save after the AI has passed WP1 and then load the game, there original WP1 will not be there.

You will also find that any options you set at WP1 (for example ROE weapons hold) are gone, so upon reload the AI can behave entirely different. In effect, this is NOT a save state.

What we have looks to me like a cheap leveraging of existing, decades old tech: take a snapshot of the current mission, and use Mission Editor's save module to encode that snapshot as a miz file. It fails 99% of all relevant points that a player would expect a save state to have. I would call this a good 5% start of the "real" thing. Hopefully ED agrees.

 

[BIGNEWY]

 

In the next patch we will be introducing an API based on your feedback and our own design process. 

The below text has been added to the first post also.

 

New Scripting API:

---

world.getPersistenceData(name)

Read persistence data identified by name.
Returns Lua-value stored in this miz/sav by a given name or nil if no value found.
Name MUST ONLY consist of the following characters: [a-zA-Z0-9_ -], that is Latin alphabet, numbers, space, underscore and dash.

This API is to be used in the initialization part of the script.
During mission it will always return data stored in the original miz/sav, data is updated ONLY after simulation finishes.
See world.setPersistenceHandler(name, handler) for further details.

---

world.setPersistenceHandler(name, handler)

Registers a handler for generating persistent data when saving simulation state.
Name MUST conform to the same restriction described above.
Handler MUST be a Lua-function which takes no arguments and returns persistent data as a Lua-value (boolean, number, string, table).
The returned value must be JSON-serializable.

The handler will be called every time the simulation state is being saved.
Note, that saving a state during mission run-time DOES NOT update the values returned by world.getPersistenceData(name) - these will continue to return persistence data as it was on the start of this simulation.
This is done in order to avoid state saving to influence the simulation.

---

Important note about the API: the use of names as keys for persistent data allows scripts to read data from any name they know. This is intentional to support cases where some scripts and frameworks might support data saved by other scripts and frameworks. Defining common names and data formats left up to framework authors.

---

Storage format:

Inside .miz/.sav the persistence data is stored as persistence/<name>.json files.

Source: https://www.digitalcombatsimulator.com/en/support/faq/scripting_engine/ ( will be updated after next patch )


Thank you 

[cfrag]

4 minutes ago, BIGNEWY said:

In the next patch we will be introducing an API

Great news - thank you, @BIGNEWY

[BIGNEWY]

Just now, cfrag said:

Great news - thank you, @BIGNEWY

You are welcome, thank you for your initial feedback in the thread. 

[Racoon-1-1]

@BIGNEWY

This is feature is going in the right direction and I know it's still WIP.

But considering that it aims for larger, more complex missions imo it would be pretty important that all flags and the advanced waypoint options are saved correctly, too. Otherwise sadly this whole thing is pretty useless.

Even worse, those who don't read the forums will figure out that all their save games doen't work as they think they do so this will definitely also cause some frustration. At least you should label "Save Game" as highly experimental.

 

Edited April 16 by Racoon-1-1

[BIGNEWY]

On 4/16/2025 at 11:38 AM, Racoon-1-1 said:

@BIGNEWY

This is feature is going in the right direction and I know it's still WIP.

But considering that it aims for larger, more complex missions imo it would be pretty important that all flags and the advanced waypoint options are saved correctly, too. Otherwise sadly this whole thing is pretty useless.

Even worse, those who don't read the forums will figure out that all their save games doen't work as they think they do so this will definitely also cause some frustration. At least you should label "Save Game" as highly experimental.

 

I do not agree with your assessment, but lets not have a debate here. As you can already tell we have been working hard on this and already adding the API features. 

thank you 

[BIGNEWY]

Just to update you all on our next steps after the API we will be tackling dead unit shack saving and waypoint parameters. 

thank you 

[Racoon-1-1]

vor einer Stunde schrieb BIGNEWY:

I do not agree with your assessment, but lets not have a debate here. As you can already tell we have been working hard on this and already adding the API features. 

thank you 

Sorry, I did not intend to make it sound too negatively.

"This is feature is going in the right direction and I know it's still WIP." <-- I meant this honestly, and I am pretty sure it is very hard work to implement such a feature into complex game like DCS!

 

[BIGNEWY]

42 minutes ago, Racoon-1-1 said:

Sorry, I did not intend to make it sound too negatively.

"This is feature is going in the right direction and I know it's still WIP." <-- I meant this honestly, and I am pretty sure it is very hard work to implement such a feature into complex game like DCS!

 

No worries, just felt I needed to push back gently

[ops]

Hey

the new save handler is great already!

It also allows for a few workarounds with dynamic spawns, and own script data.

However, following things would really help a lot:

 

Everything based on flags breaks currently

-> save flag values/times in the mission, and reapply them on start (they are already saved in the debrief.log)

(could reapply them in a custom save handler, but we don't have access to set the flag time)

 

Dynamic spawned players are saved as NPC

-> don't save units with IDs > 1000000 (dynamic player spawns)

(could keep track and destroy on mission start, but it looks like a bug)

 

Dynamic spawned NPCs lose their names

-> save unit and group names of dynamic spawned units (currently they are named to "vehicle1" etc)

(own saving not possible as we don't get access to current task data)