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

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.

That seems strange, as stopGaps should indeed do what you are looking for: replace player-spawnable slots with static stand-ins. What are you looking for?

It's good that you were able to resolve the issue. Please be advised that your script still contains at least one show-stopping bug: local EscortGroup = Unit.getByName("AI_BLUE_ESC_2-1") if not EscortUnit then env.info("ERROR: EscortUnit not found.") return end Your script should not progress past that point, and always end with the message "EscortUnit not found".

I think a bett question would be "what kind of error?"

Check your variable names, especially escortGROUP vs escortUNIT. Methinks EscortUnit isn't defined.

Hell yeah - it fit snugly into the code I crafted months and years before, the vector algebra, rotation and formation stuff was a joy to add, performance is great, and it took next to no effort to build. I'm almost disappointed that I'm done with this

And here we go, as promised: heloTroops.lua

Since the Bo-105 (hopefully soon) may become reality, I'd love to see Eurocopter Tiger (I've got a soft spot in my heart for the Bo-105, as that was the main attack chopper when I served in the (West-German) army and it was awesome to see them getting into the action during our dynamic exercises)

After some engineering pause (involving a short and salty, non-alcoholic!) Apero, I came up with a nice way to fit in this new ability, independent of how troops spawn: a deploy menu that pilots can use to set troop deployment formation when they leave the helicopter. And the formation is always relative to the helo's current heading to make it easier on everyone. null (<-- ED, please get some real HTML talent, and make your main discussion site behave professionally) Still working out the kinks, but it seems to integrate well, I should be able to pass out pre-release versions tonite before I go for the Apero's Encore (some "Bisteaka Fiorentina" - or similar. She's Italian, not I)

"DD_Friar isn't in many ballads, but he's still an important part of the DML band." - we do have the code for that in DML, and we sure can try. DCS, to keep with "Prince of thieves" our "Sheriff of Nuttingham" here, often isn't amendable to those exploits. A circle formation ensures that no unit comes too close to the helicopter to be killed on spawn, while no such guarantee can be made for other formations. I'll see what I can do. Few things are as gratifying as re-purposing existent code, so it's at least worth a shot.

Since AI needs to be able to do these tasks, I think it's a good feature (and since this is a wish list, it's perfectly placed): switch in AI and stay in the cockpit to see how AI does it - an instructor driving your plane, so to speak. It could also be the precursor to "buddy control", where another player takes control of your aircraft, and you watch to see how they do it. I envision a "Handoff to AI" menu that has sub-menus with "Continue straight and level", "Land on nearest friendly airfield/FARP/Carrier", "Fly to next waypoint", "Resume Control" (yeah, I omitted the obvious "Approach Tanker" and "Refuel" points for being less contentious). The downside for this of course is that right now, IMHO DCS's AI is nowhere near where it can do that - all AI approaches seem to be on rails, with stark disregard of procedures (especially radiotelephony), speeds and how physics should work, so it could take a while for this to materialize. But handing off to a selective AI whilst remaining in the seat would be a great didactic and convenience tool Why troll on such a beautiful day? Methinks "Git gud" is a toxic, juvenile comment, and our community is better than that. I personally wouldn't use such a feature often (except the 'fly me to waypoint' bit, which usually Otto can do fine except in helos) because most I do in DCS is landings, but that is my silly preference and entirely beside the point. Such a feature could be a godsend to many players.

Some really interesting stuff (CA upgrade? Nice!), and it's always good to hear (and now see) Wags. I'm really hoping that ED manage to attract some good UI talent for the all-important Dynamic Campaign UX - because, quite frankly, what we have seen in the past 12 months in this regard (MP join faction dialogs, CH 47 cargo interface and ME's band select feature) are UI disasters, veritable master-classes in how to violate or destroy every UI guideline, convention or expectation (looking at the MP join faction UX makes me wonder how they manage to violate more UI rules than there are interface elements). If the interface isn't up to snuff, people won't use it, and it'll be a terrible waste to create something this wonderful and important only to have it go to waste on usability grounds. So here's to hoping that ED manage to attract some top-notch UI people for DC! And a possible peek at the end of this year? Icing on the cake!