cfrag

Not any longer: heloTroops.lua

Oh yes, "1 073 741 823" in decimal equals "0x3FFFFFFF" in hex, a sure sign that some inexperienced coder use that constant (a 31 bit (?wtf?) maxInt) instead of using a bool in the data structure to denote unlimited supply. A rookie (or cheap talent) mistake. A slightly more experienced amateur would probably have used "-1" as "infinite".

Thank you for that sleuth work. Another fact to add to the bin "evidence for cartoonishly bad code engineering" in DCS's Warehouse API. Sigh.

Ouch, a classic logic blunder: I forgot an 'else' to properly handle the default case. On it now.

Thank you so much, I'll have a look asap

Indeed. Do you have a miz for me (no mods please) that shows this erratic bahvior? I guess that is easy to determine: remove WHpersistence. If you have a demo miz to force the issue, that would help. -ch

Not "vanilla" DCS. When you add one of the many frameworks available, it becomes trivial. See sample below (sample uses DML). spawn random loc inside zone.miz

Huh. Indeed. That's odd, and after I successfully regression tested. Here's a corrected version: Thank you for the quick report smokeZones.lua

It’s RGBA. The last value is Opacity. 0 is fully transparent, 128 means half transparent, 255 is fully opaque.

I usually place a couple of Tigrs (the car) on the ground. They have sufficiently bright lights for most uses. They simply look silly in others.

I believe the green arrow refers to ME's "play mission" button. Dynamic spawns are only available in multiplayer, so you must start a local (or ad-hoc) multiplayer game (the performance impact is small, and it's a great way to play single-player missions).

Version 2.4.4 - Update - works around show-stopping DCS bug - 20250227 It was a splinter in my mind. Although I never experienced the bug myself I knew that people had run into it. And it was bad - literally show-stopping. It escaped me (and as a result bugged many others) for months. And still I never caught even a fleeting glimpse of it. And then, luckily, I received a mission that could re-produce the issue - so my thanks go to @DD_Friar who supplied me with a Miz that forced the bug out in the open. It turns out that the performance-killing bug is caused by a bug in DCS's trigger.action.removeMark() when invoked too soon after drawing a mark. Yeah, I'd never have found that by myself. So now Expansion (hopefully) runs full throttle on all servers and single-player machines like it always did on mine. I used the the past few weeks to upgrade the odd module (yes, cloneZones now sports a "maxCycles" attribute, as requested) -- and to finally bring "CESAR" to Syria. It's a lot meaner than CESAR Caucasus - so if you're a glutton for punishment, you'll love it. And if you want to study how I use DML to create missions, they are good study objects. All Changes: Documentation Main - Many changes and updates QuickRef - Many changes and updates Demos - smoke'em (update smoke zones) - colored smoke switcher (new) - Random Glory (update) - Reaper, man (update) Modules - cfxZones 4.5.3 - supports names for smoke colors - better support for random smoke color - cloneZones 2.6.0 - new "maxCycles" attribute - csarManager 4.3.0 - smoke extinguishes as soon pilot is evacuated - new 'keepSmoke' option to leave smoke on - dcsCommon 3.2.1 - markPointWithSmoke() supports smoke names - FARPZones 2.4.0 - work-around for killing DCS bug in removeMark() - heloTroops 4.2.3 - new "keepWait" attribute to manage orders in dropzone - new "setWait" attribute to manage orders in dropzone - ownedZones 2.5.0 - work-around for killing DCS bug in removeMark() - persistence 3.1.0 - new "validFor" attribute for better memory management - pulseFlags 2.0.4 - corrected a silly typo - reaper 1.3.0 - new "invisible" attribute that makes drone invisible to AI - smokeZones 3.0.0 - smoke can now be stopped immediately - suppors persistence Enjoy, -ch

Try this. New 'invisible' attribute for the zone, module still has some debug verbosity built in invisible When set to true, the drone is invisible to enemy AI so it won’t be attacked by SAM nor enemy units. Does that work for you? reaper.lua

Unfortunately, you do not show when and how above code is invoked, nor how those templates work. There's one thing, however, that makes me very uncomfortable. It's simply not there yet, and tends to make things worse for people trying to learn. Don't use chatGPT for mission scripting. Also What is that?

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.