Mission State Save

[BIGNEWY]

Mission State Save Guide


Mission State Save is a new feature that will be particularly enjoyed by those of you with basic mission-editing skills that want to play scenarios you have created and play over several sessions whilst preserving and carrying forward mission progress, without complex scripting. Mission Save works by generating a new mission file at any point during the flight. The generated save mission carries over different parameters of missions such as date/time, all units state and location and other mission state relevant parameters. We’ve also added some support for this feature on a dedicated server level.

We are releasing this feature in an early Work-in-Progress state to gather actual community usage feedback, which will help us refine and prioritise future improvements. We will also be looking at requests from script creators.

Let’s take a look at some details about this feature.

Operation basics

As was mentioned before mission state save result is just a new .miz file which is just new mission file that you can open in the mission editor for adjustments or just play right away. This concept was used by some of our amazing community content creators, and it is our variation of this approach. Mission State Save is available in multiplayer and single player. It does not work with protected paid single player campaigns, for these, a separate solution is needed. There is a new special format of mission file .sav made specifically for dedicated server just to accommodate some automation, we will see its details below.

What is being saved?

Making full identical save is quite hard task if done in environment of sophisticated detailed simulation so to make something usable faster we have opted for approach of saving certain parameters that matter for mission theatre. Here is the list of saved parameters with its nuances:

• Time and date
   
• Dead units/groups and statics removed in save
   
• Position, speed and waypoints state of groups/units saved (they will start at the same position where they were at the moment of save, save  cannot include waypoint advanced parameters for now)
   
• Units/groups and statics that were activated or created with the script during mission also will be present in state save
   
• Spawn points and internal fuel state of player/client units/groups saved and move to air if you save mission while enroute. In saved mission your spawn will be at the position where you left it in the air or on another airfield. Save process will place aircraft at the minimum altitude of 150 meters if they were flying lower at the moment of save.
   
• Player/Client and AI controlled aircraft weapons state is saved (Nuance here is that for now multiple point racks like triple mavericks etc. will be considered used and spent and will be removed from plane loadout in save even if at least one weapon on them is used). Partially used fuel tanks are not accounted for in save as we don’t have partially filled fuel tanks options for aircraft loadout currently.
   
• Aircraft malfunctions are applied at the start of saved mission if there were any at the moment of save. (For this aircraft need to have on demand failures modelled and best example will be A-10C)
   
•  Warehouses state is saved
   
•  All scripts and triggers are saved as they were in the start of original mission. Saving process does not touch them (there can be many scenarios variations for processing these in the save but as of now there is no clear best process logic for it for us yet. For API scripts authors can take it into account and for triggers you can remove not needed triggers manually in mission editor if you think you won’t need them in next session). We will be looking at feedback to potentially adjust this in future.

 

How to use save mission state?

In single player you can find “Save Mission” button in ESC menu:

It will open dialogue window where you can name and choose where to save generated save .miz

Additionally same button is available in the mission debriefing screen (save time will be moment when you have quit the mission):

For Multiplayer Mission State Save will be available only on server side. If you host mission not from dedicated server then as host you will have same “Save Mission” button in ESC menu.

For Dedicated Server there is new button in its web GUI interface “save mission as..” which you can use at any time during mission to save current state.

We have added new mission format for dedicated server: .sav. It serves only one purpose - automation for running mission autosave. .sav is essentially same as .miz, you can even rename it to be .miz and treat it as such. But dedicated server treats .sav differently and difference being “.sav” mission can be autosaved into same file when you stop server or restart mission if dedicated server option “Autosave .sav files on mission stop” is activated. That way you just need to launch same mission in list to continue from the saved state.

The server has a mission list and if you are rotating through missions in list, you may have missions that you want to save automatically and some missions that should not be saved, new “.sav” format helps to differentiate between those. Later we want to add ability to save mission state while mission is running into same file and do not create new one on save for .sav files.
 

 

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/

[BIGNEWY]

Notes:

 We have seen community opinions about Mission State Save feature being somehow connected to Dynamic Campaign. It is not. Dynamic Campaign is perfectly capable of saving itself since the moment of its inception .

Known Issues at the moment of 19.03.2025: 
•    Automatic Mission State save for .sav missions on dedicated server when you stop or restart mission does not take into account clients/players current positions at the moment of save and just returns them at their starting points. Other manual save methods does account positions and save them.
•    While you are inside the simulation there are some hotkey combinations still active even when you are typing file name in dialogue window for the Mission Save file. Avoid using SHIFT+R to write capital R as it will also be read by simulation as a command that by default mapped to mission restart action. Best workaround is to not use capital letters for typing while in the dialogue window during the game.

[virgo47]

1 hour ago, BIGNEWY said:

•    While you are inside the simulation there are some hotkey combinations still active even when you are typing file name in dialogue window for the Mission Save file. Avoid using SHIFT+R to write capital R as it will also be read by simulation as a command that by default mapped to mission restart action. Best workaround is to not use capital letters for typing while in the dialogue window during the game.

This is funny (I'd consider it a bug, as in "extremely unexpected behaviour"), but if I replaced it with RWin+R, I guess I'm safe... right?

EDIT: What other combinations are potentially dangerous? UI layer only?

Edited March 19 by virgo47

[DJOGOO77]

3 ore fa, BIGNEWY ha scritto:

Notes:

 We have seen community opinions about Mission State Save feature being somehow connected to Dynamic Campaign. It is not. Dynamic Campaign is perfectly capable of saving itself since the moment of its inception .

Known Issues at the moment of 19.03.2025: 
•    Automatic Mission State save for .sav missions on dedicated server when you stop or restart mission does not take into account clients/players current positions at the moment of save and just returns them at their starting points. Other manual save methods does account positions and save them.
•    While you are inside the simulation there are some hotkey combinations still active even when you are typing file name in dialogue window for the Mission Save file. Avoid using SHIFT+R to write capital R as it will also be read by simulation as a command that by default mapped to mission restart action. Best workaround is to not use capital letters for typing while in the dialogue window during the game.

Thanks for this great addition.
I wanted to ask you about some server-side specifics.
Will there be options to decide what to save from the 4 states you mentioned in the video (Warehouse | Aircraft state | Vehicle rout location | Units state)?
How will saving with naval assets and static structures behave?
Will it be possible on the server side via DCSServerBot or something else to save a mission after a certain time and automatically start the saved mission?
Many thanks from the DCS ITALIA community.

[lefuneste01]

 

On 3/18/2025 at 3:07 PM, BIGNEWY said:

It does not work with protected paid single player campaigns, for these, a separate solution is needed

This feature is a must have for these campaigns. It would be a game changer, by allowing more complex missions. It should enable people not having  too much time playing these campaign without the current frustration, and so purchase more of them.

Personally, this will be the only context I could use it...

When would it be available ?

[tikijoetots37]

1 minute ago, lefuneste01 said:

 

This feature is a must have for these campaigns. It would be a game changer, by allowing more complex missions. It should enable people not having  too much time playing these campaign without the current frustration, and so purchase more of them.

Personally, this will be the only context I could use it...

When would it be available ?

100% agree, when I first heard about being able to save coming to DCS, this is what I thought it was. I mean it is cool for what it is but we really really need to be able to save for the paid for campaign missions. I've actually never finished one for this very reason. Nothing more deflating than flying for 2 hours, messing up then being forced to fly 2 hours of the same exact thing you just did... 3 to 4 times over and over.

[QbanRambo]

20 minutes ago, tikijoetots37 said:

100% agree, when I first heard about being able to save coming to DCS, this is what I thought it was. I mean it is cool for what it is but we really really need to be able to save for the paid for campaign missions. I've actually never finished one for this very reason. Nothing more deflating than flying for 2 hours, messing up then being forced to fly 2 hours of the same exact thing you just did... 3 to 4 times over and over.

That was the exact reason I stopped buying campaigns. Because it frustrates me to spend almost two hours only for any mistake (or a damn bug in the game) to prevent me from continuing and having to start over.

Here I have the F16 Weasels Over Syria campaign, which I've been waiting for this feature to be able to fly. I'm still not very proficient with the F16, and you add to that the fact that it's a very advanced English language with pilot technicalities (English isn't my primary language, and of course, I'm not a fighter pilot) that make the missions very difficult for me. And I can see that I'm not, and I'll continue with my frustration. Anyway... I won't buy another campaign until this feature is available for them.

[SharpeXB]

5 hours ago, BIGNEWY said:

We have seen community opinions about Mission State Save feature being somehow connected to Dynamic Campaign. It is not. Dynamic Campaign is perfectly capable of saving itself since the moment of its inception

Fantastic!  

Edited March 19 by SharpeXB

[SharpeXB]

Yes although it’s very cool to see progress on this I don’t think it’s what most people expected. This just seems like a limited mission editor feature. What people really want is the ability to save and resume games like DLC campaign missions and such. 

[ChariotOfFLAME]

This looks awesome! My brother an I can now develop and fly our own ongoing coop campaigns together! WOW!

A couple of requests for the next iteration:

• Switchology state saved (each switch in-cockpit's state saved: which MFD screen you were on, the brightness/contrast settings, each knob's state saved, markpoints saved, what mode your TGP was in, what mode your HUD was in and its rejects, Rad vs. Baro Alt, custom altimeter setting, etc... if you can set it/interact with it in the cockpit, it should be saved).
  • Aside: it'd be amazing to have an option in the miz editor, even if its essentially coding a LUA, to be able to set the initial state of every switch, panel, system, etc. in an aircraft for all player/client slots for both single and multiplayer (I know the "Prepare Mission" option exists, but I have heard and experienced mixed results in it sticking for Single Player, and that it doesn't work for Multiplayer. I'd be happy to be corrected, though!)
• For .sav: saving all client/player states, and restoring those client/player locations if they choose the same slot and click spawn within a certain (adjustable) timeframe after .sav mission start. If the client/player does not rejoin within that timeframe, default to point-of-origin. (this all will likely require a menu option for clients that is "resume last flight" to make the UX for this easier and make it so clients/players do not need to find the exact same slot or wrestle with dynamic spawns).
  • next iteration: allow host to choose between point-of-origin, nearest airfield/carrier, or get rid of the timer entirely and allow the clients/players to resume last flight, even if that area is now an unreasonable place to spawn.

I also definitely recommend getting a general consensus from mission makers as to a standard way to handle used/expired/in-progress scripts and triggers and then just starting to go in a direction and letting to community adjust to that choice. If you have to pivot, it would be nice to provide a way to convert the old way to the new way whenever that happens, but I think missions builders would just like the functionality sooner than later. As it is said (and as you are doing with this release!), don't let the pursuit of perfection stand in the way of progress.

Amazing work so far, and thank all the developers for continuing to think outside the box with DCS and not just releasing what you know/are comfortable with and continuing to push this product forward; even if most players take such advances for granted, we are all thankful for them!

Keep up the hard work!

Edited March 19 by ChariotOfFLAME

[Priest]

Without support for advanced waypoint actions this is pretty useless for SP missions any "average" user would build in my opinion.

[dsc106]

Not interested in getting technical with my feedback, because I want what almost everyone else wants:

The ability to simple save and load my game mid mission for paid single player DLC campaigns. Like every other game has.

the ability to set up auto save intervals and for campaign makers to create checkpoints.

I’m sure there are in depth technical reasons why this is harder than it would seem, but at the end of the day, this is sort of a meaningless feature for many of us unless we can pop in and play the very complicated reflected / ground pounder / Baltic campaigns and save and load them. And have it properly track my campaign progress without disruption.

I am hopeful that is coming and this is just a sort of test pilot launch, because it seems like it’s something that was already possible with scripts.

[104th_Money]

As a mission creator/dedicated server host, after waiting for so long to see this feature come to fruition, its frustrating to see it so poorly implemented at start. No static object save, AWACS with orbit times, Carriers with ICLS, ACLS, Link4 as well as any AI unit with advanced waypoint actions wont be saved. I'm not sure which mission creators ED collaborated with to come up with the release features but there is nothing in here but things that will make a comprehensively built mission unusable after saving.

 

[cfrag]

On 3/18/2025 at 3:07 PM, BIGNEWY said:

Mission State Save is a new feature that will be particularly enjoyed by those of you with basic mission-editing skills that want to play scenarios you have created and play over several sessions whilst preserving and carrying forward mission progress, without complex scripting.

I'm happy to see this important new feature make its appearance in DCS, @BIGNEWY, my congratulations to you and the team for this important milestone.

As someone who writes many scripts for missions, and that can't yet take advantage of Mission Save State, I would love to share my own thoughts and ideas with everyone to in improve, and ultimately for ED to bring into DCS Mission Scripting Environment. 

Do you already have a section where I could go to, or do you have a recommendation where I could start a thread in this regard to get the ball rolling?

Thank you and kind regards,

-ch

[draconus]

Thanks for doing the first step but I need a bit more to cosider using the function:

- full aircraft state (switches/sliders/rotaries positions, systems and mfd data, hyd/oil pressure/quantity, wear/damage, INS drift...)

- flag variables data

- resume last action/task/cmd

- all waypoint and adv. waypoint actions

[AVIskrich]

For now I have a bug that part of my units from mission just disappear on the Mission run. 
Ordinary ground units. Artillery, Tanks, Troops. Seems like only SAM units are there in the mission. 

[BIGNEWY]

1 hour ago, cfrag said:

I'm happy to see this important new feature make its appearance in DCS, @BIGNEWY, my congratulations to you and the team for this important milestone.

As someone who writes many scripts for missions, and that can't yet take advantage of Mission Save State, I would love to share my own thoughts and ideas with everyone to in improve, and ultimately for ED to bring into DCS Mission Scripting Environment. 

Do you already have a section where I could go to, or do you have a recommendation where I could start a thread in this regard to get the ball rolling?

Thank you and kind regards,

-ch

Hi, thank you for the feedback. 

If the ideas and request are script and mission save related please do it in this thread. 

If it is just script related the wish list forum section would be the best place. 

We are going to be looking at feedback from this initial save state feature, and adjusting our plans accordingly. 

thank you 

[cfrag]

25 minutes ago, BIGNEWY said:

If the ideas and request are script and mission save related please do it in this thread. 

Will do, thank you BN - this thread it will be

 

[Wait4It]

15 hours ago, SharpeXB said:

Yes although it’s very cool to see progress on this I don’t think it’s what most people expected. This just seems like a limited mission editor feature. What people really want is the ability to save and resume games like DLC campaign missions and such. 

I agree. I was hoping this would be a 'normal' save/load feature like any other game and especially wanted for the longer storybased campaigns.
Is something like that also in the works?

[cfrag]

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)

Spoiler

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?

 

Edited March 20 by cfrag

[BIGNEWY]

thank you for your suggestions I will show the team 

 

[AdrianL]

59 minutes ago, cfrag said:

does not support a scripting API,

Basically a memento pattern implementation https://en.wikipedia.org/wiki/Memento_pattern

[BBK]

Just wanted to say thank you, and this is amazing. It's been a long time coming, but I'm glad there is a lot of progress being made here. I expected the first/test iteration to have more limitations than this. This is great to see. I do want to echo what a lot of others are saying about campaigns though. I assume this is coming (eventually) to those, but that's where I could really use this feature. I can wait until it gets ironed out in missions and multiplayer, but I hope campaigns are prioritized shortly thereafter.

[Wizard_03]

I tried the save feature on a custom mission in the middle of the mission airborne at 30k ft going mach 1 and when I loaded up the save it respawned me on the ground cold and dark at a completely different airfield. What did I do wrong? 

Edited March 20 by Wizard_03

[Galwran]

Thank you for a long waited addition! Seems great so far!

I wish that persistence of destroyed units and buildings is looked into. I'd like to see smoking hulks and destroyed buildings at least on targets sites. A bridge that is cut in one missions should remain cut.  Currently the destroyed units just disappear and buildings get fixed.

I believe that flag values are not currently saved? So transmitting flag information between saves requires a workaround.

The following works for the units:

1)create a small trigger zone TAZO1 just over the specific target unit LAUNCHER1

2)place an identical target unit LAUNCHER2 on the zone TAZO1, on top of the original target unit. Set LAUNCHER2 to late activation

3)Create a trigger Mission start, ALL OF COALITION OUT OF ZONE on the TAZO1 to activate LAUNCHER2 and set a value for a flag L2

4)Trigger an explosion on zone TAZO1 when flag L2 is on and time is more than 5.

So basically the trigger in 3) will be true only if the TAZO1 zone is empty on mission start. This happens only when you destroy the LAUNCHER1, save the game and later load that save. The trigger will "spawn" the LAUNCHER2, which in turn will be exploded five seconds later by 4).

 

I haven't been able to make this work with buildings, yet.