cfrag

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)

I think it would greatly help if you elaborate a little bit more on your idea, so it is easier for poor old me to understand what you are looking for, and perhaps come up with good alternatives. Now, what I *think* I understood from above is that you want the following order of events: you have infantry on roofs in Poti once they are destroyed, a gun emplacement appears that the players must destroy once the gun emplacement is destroyed, some major explosions happen as a dramatic effect Now, as it turns out, your mission suggests otherwise: you are not tracking the infantry, merely the Zoo 23 and all units are initially visible. So all we need is to apply what we learned from the initial mission and apply it to the Zoo (track it with a tracker, exactly as you are doing now in the update you posted), and trigger a different module than smoke when the emplacement is dead. There's really not much to it-except perhaps for picking the effect that marks the demise of the zoo. We already know how that effect will be triggered: by a signal on the 'done' flag that is fed from the 51tracker. DML has a module called 'ground explosion' that fits your bill (and that you already found -- note: there was a silly bug (typo) in groundExplosion that I've fixed -- if you encounter those, please tell me immediately so I can fix them quickly and you don't have to wonder what's going on): it creates 1 to many explosions inside a trigger zone. Please look up groundEplosion in the docs, and you'll see what the attributes do. Main thing: the 'boom?' input is wired to the flag 'done' which will receive a signal from the tracker once the Zoo is dead. One particularly nice thing about DML is that if one module can trigger on a signal flag (like 'done'), so can many. So I'm updating the one trigger zone '51explode' to attach the ground explosion module, and wire it to 'done', then I simply copy/paste the zone and place it over other areas. The result is are multiple explosions in different locations that ALL trigger at the same time. Very visceral (make sure you aren't too close in your helo), very cool, difficult to miss. And something that you can't do that easily in vanilla Oh, and since I'm lazy and don't want to fly there every time and battle through everything to see if everything checks out, I've added a new radio menu item to the 'other...' communication branch (using vanilla ME) that simply sets done to 1 (one) when you select it. This triggers the explosion. So all you need to do is enter the Huey, select map view, pan the map to Poti, select one of the units, press F7 to view everything. Then hit communications-->other-->Set Flag "done" to 1 and enjoy the fireworks. You may want to tone down the explosions if you plan to be there in a helo... 000 DML Test_C - CFR.miz

There currently is no way in DCS scripting to spawn weapons, just their launch platforms (e.g. ships for cruise missiles). That being said, your question reminds me of the old adage that "a guy walking into a store to buy a drill does not really want a drill: he wants holes in his walls". So, why do you want cruise missiles to spawn? Unless you want to engage those weapons themselves, if you need explosions in some locations at a specific point in time, DML has the tools for you:: groundExplosion (which can also do airbursts).

Version 2.2.0 - Update 20240320 Often, it's the small things. Last update, 'all' we added to DML was the ability for persistence to share data. A small thing, but it opens a lot of fun new possibilities. This update adds another very small change than can greatly multiply the possibilities. Background: DML uses attributes to control how how modules work. Mission designers decide when they create the mission, what values to use. If they want to introduce an element of random, some attributes support ranges (for examples "5-9" which means "a value from 5 to 9"). There is one 'type' of attribute that mission designers to turn something on or off. In Geekspeak, attributes that have only two values to choose from are called 'boolean'. Cloners, for example, have an 'onStart' attribute that controls if a cloner should run a clone cycle on start. Possible values are 'yes' or 'no' (or 'or'/'off','true'/'false', '1'/'0'). Well, no more. As of this release, you can set this value to 'MAYBE'. In that case, DML rolls the dice at mission start, and sets the attribute randomly to either "yes" or "no". This allows you to randomize any attribute that uses a formerly boolean (true/false) attribute. Note that setting this 'maybe' to either 'yes' or 'no' happens once, at mission start, and that value remains set to this value for the entire duration of the mission. It's re-rolled every time that the mission restarts. So why is this such a big deal? Because in an instant, you can now randomize many missions simply by changing the value of a formerly true/false-values attribute to 'maybe' and have your mission randomize its setting every time that the mission starts. The other big change is that finally, after a lot of stress-testing I am able to add the ability to intelligently drop units into densely populated areas (like cities in Syria or Sinai) with a good likelihood that they are not dropped on top of buildings. This is controlled by the new 'inBuiltup' attribute that you can use to control the minimum free space that a unit must have around it. Changes is Detail Manual Main - boolean "maybe" - changes to cloner Demos - (none) Modules - cfxZones 4.3.0 support for "maybe" - cloneZone 2.1.0 - despawn option - inBuiltup attribute - csarManager 3.2.5 - useRanks option - groupTracker 2.0.1 - better verbosity - PlayerScore 3.1.0 - shared data - rndFlags 2.0.1 - better verbosity - sequencer 2.0.0 - dmlZones - stopGaps standalone 1.1.1 - filter "start from runway" - stopGap 1.1.1 - filter "start from runway" - valet 1.1.0 - hysteresis now time-based Enjoy, ch

Definitely. There are many ways to do this, and you don't even need DML to do that. There are 'vanilla' ME trigger conditions that can do that for you, albeit using them is (at least to me) somewhat more of a hassle than what DML offers. We'll get to that soon - I like your mission's idea because they are straightforward, and to a point. In ME (and DML builds on that) we always separate things that units/troops do (fighting), and checking if some situation happens and then tell DCS to react in a way that modifies the mission, for example spawning new troops, blowing stuff up, or adding smoke. The first part is DCS's turf, we (mission creators) currently cannot change how AI works. The latter part is where DML offers us a ton of help: doing stuff. DML can't work miracles, it just makes many complex tasks more accessible to average (and in my case: lazy) mission creators. Let us look at the situation that you describe that we are looking for: "all the troops are eliminated". To nit-pick (which is unfortunately necessary for the task of writing missions), by 'all the troops' you mean the red units that you have placed on roof of buildings in southern Poti. And by 'eliminated' you mean that they are dead. So the situation that we are looking for is 'all those units that I placed on the roof of buildings in southern Poti are dead'. And when that happens, we want to do something. Let's say we want to show some blue smoke close to those buildings (we could also display text, play sound effects, or initiate fireworks - something I only recommend in a mission at night time - or, or, or. The possibilities are limitless. So the description of 'all the units that I placed...' is the condition WHEN something happens. In vanilla DCS, this is put into a rule trigger's condition and is evaluated roughly once per second, for the entire mission. In DML, you don't use rules as much as you simply place a specialized module that also perpetually looks for these things, except you don't write those rules in logic code, the module implicitly looks for these because that is why they were made. Once we determine that a situation that we describe has happened, in vanilla DCS the 'Action' part of a rule is enacted. There are a lot of things that you can put into DCS's actions, and some of them are even nicely documented. DML, on the other hand comes with very specific (and often helpful) things it does when the wanted situation arises: it spawns troops, sets off fireworks, starts smoke, plays sound and/or text, blows stuff up, etc. What makes DML a bit easier to use is the fact that since we use trigger zones to place modules, we not only control when stuff happens, but WHERE. This allows us to rapidly move our effects around. Oh, and usually use copy/paste to duplicate this all over the map (that's 90% of the work I did for the 'Angels' mission: copy/paste DML zones ) Now, let's come back to WHAT you want to do when 'all those troops' are dead: let's say that you want to start some blue smoke. DML has a 'smokeZone' module that does just that: it places smoke on the map. It has some nice-to-have additions that make it (IMHO) easier to use than DCS's plain colored smoke, but that's just the icing. So, let's use a smoker and place it close to the houses with enemy troops on top. I name that trogger zone 'We are done here'. Since this is DML, we also add a couple of attributes. If you look up smokeZones in the docs. you'll find that 'smoke' tells DML that this is a smoke zone, and the value 'blue' tells itg that the smoke to produce should be colored blue. The attribute 'paused' tells DML that the smoke zone should wait for signal to start smoking. Meaning: it will not produce smoke when the mission starts up but waits for a signal to start smoking. Which signal? Glad you asked. The 'startSmoke?' question tells DML that the smoke zone should keep its eyes peeled on the flag named 'done', and when the value of that flag changes, it should start doing its thing. And the last sentence is 90% of what DML is: waiting for a signal, and then doing what it should do. A smoke zone smokes. Cloners clone. Messengers send text or sound messages, etc. But how do we find out that "all the troops" has happened? There are lots of ways to do that. In vanilla DCS, you'd create a new trigger rule that concatenates the conditions "GROUP DEAD (Ground-1)" and "GROUP DEAD (Ground-2)" and when this has happened it will increase (change) the value of the flag named "done" Above produces a "signal" (a change in the value of a flag) on the flag named "done". That will work, is quite straightforward, and a classic example of how you can easily integrate DML with vanilla DCS. When groups "Ground-1" and "Ground-2" are dead, the value of the flag named "done" is changed. The smoker, which is always looking at the flag named "done" sees the change, and reacts: blue smoke starts erupting from the center of the trigger zone "we are done here". Above is "the vanilla way". Definitely not Mandalorian: it's also boring, so let's kick this up a notch: let's use DML's built-in abilities to automatically provide a signal when it's time. The problem (for you right now, but probably not for very much longer) is to know which modules can produce such a signal at the right time, and when. If we browse the shock block, you'll find a module called 'groupTracker'. It's sole raison d'etre is to provide signals if something happens to groups that are inside the trigger zone. So we place a trigger zone over the two groups on the buildings, call it "Tracker" and add attributes: "tracker" tells DML that it should create a tracker with the name of this zone (which is "Tracker"). "trackWith:" tells DML that the units inside this zone should be tracked with a tracker named "Tracker", which happens to be the tracker attached to this zone (you can attach the "trackwith:" attributes to other zones as well to track multiple groups with one tracker, a quality of life thing). As a result, we tell DML that it should track all the groups inside the trigger zone with the tracker we attach to this zone. And "allGone!" (see the exclamation point. That's DML for telling you: this is a signal generator) tells DML that when all the groups that are being tracked are dead, it should send a signal (change the flag's value) of the flag named "done". That completes this small 'automaton": tracker tracks until all the units are dead, and then sends a signal on the flag named "done". smoker waits until it receives a signal on the flag named "done", and once it does, it produces blue smoke at the center of the trigger zone. You may have noticed that the smoke zone "we are done here" has come to sit inside the "Tracker" trigger zone. This is just to show that this is of no consequence at all, and you don't have to mind other trigger zones when building with DML. And that's it. Now, there are way cooler things that you can do with DML, and my challenge to you is to re-build above with a cloner (yes, it can place units on roofs - not actively, it simply places them where you have placed them in ME), and use the cloner's ability to signal when all clones are dead. Can you do it? Have fun! 000 DML Test_B - CFR.miz

Someone may have slightly misrepresented what DML can do. Those zones that you see is what tells DML where, when and what to do. But DML rarely controls troops - they do what DCS's AI tells them what to do. So, for example, you can use a 'cloner' from DML to spawn troops at the location that you put them in Mission Editor and then let them do theirt thing. For example, you place troops on rooftops exactly how you like them. Then place a "cloner" zone above them, and they disappear - until you trigger the cloner, and they magically apear, the perfect ambush. Triggering is where DML excels at - and randomizing the spawn locations. So, DML might work for you, and it can greatly shorten the time it takes to create missions like that. The downside: you need to learn a bit of DML before you can use it, so it's a mixed bag. Personally, if it catches you interest, look at some of the demos that come with it, and the descriptions - each demo has its own chapter in the shock block - then try for yourself. But beware... designing missions can be exceedingly addictive.

Version 1.1.1 - 20240318 This version adds filtering for client planes that start "From Runway" Enjoy, -ch

There may be a couple of issues with your code: You may have been bitten by one of the many idiosyncrasies of DCS. Remember that StaticObject.GetByName() works on the name put into the "UNITNAME" field for static objects, not the "NAME" field. That silly issue has gotten me more times than I care to admit More to the point, though: when does rmBaseDamage() execute? Because, if at that point a static objects was completely destroyed, it will no longer respond to getByName(). Meaning: it may well be that only those buildings respawn that weren't completely destroyed. What you would need to do is to read all bases fully at mission start, cache their description, and use that to re-spawn them all. Hope this helps, -ch Wait... two more things to check: make sure that those trucks are also static objects when you spawn them, make sure that the "dead" flag isn't set to true (as it can be if you getDesc() ), else most static vehicles spawn without a model.

It would surely possible, but it would be a bad experience all around. The reason for that is that DCS has no API for unit-individual commands, just for entire groups. So all group members have the menu items available, and only that one plane would elicit a response. It would also introduce a source for frustrating and difficult to detect bugs (name-matching from units to what you specified in ME), and some more checking in the WP code (not that difficult). So what I would prefer to do is wait until ED get around to introducing unit-specific missionCommands (after all, it only took them some 10 years to do the same for textOut() and soundOut(), even though it currently does not work correctly in multiplayer yet), and then re-code WP (and all the other modules like HeloTroops, csarManager etc) to support single groups without ugly hacks.

Unfortunately, DCS (currently) has no concept of a player in the game; that is only an attribute of a plane. In your case, though, you can get around this since these x-commands are highly type specific (and I don't know if they work in multiplayer at all). So since you know which planes are client/player planes, and you know their type and which is their unit, you can go the old 'unit in zone' route. And yes, it would be great if there were a) a standardized player API b) a standardized cockpit command API We can only dream...

I think there are multiple ways to approach this. have the helos bring the troops along (using helotoops) and have the players drop them where they deem correct If you are going the route that a helo that lands triggers a spawner or cloner, and run into the problem that multiple landings result in multiple triggering signals to the spawners, use an output method from the LZ that will not cause multiple spawns, e.g. 'on'. Note that in this case you may want to use individual LZ and spawners for each helo.

Hey everyone, I'm putting the final touches on my new 'combat rescue' sandbox mission "Cesar Caucasus" - if you'd like a sneak peek, provide feedback, and help stress-testing the mission, please head over to "cfrag's DML testbed" (a hosted server, no password) and take your favorite helicopter out for a spin. In short: pick up the blue guys by landing close to them, then bring them back to the field hospital (marked with red smoke). Be advised, this is a COMBAT mission sandbox. If you feel that you are a member of the sierra hotel club, cross the yellow line to the north. If you do, bring a buddy. Please provide any feedback here or pm me. Thanks to all (especially @bitboy and @HungryCoyote) for their feedback - much of it has found its way into the mission. After the stress-test completes in a couple of days, I will make the mission available to everyone for download from ED's user files. Thanks, -ch

You know I always value your opinions, @draconus, even if passive aggressive and dead wrong I surely won't oppose wishes on a wish list. Like diamonds in the rough; I'd like to help and polish them to find the valuable core. That elusive core has evaded me on this one so far.

Possibly. Then again, I've written my fair share of missions. If you are in a fast mover and eject, you usually are some 50 km (30 miles) away from a friendly FARP, usually a lot more. If your CSARS are based on an airfield, way more than 50km. So, let's assume that your hot-started helos can be manned within 5 minutes of a splashdown (I'm assuming that your CSAR pilots aren't sitting in their cockpits doing nothing, but can end some other job within 5 minutes -- quite not likely at al). So, ingress 50 km at 200km/ is still at least 15 minutes (more if the LZ or ingress is hot). Pickup & return trip another 15 minutes. Best case scenario here, the downed pilot must wait more than half an hour and can't do anything in that time. I've written missions where the players rescue downed pilots before they can fly again. The consensus was 'replace the downed pilot with an NPC and let some player eventually get around to rescue them' (the NPC). Players hated waiting on the ground for the helo to arrive, and consequently preferred (and made sure) not to survive the downing (meaning they did not eject even if they could). Being the evacuee is no fun and boring. If you have 2 hours of quality time this week, you would not want to spend a quarter of that twiddling your thumbs. I'm sure that there will be the occasional player who likes this, but my impression is that they will be few and far in-between.

That scenario where the player sits on the ground and waits for hours on end to be picked up and flown to a base - that is MP only. How is that going to be a good game experience for the person who first waits and then is being flown home?

That's a distinction without meaning to me. You are either paying for an FAA (or other) licensed 'real' sim for your job (or advanced hobby), or you are playing a game to entertain yourself and spend your quality time. If you want to 'hardcore' it in your quality time, by all means, have at it. But if I don't want to, please don't make me. I happen to like the option of hot-starts, labels, external views and field repair. They - to me - make DCS a better game. So we can completely fantasy our way around that (a multi-year education, medical and mental fitness, political and national affiliation), but we should not fantasy about some grass-lenient gear? Seems a bit arbitrary to me. To me, it's "whatever makes a better game". And let me bring up the "Progressive Overlay" that people enabled for me when I had the opportunity to PIC in a (fully licensed, full motion, and prohibitively expensive) A340 sim. That overlay is not available in reality, yet it helps sim pilots (during training) to find their way around unfamiliar airports without stressing the Tower guys (who, as sim crew, aren't familiar with all airfields either). So even professional sims can bend reality. That's exactly why we use sims: because it is possible to do so there. So, as long as it's optional, I feel it's great to have things that are not 100% realistic - as long as it increases enjoyment for some.

Not IRL, no. Luckily, DCS is a game and provides the "three-minute-repair" that can bring a FUBAR Mudhen to stellar, flight-worthy condition. So why not a plane that accidentally was driven off the ramp by an unlicensed pilot? Remember -- this is a game, and we can do stuff that isn't realistic (like flying a jet fitted out for Armageddon without being licensed nor authorized). Actually, that's one of DCS's strong points. So even if it wasn't realistic, IMHO it's still something worthwhile to discuss.

I usually start my Vive via Steam first (which will run the SteamVR Home app). I then switch the Audio back to normal (I don't like the Vive's headset) Then I start DCS, and I'm presented with multiple option, TWO of them relating to start DCS in Steam VR (one as single-threaded, one as multi-threaded). I usually choose MT (you will have to scroll down the options, especially if you also get the Oculus Options which I do NOT use). And yeah, once you go VR there is no turning back. DCS is the killer app for VR (well, that, and Alyx). MS can't touch this.

You can, but not in ME - you can spawn units via script. Remember to convert lat/lon to DCS's internal coordinates with the coord.LLtoLO() method.

Yes, the new model comes with an FM antenna and internal audio cassette player pre-installed.

TBH, if this was entirely optional and supported in VR, I'd love this as well. I feel the same, even though I don't need a shutdown of the plane at all. Simply being able to exit the plane (or chopper!) in its current state, even if we could only stand in one spot - silly as that may seem, but that would scratch an itch I have.