cfrag

Not one of the other Hueys that already exist, but you could edit one flight (group), and increase the number of ships in the group to two. Make sure to set the skill of the added ship to anything but player or client make it take off from one of the "Misc" helo pads or remove one of the existing players to make space. If you play single-player there are enough pads to choose from. If you play MP, stopGap will crash multiple helicopters occupying the same location. You wingman should follow you, and since you don't follow waypoint, he won't either. Caveat emptor: I don't know how the scripts react to multi-ship groups with AI; you'll have to find out.

Some more hints/explanations of why this works and how: DCS, being a creakingly ancient well-seasoned application, was originally designed for a single map (Caucasus) that was flat (currently, all DCS maps still are), and all locations on that map are expressed as offsets horizontally(W/E)/vertically(N/S) to the map's Origin (the point that has the location [0,0]. Warning: in DCS, the x coordinate is N/S, and z is W/E!). In Caucasus, that location is roughly the location of Simferopol/Aqmescit on the Crimean peninsula (this in itself a relic of the past when DCS's predecessor 'Lock On" was made and Crimea was part of the game map, changing to the current map around the release of "Lock On: Flaming Cliffs 2", circa 2003. Yupp, more than 20 years ago. DCS is old enough to drink in the US). Unless you changed the default in DCS, this origin it is also the location for NEUTRAL's bullseye. All units, when you place them in ME are placed relative to the map's origin (0,0), with their coordinates given as offsets (in meters) to that point. If you go into ME, move the mouse cursor and look at the bottom, you can see changing numbers next to the "CCS" label. If you move it to the Crimean Peninsula, watch the numbers recede until they become (0,0). You are looking at the map's origin, the point that all units use to define their position relative to. Why is this important? Because each map has it's own origin, and if you change the map, you also change the position of the map's origin. Since all your units are placed relative (in offsets) to the origin, a point that has the location (2000,9000) in Caucasus (i.e. was located 1000 meters North and 9000 meters East of Simferopol) is now displaced by that same amount from that map's origin. For the Syria map, that (0,0) location is roughly halfway between Banyas and Tartus. So, if you took a map made for Caucasus, and changed the "Theatre" attribute of the mission to "Syria", all units and zones will come to rest in the exact same relation to each other as on the Caucasus map, but they will be placed in relation to the new origin, so all units and zones will be shifted across the map: they are now located in relation to the new origin (that coastal point between Banyas and Tartus) that they originally placed in relation to Crimea's Simferopol. Since for most mission designers, trigger zones and triggers take more time to develop than placing individual units, it can save you quite some time if you change the "theatre" entry to the map you your choice, and then merely re-position all zones and units. Some 3rd party map editors can use this fact to relocate your groups/zones from one map to another. Now, if ME allowed us to band-select units, we would be in heaven, but that's probably something we will have to keep dreaming about... I hope this helps you understanding how and why the units groups have been moved to these strange-seeming locations when you change the 'Theatre' attribute. Note: The name of a map to be filled into the "Theatre" attribute is inherently not guessable and case sensitive (as far as I know). You must know it before you can change it. For example, the Sinai map's Theatre is called "SinaiMap", Syria is "Syria", and South America is "Falklands", and Marianas is "MarianaIslands" - so beware, and be sure that you know what you are doing. Anyway, you are working on a copy, right? Right??? [aaaaand I realize that this is entirely off-topic, except that I love the MB-339 and do not think it overpriced. Sorry to ramble]

Ah, that was a bit premature I guess. But there probably will be - I'm looking at some free time over Easter...

Since you already figured it out, there's no reason for you not to - it's currently not fully supported from me. But it's a very simple module and should not create issues. Yes, that's how the 'lase' orders work, and the range attribute from the spawner is crucial (remember, I didn't know those JTAC units even existed until you showed them to me -- so this works with any troops that have the lase orders, you don't need the JTAC type). Remember that the lasing ability is not something that the jtac gui module gives you access to, but it's something that is provided by the groundTroops module that manages units that have 'lase' orders.

uh. That's an old module that I'm so unhappy about that I never documented it. Yes, it needs cfxplayers to run When by 'crash' you mean 'put up an error dialog', then yes. That is standard for all supported DML modules. They will tell you when they need another module in order to run. I abandoned JTAC GUI to the wolves before I added that. Units deploy in a circular formation around the helicopter when using heloTroops, and then assume following their orders if you spawned them with a spawner. heloTroops does not know nor care what kind of units it deploys, it merely deploys the unit types that it picked up That's currently not possible with DCS AI. If you give the units 'lase' units, you don't need JTAC type units at all - all lasing is handled by DML, and the units don't move. At this point, it's the best that we can do until the unit order API is opened up.

That would entirely depend on the routes that you assigned those troops. If they have orders to attack owned zones (from the spawner), they should move into the zone (but the zone must have sufficient size, say 100m across, 50m radius)

I'd recommend Audacity (free and complete) or Logic Pro (Mac only, Pro-Level). Be advised that much like using a good video editor, you can't do much with an Audio Editor by itself: you need access to some audio source (like samples for gunfire etc). There are great sample libraries available for next to no cost, and if you purchase one of these libraries you have one incredibly useful thing: peace of mind that you own the rights to use them and aren't threatened by DCMA takedowns (and resulting litigation) should your mission prove to become popular. A library of some 5'000 production quality sound effects should cost you around USD 20, which I find to be acceptable (the price of three decidedly average coffees where I live). And while there are very good free editors (Audacity), you often do get what you pay for. I recommend you go with free first, and only go paid when you find that you enjoy doing audio production or want to create an income stream

Unfortunately, player_enter is borked in MP, which is truly unhelpful since that is when it is needed most. What you can do do (and what @Grimes kindly alluded to) is write a small server script that works similar to the way SSB communicates with client-side missions: whenever a player connects to a slot or leaves a slot, set a flag with the exact name of that player to a value: 0 = not connected, 1 = PIC, 2 = crew - and interpret that value during events. It's less than optimal (you'd need active polling), and I don't know how quickly the server synchs flags (I have a nagging suspicion that it can take up to a second for some clients). But it may be a start, and if you are writing missions specifically for crew, I think you'll have some kind of active monitoring in place for players anyway.

And to be on the safe side: You have loaded the unitZone module, right? Sounds silly, I know, but I've made this silly oversight more than one. If you can't resolve this, maybe I can take a look at the mission. This should be quite straightforward. Sure, if you only want to be able to pick up JTACs and nothing else. The list is not additive to the existing, it must contain every type that you intend to pick up. Usually, you can get by with the three to four your mission has. Since DML attempts to default for any possibility, that list is much longer.

that logic seems sound - to me at least

That is to be expected since you put the spawner's paused flag to true (which is correct if you only want the spawner to spawn on command, which is - I believe - what you were asking for). If you want to spawn units when the mission starts up, add a raiseFlag module, and have it once raise flag 'goTest' at mission start. That will spawn once when the mission starts up, and the spawner (since paused) remains under control of the 'spawn?' input. I don't see the trigger, so I can't comment on that.

By default, spawners spawn after their cooldown runs out. To have spawners only spawn on command, use the "paused = yes" attribute

Thank you @DD_Friar for taking the time to report the issue in such detail, I appreciate that. This had me stumped for a while until I clued in to the fact that "JTAC" is indeed a valid typeString for an infantry soldier, one that I did not find in what I use as DB for all things DCS units: objectDB After some experimenting, head-scratching and examining missions, I discovered that there is indeed an infantry type that has a typeString of "JTAC", and it should be deployable by helicopters. Huh. Thank you for that! This should make heloTroops even more versatile. That is because HeloTroops checks all members of a group against a whitelist of allowed types before it allows anyone from the group to step in. Else people could try and allow a Sherman Tank inside the passenger cabin. Since HeloTroops doesn't know "JTAC" it tells the entire group to wait outside and get stuffed. Now, it seems that you tried to force heloTroops to do your bidding with the edited code, and I'm surprised that it didn't eat your troops in retribution - the code that you changed was not the part that recognizes JTACs, it merely controls the defaulting if there was no unit type. I strongly recommend to revert to the old code. There's an attribute in heloTroop's config zone called "legalTroops" that defines this whitelist. Try and add "JTAC" there, and it should allow them on board. This doesn't mean that heloTroops nor theSpawners will allow you to control the JTAC features (since I just discovered this, I did not code for that), HOWEVER, other DCS features may allow you to control the JTACs, try the relevant communication menus, maybe you get luck (if you do get luck, please let me know so can claim that this is a cool new feature , not a bug).

Version 1.1h - 20240323 Another update for the same rare error that seems to crop up but I can't reproduce. I hardened the code surrounding the call that fails with an error note.

Version 1.1 - 20240323 Update fixes a small bug that could lead to issues should you kill elements of an enemy search party before the evacuee pops smoke.

Huh. Looks like I screwed that one. Will fix asap, thank you! -ch

CESAR Caucasus released! Thank you all for your kind feedback and help in stress-testing the mission. I now have put it up for download at ED's user files here: (cliketyclick) Enjoy, -ch

CESAR IN CAUCASUS "Et tu, Angele?" Version 1.1h - 20240323 Download: here (ED User files) Helicopter Combat Rescue (C-SAR) Sandbox [1-20 Players] =========================================== You are a "Battle Angel", a member of Blue's elite Helicopter Combat Rescue Team "Cesar". The battle for control of Mineralnye Vody has turned into a prolonged aerial conflict. You are tasked with retrieving downed pilots north of 'Cesar Ridge' and return them to a Field Hospital inside the safe zone (marked by red smoke). Expect opposition forces to be around that are searching for pilots, so perhaps bring a friend in a gunship. Pearly Gates, your command authority, is in contact with all downed pilots. They provide you with an updated list of all pilots requesting extraction and can vector you to evacuees. All evacuees have an ELT that you can use to 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 north of Cesar Ridge is contested, with lightly armed patrols roving the area, looking for downed pilots - expect enemy contact once you are clear of the ridge. 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 and should best be entered with a support ship. Mineralnye Vody's airfield is in Redfor's hands and actively reinforced, The area around the airfield is expected to be patrolled. Only approach the airfield if absolutely required. Attacking the airfield's defenses is outside the scope of your operational parameters and a sure way to attract superior retribution force. So, fly low, fly fast, and make sure the tree-tops are above you. And come back alive, Angel! --- FRQ: FARP London 225.0 MHz Weather: CAVOK, light winds Notes: If you also have one of the other "Battle Angels" missions and persistence is enabled, the missions share player's accomplishments. If run on a server, this mission auto-restarts every 8 hours. It's an endless C-SAR sandbox mission 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. Acknowledgements Voice acting by ElevenLabs Mission by cfrag Created with love and DML Uses StopGap Enjoy, -ch

What you can do is use the "delayFlag" module. Feed "flagA" into fireworks A (to start it) and into delayFlag. Set the delay to 30 seconds, and feed the delay's output to a new "flagAA" that you feed into fireworks AA. Now, fireworks AA will trigger 30 seconds after fireworks A.

Ah. I found the issue. Here's something that you probably missed when you read grouptracker's description: addToTracker: List of groupTracker zones. All groups that have at least one unit inside this zone are added to these groupTrackers. ... Now, your Zoos are all part of the same group "Ground-5". Hence all trackers track Group 5, because they each have one unit of that group inside their zone. And this is what happens (I imagine, it's what happened to me) When you trigger the menu items one by one, you trigger an explosion, and you trigger the flare. The explosion will kill the zoo. Since all zoos are part of Group-5, that group is still alive until the last Zoo goes. None of the trackers fires until that time When you fire the last by menu, the explosion kills the last remaining Zoo. Once second later, all trackers find that the group that they are tracking is dead, and each fire their triggers, which will set off explosions and flares at each zone once more. So, how do you resolve this? Make each Zoo part of its own group.

Silly question: why are you linking some of the the trigger zones (the trackers) to units? I'm still analyzing what's happening (probably dual firing of triggers: once when you trip the trigger via radio, once when the unit dies due to the fireworks in their vicinity), but that one has me stumped. Is this accidental or intentional?

yes and no. In the advanced waypoint options for groups, you may want to experiment. Try the 'disperse under fire'. Always remember that DCS AI was seemingly designed to frustrate mission designers, so don't get your hopes up too far.

well, there's an eye candy module called (you guessed it) called 'flareZone' that may be able to do something similar, merely trigger it at the same time as the explosion. Note, however, that effects like these are only good-looking al ground level, and when you are very close. However, this being a flight sim, you want to be neither, so it only looks cool for your camera if/when you create the B roll. In-cockpit you'd be further up, facing the other direction.

Huh. Yeah. .... actually, I was just testing if you are RTFM-ing. Right.... I guess I changed that after some kind but worried soul told me (a non-native English speaker) that 'blow' has some connotations that make uptight US people squeamish. So "boom?" it is. I'll update the docs

Ha! Great - you'll find DML to be quite simple to use once you get over the hump of 'signals' and 'flags'. Once you are done with this - and unless you already have begun doing so - we can explore 'stacking' modules, and of course tracker's ability to import other zone's units and the fact that we can use multiple trackers, and... (there's so much to explore . Try the messenger and/or valet next)