cfrag

Thank you @Penfold-88 - some analysis showed some missing explanation in the manual: radioMainMenu and attached radioMenus must have the same access restrictions (e.g. coalition: blue) else the main menu can't be found and the menu attaches erratically.

At first blush, all seems to be fine. Please verify that you are using the newest versions of the modules. If that doesn’t help, post or send this (or a simplified version of the miz, no mods please) via PM, and I’m sure we can have 5his resolved quickly.

Thank you for that report. I'm not sure that there is anything I can do (CA isn't well integrated into DCS) but I'll surely have a look.

Indeed an important question - did you and @Grimm hash this out, or is this an initiative of your own? Will the branches perhaps merge?

Yes, and easily so: Open ths mission in mission editor, then Click on the 'zones' button (three interlocking rings) Click on Show all Click on the zone named "persistence config" Change the value of "saveInterval" from 5 (current value) to 1 Save and you are done.

And this is single-player only, and the "X: Command..." are module-specific, i.e. the mission may not run with a different module. VERY time-consuming, frustrating and limited. But it is possible. just like @Minsky kindly pointed out.

There currently is no good way in DCS to associate a livery with a unit, so livery support can only be provided for some modules. Spawners who can spawn any typeName cannot provide livery control in a meaningful way. Cloners can do it if you manage the livery in ME by assigning it to the clone template.

Please ensure that USSR (the country) is allocated to RED. I think in your default setup, it is NEUTRAL, which forces the error.

"And if I'm flying solo At least I'm flying free"

HIghlander?

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.

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

I doubt anyone can help without you showing us how you set this up (DCS's actions are notoriously easy to mess up, and there is very little -- if any at -- all debug support, so anyone attempting this for their first time risks a receding hairline). I think many more can help if you set up a small demo miz that shows what you are trying to do, and I think that if you post it here, we can quickly get to the bottom of this. The upside is that we all know that is is possible

Yes, that is (blush) an unfortunate result of some backward compatibility I put into unitZones. Historically, unitsZones supported a (now deprecated) 'coalition' attribute that defined which coalition unitZones should regard. I collapsed the function of 'coalition' into the 'unitZone' main attribute, simplifying the semantics of unitZone. To ease transition, unitZones still checks for the old-school 'coalition' and 'uzCoalition' attributes. Goldfishbrain I did not remove that backward compatibility (I simply forgot). This usually is not an issue UNLESS you stack unitZone with other modules that do use a coalition attribute AND that define a different coalition (which is exactly your use case: a messenger that warns the other side if a unit of opposing faction enters it). I now removed backward compatibility (support for "coalition" and "uzCoalition" attributes, the time to do that seems right ), please see below. It also means that yours can be the joys and privilege of supporting unitZone's regression testing An alternate option is to deconflict 'coalition' with the existing version of unitZone by unstacking and moving messenger to its own zone. But that is less elegant, and should be remedied with the updated unitZones version. unitZone.lua

Thanks! Ah, he pitfalls of using inadequate development systems (how much I wish that DCS supported a real IDE - this was no fault of notepad++, mind you, but ham-fisted I: I accidentally hit the c key when I finalized final version). Fixed - just like you recommended by removing the 'c'. playerScore.lua

Yes. At least some of your modules are out of date. Please make sure that you are using the newest versions of cfxZones and dcsCommon. In general it is always a good idea to use the newest version of modules and don't mix modules from different DML versions.

My apologies for being obtuse. RTFM, and use the newest version of cfxZones.

please see here. It's for servers only to work around a DCS bug.

That is already in the game Good news: that is already in the game Not specific, no. But unspecific capture missions are available. I recommend that you follow the instructions to de-sanitize DCS so that saving works. While at it, also install stopGapGUI.

entering twilight.miz

To capture you either send a mission (AI will generate one automatically) that you pay for with the funds that you earn, or take a helicopter with some troops and deploy them there (Expansion is really fun if you can fly one of the transport helos). Yes. Total playing time (if you are good) is some 20 hours. No need to long for Senaki.

At the beginning of the mission, blue only owns a single airfield: Nalchick. All other airfields are owned by red, and players cant join them. The goal of the mission is to expand (hence the name) to capture the other airfields.

What airfield? Initially, only Nalchick should be avalable.

Helicopter 66! And a static item that resembles an Apollo Space Capsule. Please?

Have you tried it? "Note that Helo Troops can load any group that complies with Helo Troop’s ‘legalTroops’ unit filter " It never says anything where those come from.