cfrag

Update 1.62 - 20241023 Changes: autoCSAR DCS bug on isExist hardened against cloneZones now correctly reconnect from persistence better nilling in slotty Enjoy, -ch

You may want to try a raiseFlag on the input that hides the menu 1 second after mission start. I'm not sure that that works for all use cases, but it should for menus that are available for all aircraft.

I first want to finish Expansion (it's close to what I wanted to do with it). After that, there have been a couple of suggestions. Cold war is something that I have kicked around, a bigger Expansion on a different map (probably Syria) is probably the next step. No definite plans yes.

CTLD is outside DML's scope, and I have rarely looked at it, IIRC, it uses a unit's/group's name and that will throw you off if you are using a DML clone - because clones adhere to DCS's requirement that all names must be unique. You can force a cloner to keep the clone's original name and ID by setting the 'identical' attribute to true. If you do that, remember that the 'Highlander directive' is in force - there can only be one. With identical active, any previous clones from that cloner are destroyed when a new clone group with the same name/ID is created. But CTLD should (hopefully) work with that group.

That is most probably because the aircraft are flying too high to be part of the volume that wiper checks (a sphere with the same radius as the zone -- wiper was built to remove debris on the ground. My (severely limited) imagination failed to foresee that use case. That being said, perhaps you can trigger the spawning cloner's declone? input to remove the group? Or you could perhaps use a groupTracker's destroy? input for that purpose.

Huh. Thank you for clearing that up. I believe you could have led with that, along the lines 'I effed around with some scripts, added the Herc, and then I got an error, perhaps where I screwed with the script...". I don't mind people effing the scripts - I rather expect you to . I do mind when you send me on a wild goose chase because you do not disclose important details like changing scripts

Do you have any indication which script throws the error? Malformed number is a strange one, usually a typo. If you run it as a DOSCRIPT instead of DO SCRTIPT FILE, we can often see the first line of the script and that often tells us what script is misbehaving.

Thank you, I'll have a look at it.

Well, I think it's still the Herc mod. Methinks it would be best if you removed it.

Disappointing indeed. It looks like that's a Hercules bug, though (DML scripts in my missions always identify themselves). Let's hope that the Herc will make the transition to a 'real' DCS product soon, I've pre-warmed my credit card already

Aaaaaand the award for this month's greatest understatement goes to: @Tippis!

Ha! Welcome to advanced trigger transmogrifation! So you already know the answer, just not which DML "bricks" to use. Let me point you into the right direction: What you are looking for is (in old-school TTL electronics) a 'gate' - something that lets a signal through when one condition is met, and prevents it from passing through otherwise. Have a look at the second use case for the 'changer' module. So when the airfield belongs to red, the gate opens, and otherwise it closes. Connect the triggeing flag to the changers change? input and then changeOut! to the cloner's clone? input. The triggering signal will only propagate if the gate is open. But how do you tell the gate to open/close? That's a job for the first use case for a changer. Use another changer to create a direct signal to the first changer (the one that functions as a gate) and connect it to the "on/Off?" gate input. And get the current airfield's owner (perhaps from an airfield's ownedBy# attribute and use the 'bool' conversion to match the "=1" trigger method. So you will be using two changers to process/gate the incoming cloner signal. If you can't get it to work, we can hit it over the head until it does.

Update 20241019 - Many DCS bugs worked around, added Chinook Mission works again, and now supports the Chinook. Enjoy, -ch

FC 2024 FUN PACK - Flaming Cliffs Practice Sandbox [all FC aircraft] Download: ED User Files Forum Thread: HERE Your Flaming Cliffs 2024 planes have arrived and assembled outside, ready to fly. All planes are fueled and armed, the only thing they need is you in the cockpit. So suit up and strap on, pilot! Features Ogle at all your aircraft Once you are inside your cockpit, take a good look around. The airfield is populated with aircraft that you can jump in - you own them all (well, except the Hercs). So taxi by those planes carefully, and enjoy the view of the other planes that you own. Landing Practice Senaki Kolkhi's 09 is marked with blue smoke for landings. There is another blue smoke marker on the 5 mile final approach point. To practice landings, take off, turn around and then position yourself over the 5 mile final to set up for nice, easy landings. Additionally, when touching down inside the touch-down zone, your landings are automatically rated, giving you details on quality, speed, run length, etc. "Touch-down zone", you say? Switch to F-10 Map view, look for the green rectangle on Senaki's 09. Logbook ("persistent" -- if you want it to be) What good is a practice ground when you have nothing to show for later? The Fun Pack logs all your flights per type: total time, landings, departures, "super-marginal landings", start-ups. And it saves that data to your permanent storage ('persists') if you "de-sanitize" your DCS. This is entirely optional, and requires some work on your side that I'm too lazy to detail here. Perhaps Google it. Air-to-Ground Practice Taking off from Senaki's 09 and fly that heading until you see red smoke. In the field south of the smoke marker, a number of vehicles await your destruction. They will NOT fire back. At any time you can re-spawn all ground targets with the Communication-->Other-->Ground Targets menu. Note that target positions for all vehicles change each time that they spawn Air-To-Air Practice Should you want to practice your air-to-air combat prowess, you can call up as many enemy fighters from a selection of 12 fighters as you like. Be advised that these enemies will engage you, and most of them have missiles. To have an enemy appear north of Senaki Kolkhi, go to Communications-->Air-to-Air and choose the era and type. You can spawn as many enemies as you dare. I recommend that you re-arm your aircraft for CAP should you engage into air-to-air combat. Most aircraft are configured for ground attack by default. Multiplayer: FC Fun Pack uses "stopGap". If you experience planes crashing on startup, you should install 'stopGapGUI' on your server (only server) to work around a DCS synchronization bug. Multiplayer supports dynamic player spawns for both sides, any plane with any armament. Red players spawn from Kutaisi. Enjoy, -ch

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