cfrag

I think that should be doable, thank you for the suggestion

Here's an experimental version of heloTroops that supports two new attributes for dropZones: keepWait and setWait: keepWait If set to true, groups/units that are disembarked inside this dropZone keep their “wait-” orders active if it was active on pick-up. This can be used e.g. to create ‘assembly zones’ where helicopters can assemble groups for other helicopters to transport to front lines. Defaults to false (existing wait orders are removed) setWait If set to true, groups/units that are disembarked here have “wait” added to their orders if not already present Defaults to false (existing orders are unchanged) Below is a demo build that should show it can be used heloTroops.lua troop assembly zones.miz

They will become 'full DML citizens' in due time, once they are sufficiently usable (in Exp I use crude experimental versions that work with the mission, but are unfit to be used in general scenarios). The one module that you are probably looking for is the "camp" module that pulls together a lot of 'ownable' stuff and combines them with cloners and funds inside the zone. milHelo and milWings can observe owner status and pull together functionality from cloners. These modules are still in "hack" (i.e. not for general consumption do-you-feel-lucky-punk) state and with some luck I'll find the time to complete their design soon. They'll probably appear in the new 'compound modules' section of DML. TBH, I find that since only you know the logic behind that, and everyone else supposes 7337 AI programming skillz on your side, that's most often the best approach... Just saying

Sorry, I suffered an insufficient coffee fault before. dropZone! already does that for you. I'm now working on keeping the 'wait-' suffix when you drop troops in drop zones so you can use them as assembly ground for troops.

Silly Q: what is keeping you from disabling the spawner until the first time that troops are delivered into the zone? I could probably add a delivered! output to a dropzone to make this easier, until then I think a stacked LZ could do the job. Also, troops delivered to a dropZone by heloTroops could optionally preserve the "wait-" command and not remove them... What are your thoughts?

It's an intriguing concept - transport of cargo / troops in general, and using it to reinforce/build specifically. I have 'concepts of plans' for game mechanics that allows players to transport something (an abstract Whatchimacallit) some place arbitrarily and when put down, use it to establish tactical/strategic points: FARPs, Warehouses, Factories, Barracks, AAA etc. Bringing CA into this would add immersion and increase the scope of DCS and what we could do in missions, making missions less sterile and more organic. Alas, the current Warehouse/Cargo API is crap, and CA worse. Right now, neither is IMHO worth a time investment. Once the kind of folk at ED invest some real talent into developing a sensible cargo/warehouse API (e.g. one that allows arbitrary creation/destruction of warehouses, and doesn't always bind a warehouse to an airfield, can manage arbitrary goods not just fuel, ammo and aircraft, etc.), this may be worth further thought. Also, nobody today would claim CA to be a serious product - at least not with a straight face. Scripting for CA is a joke, as their unit API and UX departs radically from all others. Now, if there was a unified player API available that covered all player-controlled units, things may look different. So IMHO there's lots of potential in DCS, locked behind cheap, inept and/or clownish implementation. Missions could be so much grander in scale, just like the concepts that you outlined: create, build and expand your base of operations by creating a network of logistics: FARPs, factories, warehouses etc., and pay homage to the adage that 90% of warfare is logistics (or in the words of Gen. Pershing: "Infantry wins battles, logistics win wars"). I would be happy to explore those possibilities. But we (mission designers and script authors) need something to work with. Today we are far, far away from that.

Version 1.85 - less smoke, more bug protection Changes Smoke should now disappear immediately upon picking up evacuee Code hardening against DCS bugs from recent releases. Enjoy, -ch

Yea i'l just put this bluntly, that's absolute nonsense Agreed. Perhaps OP used 'local fog' loosely, and was trying to make the point that fog is really nothing more than a (local) cloud close to, or touching the ground. Still, people who are aghast that a mission's fog setting in Tel Aviv results in the same fog setting in Adana, more than 1000km away and therefore would prefer local(ized) fog settings (as opposed to "map global") are correct; the way that fog works in DCS is silly and not at all realistic. The (presumed) comment that there is no such thing as fog, as fog is really just a low cloud is technically correct, but misses the point. If I create a mission for multiple players in multiple regions (e.g. the "Angels" mission in Syria with centers of operation in Adana, Haifa, Tel Aviv and Nicosia), I'd like to have some fog in Nicosia, heavy fog in Haifa, but no fog in Adana. That's physically something very likely to happen in real life, even if fog really is just clouds/condensation near the ground (A common definition of fog is: "Fog is a visible aerosol consisting of tiny water droplets or ice crystals suspended in the air at or near the Earth's surface"). It's currently impossible in DCS to set up local fog conditions for a specific area, and that - I believe - is the point of contention.

Yes indeed: all Attributes must be zone-unique. Since you have two attributes named "messenger?" (and two named "message"), it is pure chance which one DML's parser fetches (it depends on how the mission loaded, and the flavor of the color green at that moment). Attributes are accessed by name, the order in which they appear in a zone is not significant. If two or more attributes share a name, it is undefined which will be returned. Hence, only one attribute can have any name per zone. Since all modules are identified by a unique attribute (e.g. "messenger?" for messenger, "smoke" for smoke zones, etc.), there can only ever be at most one instance of a module placed on a zone.

I think that would be the best approach - a cleanroom reproduction of the issue without the distraction of all the others. And of course I'll be happy to look at it.

No, that would be something only Moriarty would recommend. Dang! Looks like some more investigation is required.

Ah, indeed, Dr. Watson! However, if the module messenger loads after the ones that provide the outputs on red# and blue#, messenger will not hear those commands (in coding terms, it uses the current values of those flags as default, and only reacts to changes from that value.) You may get everything to work if you simply place 'messenger' in the load action before the other modules.

This may sound like a silly question: why do you think that you should see "Good guys own 1 out of 4 zones"?. I'm guessing that you progressively remove zones from red and cap them by blue. What is your procedure to do that, and have you also checked Message History that the message really do not appear but merely are erased quickly by a 'clear screen' command?

Version 1.60 (initial release) 20250218 Download: here (ED User Files) "So if you care to find me, look to the western sky. As someone told me lately, everyone deserves a chance to die." Helicopter Combat Rescue (C-SAR) Sandbox ================================ You are a "Battle Angel", a member of Blue's elite Helicopter Combat Rescue Team "Cesar". The battle for control of Damascus has turned into a prolonged aerial conflict. You are tasked with retrieving downed pilots and return them to a Field Hospital inside the blue safe zone (the hospital LZ is marked with red smoke). While evacuating pilots, expect opposition forces to be on the prowl, so perhaps bring a friend in a gunship. Pearly Gates, your command authority, is in contact with all downed pilots. They can provide you with an updated list of all pilots requesting extraction and can vector you to evacuees. All evacuees use an ELT that you can home in on; Pearly Gates has their frequency. Once you get close enough, the pilot on the ground contacts you and pops smoke. Land close enough to pick them up; have your gunners ready to defend against approaching forces, especially on egress. If you can't land, or prefer to hover to defend, you can winch rescue the evacuee (this is automatically initiated by your chief) WARNING: Be advised that as soon as you can see the smoke, so does the enemy. Expect that you have some two minutes from the moment that your evacuee pops smoke until your LZ becomes hot. Since there are enemy forces actively looking for downed pilots, expect enemy fire on ingress and egress. The entire area around Camp Cesar is contested, with lightly armed patrols roving the area, looking for downed pilots - expect enemy contact once you leave the camp's security blanket. WARNING WARNING: The area north of the yellow "barbed wire" line (marked "--X--X--" on the map) is exceedingly dangerous and only suited for experienced pilots. It should best be entered with a support ship. Damascus' airfield is in Redfor's hands and actively reinforced; the area around the airfield is expected to be patrolled and heavily defended. Only approach the airfield if absolutely required. Scratch that: never approach it, soldier! Attacking the airfield's defenses is outside the scope of your operational parameters and a sure way to attract immediate, and superior, retribution. So, fly low, fly fast, and wear sand filters. And come back alive, Angel! --- FRQ: FARP London 225.0 MHz Weather: CAVOK Notes: If you also have one of the other "Battle Angels" missions and persistence is enabled, the missions share player's accomplishments. This mission can persist all your accomplishments (landings, time, rescues) per airframe if you have persistence enabled (this requires that your DCS is 'de-sanitized'). When run on a server, install 'stopGap GUI' on the server to allow static scenery occupy open player slots. If you are a fan of the Blackhawk, you can add it to the mission and it is immediately supported. Griefer protection is active. Blue on Blue kills are punished. Severely. Acknowledgements Voice acting by ElevenLabs Mission by CFrag Created with DML Uses StopGap (MP only) Enjoy, -ch

Version 2.01 - (finally!) remove blue smoke immediately upon loading evacuee - 20250218 All Changes Blue smoke (next to evacuee) vanishes as soon as they are on board Hardening against DCS bugs Enjoy, -ch

I'll look into it. Seems doable, but I haven't looked at the code for some time.

No *technical* limit, no - scraping mesh data from Google's (or other provider's) maps/terrain and objects is easy, and the API is provided. Because that is one of the (many) methods that Google makes money. And that's the impediment for ED: to access the data, the app needs an API key to access the data - getting that is easy. If ED then builds DCS with such a key, access to data is metered for anyone using it, and ED billed at the end of the month. I believe (last time I used that service for an app, the real number is probably a decade out of date) up to 100 accesses per day are free, any number above is charged. So, if only 101 players access google data via the DCS app key once a day, ED will get charged. There are probably more than 101 people a day who would use it. I'm a notorious Mission Editor user, and my editing alone would probably account for more than 100 accesses per day, more than 10 even if cached. So, no technical, but a lot of financial aspects will limit this.

Agreed. And how far have your talks with management progressed in this regard? I'm not bad-mouthing your intentions nor approach, I'm questioning your familiarity with the matter at hand and your contacts inside ED management. Do you think that the items that I've talked about are new or have not been a matter of subject that were discussed in the past? I believe that they have. Many times. Indeed. So how does your approach (yet another post in a forum resplendent with requests and starting points for changes) sits aside from the 100+ that are started each month? If you believe that your post is that single point of reference I wish you all the luck that you need. You have my vote. Now you only have to convince all the others, and make sure that your thread never disappears below the fold. So, for reference, I would submit the following as points to pass on to management (just off the top of my head): overhaul the event manager, provide more events (start/stop for actions), the ability to post events to others, introduce event categories, event filtering, add an event class tree overhaul Warehouse API to be able to manage generic items instead of the arbitrary split between liquids, aircraft and weapons, add vehicles, add generic items such as water, medication etc do not attach warehouses to airfields introduce warehouse classes add the ability to create missionCommand menu items for units (not just groups) add unit management so we can change a unit's life/health, fuel, ammo add a player management layer add the ability to change the weather add the ability to change the day/time make fog local Good luck, and all the best, -ch

Version 1.71 - Important performance/bug fix - 20250216 This update finally tracks down a bug in DCS that can potentially lead to crippling performance behavior in DCS - a bug in DCS-internal line-drawing methods. This update also patches a new DCS bug that appeared with the January 2025 update inside the way that DCS saves zone attributes. Other changes include some less generous scoring after players buy the farm, less aggressive AI on lower difficulty settings, and some other minor changes. Version 1.71 Changes in detail: • worked around a show-stopping DCS bug (performance killer) • patched a silly change in DCS mission data format • playerScore is less generous awarding kills • made playerScore less verbose • more mission difficulty balancing • setting difficulty to less than 1 suppresses RED repair/upgrade

Hmmm. When people talk about Mission Creation API, they commonly talk about DCS's Mission Scripting Environment, which you can inspect here. It's awfully inadequate for the job, is distinctly riddled with amateurish design decision/blunders, badly documented and maintained, and famously buggy (I reported two show-stopping bugs in the past two weeks: one in net.lua2json(), the other in trigger.action.removeMark()). They each have a 50/50 chance to get fixed in the next 10 years if we go by ED's track record. You seem to be talking about some minor aspect of the MSE, namely some events of the (comically underdeveloped) eventHandler and some missionCommand callbacks. While I agree that DCS urgently needs an overhaul of those parts as well, I feel that they make the minority of issues. The entire MSE API is sliding and becoming unmanageable, the new Warehouse API is a masterclass on how not to design a system. In MSE, player handling is a catastrophe, the eventHandler is abysmally dysfunctional (you can't even feed your own events to it) and lacks fundamental events (cargo events, just like you mentioned, amongst them), group creation and AI tasking is a coding tragedy, and the entire 'trigger' singleton shows that it was thrown together ad-hoc (trigger.misc branch for getUserFlag, and trigger.action branch for setUserFlag) by whoever was working at it at the time. Looking at the missionCommands singleton is enough to make any experienced developer's eyes water. IMHO, the entire DCS MSE API needs a serious work-over, and it would help if ED got some talent involved who know what they are doing: real developers with real experience in code design and architecture. Looking at what was recently delivered with their Warehouse API, I'm not convinced that they currently have the right people working on it, nor that improving the MSE API was a focus of their work. Let's hope that this improves soon because I agree that content creators (mission designers) are part of DCS's lifeblood, they give players things to do once they have purchased their modules, they can make people want to stay in DCS.

Hey all, at long last I tracked down a severely performance-degrading (and in servers halting/crashing) bug: when a script invokes trigger.action.removeMark() on a mark that was drawn before the mission had a few cycles of mission drawing, the thread executing removeMark() crashes or slows down to a crawl. This can happen in any mission script that first draws a rectangle during init, and then immediately tries to erase and redraw it (for example if data was loaded at mission start) before the mission has really started. The result is a mission that may run in single-player, slows down to a once every 10 second update in player-hosted MP, and completely trashes the server in dedicated. I could submit a simple demo to recreate this bug, but ED appears to be so swamped with the other bugs that I've reported in the past years that I'll save me the trouble.

Who's doing it now? Because right now it is being done. Making an existing process better is possible. Making it more efficient and user friendly shouldn't take 20 years if you attach value to it. I'm not saying it is going to be free. The opposite is true: caring for customers can be a significant investment. It means that you are showing dedication and care for the community. And there could be some payoff at the end. The perceived lackluster uptake of UserFiles may well be a chicken-and-egg problem: No one uses it because the interface is bad. The interface is bad because no one uses it. etc. What is keeping them from doing it now? In this day and age digital contributions is a process that has been well understood, solved, documented and freely distributed. A contributor can request a crypt key pair from ED, and their contributions are then encrypted not only tamper-proof during upload, it can be disabled at a heartbeat from ED at all clients who downloaded it. This is commodity software by now, implementations of this are cranked out by the dozen each day, and are part of many web publishing bundles. The documentation for writing this kind of software is openly available and has been for 20 years. I've implemented this kind of software more than 15 years ago, more than once. If I can do it as a side job, I'm certain ED's talent can if they set their mind to it. The problem of Lua not being properly sandboxed points the finger at another rather glaring shortcoming on ED's side that I'd rather not dwell on, but it's hardly a good excuse to make player's and contributor's UX as horrible as it is now.

The year's still young, but we have a contender for "understatement of the year"! The UX is last millenium, and simply user-hostile: it breaks apart your mission description in a lame, 30 years-old attempt at preventing code injection (so "where" becomes "wh ere" or "update" becomes "upd ate" etc. As if no-one has heard of prepared statements. Terrible, crummy, old code The onus is on you, the content creator to provider (in an old, GeoCities-like interface) to provide information like player aircraft types, map, etc. -- all things that a simple script can read out of the miz file by itself. Clearly, ED don't care much about content creators, or they wouldn't deter them with such a crummy interface. Remember that all users are logged into DCS. Why is that important? Because it would be trivial to write a script/interface for mission creators to share/publish AND UPDATE their contributions from MissionEditor. And players who downloaded missions can see updates for their mission as they become available. ... All that (and a lot more) is what separates the pros from the amateurs, the good, community focused companies from fly-by-nite wannabes. I really hope that ED will some day soon realize that content creators are an important part of their community and extend a hand to make it easier for people to share and enjoy other people's work. Yeah, I'm rambling again. It pains me that one of my favorite apps has such a sh¦%%y player-facing side.

Yup, a typo that I failed to correctly regression test. Here's the update: pulseFlags.lua

Version 2.4.3 - REQUIRED UPDATE - 20250213 Whoops, they did it again. For some reason, and documented nowhere, ED changed the way that MissionEditor saves some of its zone data. This played Havock with some modules, and my disbelief was... The fix in DML was as quick as the change to DCS was silly. Since DML uses a modular, engineered approach, fixing this in a single module was sufficient to restore all modules back to full working condition. As a result this update to DML is required for everyone who creates or edits missions with a DCS version from, or later than, the January 2025 update. And since I'm already whining about really, really bad stuff in DCS: I took another stab at working with DCS's Warehouse API, and - again - came away aghast at its amateurish, clownishly bad design. I flat-out refuse to believe this to be the result of professional work, much like the band-select "feature" in Mission Editor. No professional worth their salt would sign off on something like this, and I hope that it all turns out to be a practical joke. The WHpersistence module (which persists warehouses) required a near-complete rewrite, and should now correctly support ferry flights. While at it, I discovered (and reported) a show-stopping bug in net.lua2json(). Hopefully this gets fixed - seeing that my last report of a different bug in net.lua2json() (math.huge is incorrectly converted) has been unfixed on the record for more than a year, I'm trying to keep some optimism and hope for at fix sometime near the end of this decade. On the positive side, this update is filled to the brim with small updates, and sees the release of a new 'kind' of modules, the "compound module" - a specialized module that pulls together the functionality of multiple modules to provide easier access. Compound modules are designed to ease building specific functionality, and aren't as flexible as the normal building blocks. "FireCtrl" kicks off this category of modules, and it is designed to integrate "airtank" and "inferno" and adds some player management for good measure. You can see it in the wild in "Heroes of Flame". All changes: Documentation Main - FireCtrl (new) - Various Changes QuickRef - Various Changes Demos - fire starter (new) - FARP and away (update) Modules - Airtank 1.0.1 - attachTo: no works correctly - cfxZones 4.5.2 - GUARD AGAINST DCS CHANGE: "ZONE RADIUS" - new API for property access - FARPZones 2.3.0 - new outputs redCap!, blueCap!, captured! - fireCtrl 1.1.0 - Initial release - GuardianAngel 4.0.1 - hardening against DCS bugs - heloTroops 4.2.3 - new attachTo: attribute - inferno 1.0.1 - code cleanup - playerScore 5.2.1 - wildcard support for scoretable - support for CA players - score wiped on player birth event - pulseFlags 2.0.3 - pulses now correctly inited to -1 - WHpersistence 1.1.0 - workaround for severe json error - support ferry flights (dynamic spawns)