cfrag

TBH, ED could easily expand that concept to display a random theme from all that you own. It requires 20 measly lines of Lua and is trivial for them (yet really difficult for others). I have no idea why they do not implement this obvious opportunity to show off DCS. They sunk a ton of effort into an (IMHO) *terrible* and useless launcher app, yet missed that incredibly low-hanging fruit. A Pity (capital, boldface-italic, underline P).

Ah indeed. Some depend on it, other (me included) don't expect and are tripped up by it. So far, it's more a matter of baseline definition, some written docs on what the rules are. It is something I just discovered the hard way after 4+ years of mission design (including my fair share of capture missions). It's an edge case that was driven to the forefront for me when I designed a large dynamic mission with lots of capturable airfields that are expected to have a lot of to-and-fro. I can code against it, but I would have loved it if I knew years ago when I built that particular part of my code framework. It's no news that the current state of MSE documentation is abysmal (to put it nicely), so yeah, it's just another day in MSE. Agreed. Then again, to do that we switch from a modern, event-driven model to last millennium active polling. It is entirely doable. It does highlight yet another severe deficiency in ED's code. It's really bad design, pure and simple. Let's hope that the fine people at ED find the time to also invoke the event on neutral 'capture'. Your past suffering does not give me much hope, though. Ignorance is bliss, and it seems that I was blissful for the past years. Perhaps. I see no reason to believe that any active thought has gone into this 'feature'. IMHO it just emerged, it was not designed, and therefore also was never documented. It's here now, and I would like to see some formal definition/docs (just like what goes into capturing a base, as -- as was shown in a separate thread -- it is a lot more complex than simply 'have the only boots on the ground') that we can all work from. I'll design around it for now. Doesn't mean that I like it

While creating a new mission, I seem to have run across two airfield ownership behaviors that seem new to me and/or depart from what I expect: Airfields revert to their original owners (as set by ME) when the last enemy unit leaves the 2km capture radius When a formerly neutral airfield is captured, and it then reverts to neutral after the last unit leaves, no capture event is issued. The base in-game, however, is now shown as neutral. Note that this behavior is exclusive to originally NEUTRAL bases. If a base reverts to blue or red after the last occupying unit leaves, a capture event is issued. Below please find a mission that illustrates this behavior (i.e., it can be 100% and easily re-produced): Batumi is NEUTRAL at start, Kobuleti is RED. For both, a blue Vehicle transitions through the capture (2km) zone. A tiny script alerts you to all capture events. In Batumi there is ONE capture event (neutral -> blue) and no event when the zone reverts to neutral after the vehicle leaves. In Kobuleti, there are two capture events: red -> blue and blue -> red. I'm surprised at both: I did not expect bases reverting their ownership simply because all occupying units left. That would be akin to my car reverting ownership to its previous owner when I exit the car. IMHO, anyone who wants to own it should have to expend resources to receive ownership. Not receiving a capture event (which to me signifies a transition of ownership) when a base reverts from blue/red to neutral seems wrong, as it is a significant change in logic. My recommendations / requests here are Invoke a capture event on every change of hands for an airfield, including a change to NEUTRAL. DO NOT automatically revert ownership after the last occupying unit leaves the 2km radius. A base should stay owned until it is occupied by other forces. I'm aware of a kludge work-around. Turning off autocapture via API for a base entirely would amount to throwing out the baby with the bathwater, as that would require that a mission determines base ownership by itself (a significant additional performance drain). Is there some official documentation on base capture behavior that I might want to re-visit? Thank you for your kind consideration capture analysis.miz

Version 1.61 - 20241017 - maintenance update Changes: updates to heloTroops stronger guards on stopGap refresh Ebjoy, -ch

Thank you, heloTroops issue is confirmed, reproduced and corrected, will be included with the next update

Can I trouble you to verify that you are running the most recent version of Expansion? That error should have been be fixed already. If you set "onStart = no", stopGap should indeed no longer bother you. As kindly suggested by @eric963, you can also change the setting "refresh = -1", although even when set to 3600 (every hour) stopGap should not engage after one hour (checking this right now). You can make sure that stopGap won't bother you again simply be removing the DOSCRIPT Action "(stopGap =" from the 4 MISSION START "DML" trigger.

NoGap hasn’t been updated yet to support dynamic spawning. The error happens when you leave a dynamically spawned aircraft, and noGap looks at the Miz’s defined player aircraft to determine what static aircraft to place, and where.

I hear that there are concepts of plans. Or have been. It's been some time...

Inconceivable! (and yeah, I think I know it means what I think it means...) Let's try and forget this little coding mishap: impostors.lua

AFAIK, camp is currently already present in DML (because I intend to share all major work I do for mission creation so everyone can create even better missions), but not yet documented. I'm not going to write myself into a corner here - so currently the sequence in which they are chosen to be upgraded is officially "mysterious". My apologies.

Update 20241011 - Stability Some hardening against most egregious DCS bugs. Better Scribe. Enjoy, -ch

I believe that this is a known DCS issue with dedicated server. Just to make sure, I've reported it to ED. Thank you so much for taking the time to report the issue.

This issue surfaces only on dedicated server (it works fine on singleplayer, local/hoc hosting): When contacting ATC (I'm using an A-10A in Senaki, easy comms active) from airfield and request startup, tower does not respond.

I imagine similar mechanics as when you are pulled onto a carrier's cat track (correction of location and orientation). Simply force a movement to the correct location. Maybe put some lines on the ground in which the aircraft must be located. If it's inside, it can be forced-aligned. Could be part of the re-arm/refuel process

I believe I have found the issue: the ackSnd attribute assumed (for silly reasons it assumed that it was only applicable if you also specified a group attribute with the menu) that the audio was to be played to a specific group only. I changed this, please try below slightly updated radioMenus. radioMenus.lua

That's odd indeed. Since I do not own or use WW2 AP, I can't reproduce the issue, and lazily assign blame to that product You probably mean 4.0.1 from DML 2.3.4 If you can PM that miz to me, I'll see if I can have a look. [EDIT: no longer required, please see below]

So my first test would be to make sure that you get the ACK message "New Convoy dispatched..." - if you don't get that, there won't be a sound either. If you get the text message and no audio, it's time for me to break out the debuger I guess. And we are talking about item A, right? And the most recent version of radioMenus...?

That would indeed indicate something else is amiss. I don't think that it is an issue, but you can move the AT START Load Sound trigger to a standard trigger at condition time more 99999999 - it's only there to ensure that the sound files are included. File name and extension is correct.

DCS has a known, intermittently occurring bug playing sounds to clients in multiplayer.

I'm often mystified why people seem to believe that ED have not done that (looked at the numbers) and haven't yet come to a conclusion. I believe that they probably already have done both - it's quite possible that the result is just not what we had hoped for. The obvious, "even more profitable" idea (based on your suggestion) would be to make a free, much better Caucasus to lure in even more players by putting forward your best foot (a fantastic free Caucasus). Don't get me wrong: your suggestion could be profitable, agreed. It just may be that it's not likely to be profitable, and it is therefore prioritized accordingly. Maybe ED did not find someone who would want to invest in such an endeavor, take the risk (which would be big). I'm all for a better Caucasus. To me, this is not obviously "free money"; I see it as a financial loss more probably. So unless ED are prepared to finance a loss leader, this is a non-starter to them. I have no insights into ED's inner workings, so above is just an educated guess.

Update 20241010 - code hardening, better hospital names - some better csarFX - better (more exact) scribe - code hardening - better hospital names Enjoy, -ch

Update 2.3.4 - 20241010 -- Feature Update "Tickle" "And now, for something completely different..." for fans of Monty Python, please imagine a loud "boom" in the foreground. This update of DML brings an entirely new module with completely new abilities that is exclusively for those of us who run multiplayer missions -- in other words: those who run servers - be they ad-hoc local, or dedicated. When installed, the module 'Tickle' provides you with means to schedule missions on your server (i.e. rotate missions every 4 hours), and to change the currently running mission via in-game chat. Again - only if you run a multiplayer mission, not for single players. The rest of the past weeks I spent hunting a highly pernicious bug that could suddenly cause DCS to quit entirely (also known as 'CTD'). Normally, in well-behaved environments, invoking game API that should be impossible. Then again, this is DCS, and here it is entirely possible. After some long (and definitely *trying*) debugging sessions I finally was able to isolate, then re-produce, then identify the issue: a bug in DCS's json conversion code that can't handle cyclic structures and proceeds to tear down the entire application. The error sporadically surfaced in Expansion, if you loaded a specific infantry group, flew them 15 minutes to an enemy zone, used them to capture the zone, and then saved the mission. Bright side: my helicopter skills have become *really* good. Expansion 1.6 update fixes the issue, and the HeloTroops module now defends against the json issue by preemptively eliminating cyclic references. All changes: Documentation Main Tickle (new) noGapGUI (new) stopGapGUI heloTroops additions Quickref heloTroops additions Demos (no changes) Modules cfxMX 2.2.0 new groupCatByName heloTroops 3.1.3 resolved cyclic structures on save upcycle structures on load new loadSound and disembarkSound attributes impostors 1.1.0 filters dead units performance improvements persistence 3.0.2 guard against json bug strenghtened info logging Tickle tcliGUI 1.1.0 Initial version Enjoy, -ch

That map would have to coexist and work with free Caucasus, else it pre-empts a lot of multiplayer playing. To make matters worse, it would also have to be 1:1 compatible with existing Caucasus missions - when mission creators lovingly and carefully place an object in one Caucasus map, it must be as accessible, visible and consequential in the other. If, for example, you place an ambush at a farm near a bridge, those farm buildings must be very similar, the bridge must be there, and all units must have the same arc of fire (and be targetable) as in the other map. In short: that new map would have to be near-perfect old map. There could be an extension to, say the Crimean peninsula or Turkey that's not reflected in current Caucasus. Well, there goes interplayability... Another point: Caucasus is my go-to map for performance. DCS's performance in Syria, Sinai, Kola, SA and Afghanistan is abysmal in VR. Sure, an update to my rig is due. Until then, I like having at least one map that works well enough (since around May, Caucasus is also tanking on my computer)

Update 20241009 -- Stability Update, Kiowa, Chinook Update to work around lots of DCS bugs Added Kiowa (although it does not - yet? - support sling loading) Added Chinook Now supports dynamic spawns Enjoy, -ch

That is very weird. Can I trouble you to make double sure that that mission is running the updated version of the script. I'm not saying that it is impossible (stranger things happen in DCS), but I'd like to make doubly sure that the miz isn't accidentally is running the old, unmodified script. I don't know how easily I can get that data, and present it in a good way, but I'll take a look.