DML - Mission Creation Toolbox [no Lua required]

[Apothecary]

Hey cFrag

 

Thanks for all your support, I've made a lot of progress on my mission thanks to your DML tools. I've made a sort of random mission generating map with base capture.  Right now, my biggest hurdle is getting SSB to work correctly. I have a separate computer that I run a DCS server on and I've downloaded the SSB script and have tried every conceivable location script location (main director and \username\) to get it work correctly. I enabled the SSBclient in the mission, but it's still not blocking spawning of an airfield we are trying to capture. the test SSB mission works on my server as a side note.

Any advice would be greatly appreciated, thanks!

 

*EDIT*

Edited April 6, 2022 by Apothecary

[cfrag]

If the test SSB mission works successfully on your computer, I believe we are almost home, the rest is probably just a configuration issue. So let's try to figure it out

I have the ssbGUI.lua file placed in my (User)/Saved Games/DCS/Scripts/Hooks folder, by the way.

Probably the easiest approach is that you describe what you are trying to do, what you are seeing instead, and why you think that is incorrect. It would also help if you shared your mission and SSB script (so we can look at how you configured SSB itself). If you do not want to share your mission here, and still want me to take a look, simply pm me with a link to a download. With some luck, we'll have figured this out quickly.

Edited April 6, 2022 by cfrag

[cfrag]

Version 0.997 - 20220407

Feature Update: Viper - with a double youu

"Yo, cfrag - what can you see?"
I move the code-torch up, slightly increasing the light's reach. In the stygian darkness of DCS's deepest world.search() dungeon, a number of scenery objects rustle, skittering away from the light. 
"...nothing."

If you thought that getting objects into your mission was difficult, you haven't tried reliably removing them. DML's 'wiper' module is here to help you. It's easy enough to use: Place a zone, add the "wipe?" attribute, and the objects inside that you want gone will be gone. 

Well... mostly. Wiper works well with Mission Designer-placed units and static objects. Unfortunately, DCS is a bit capricious when it comes to other objects: flames, smoke, debris, scenery, and (worst of all) trees. Trying to delete these correctly can become a Herculean task. 

And so, the wiper module comes equipped with its own tool to shine some light into the dark dungeon: an inventory option. Designed to be used only during mission design/testing, it can nonetheless identify and report what it sees so you can remove only those objects that you intend to. Provided of course, that wiper can see them. Because, for reasons unknown, DCS is filled with objects that are there, but can't be identified, not even by wiper.

 

Other changes:

Documentation
    - Wiper 
    - Wiper Quick Ref
    - Viper with a double youu demo 

Modules
    - changer (pre-release)
    - wiper 1.0.0
    - unitZone 1.2.0 
    - smokeZones 1.1.0
    - xFlags 1.2.0 (still undocumented)

Demos
    - Viper with a double youu
    - smoke'em (update)
    - random glory (update)

Other
    - dcsCommon 2.5.9
    - countDown 
    - cfxZones
    - groundTroops

 

Enjoy,

-ch

 

Edited April 7, 2022 by cfrag

[crispy12]

Hi
Love your mod... it is a very interesting and different way of creating missions. Need some basic help regarding the cloner tool.

I would like to create random armoured convoys but to have them follow the same route. Is there a way to select the source as different units but get them to follow the waypoints of 1 unit group? So far it randomises the type of unit group (source: Group1, Group2, Group3). Group 1 has a waypoint route planned, group 2 and 3 do not.

Edited April 12, 2022 by crispy12

[cfrag]

1 hour ago, crispy12 said:

Is there a way to select the source as different units but get them to follow the waypoints of 1 unit group?

That's an interesting concept - choose route from one template, and unit layout from another. Since cloners currently support cloning multiple groups and types (a single cloner can spawn multiple ground groups, plus air groups and even ships, all with their own paths), I'll have to look into how this (accessing the correct path) could be made easily accessible for Mission Designers, and at the same time prevent an air group getting assigned a ground path. 

In the meantime, my approach to this is rather pedestrian: each group has their own path (which is almost identical). Since cloners remove the original groups at start, I then use a RND flag to randomly choose one of the convoys whenever they should spawn. 

Edited April 12, 2022 by cfrag

[crispy12]

29 minutes ago, cfrag said:

That's an interesting concept - choose route from one template, and unit layout from another. Since cloners currently support cloning multiple groups and types (a single cloner can spawn multiple ground groups, plus air groups and even ships, all with their own paths), I'll have to look into how this (accessing the correct path) could be made easily accessible for Mission Designers, and at the same time prevent an air group getting assigned a ground path. 

In the meantime, my approach to this is rather pedestrian: each group has their own path (which is almost identical). Since cloners remove the original groups at start, I then use a RND flag to randomly choose one of the convoys whenever they should spawn. 

 

Ok got it
I am currently using the way you mentioned

I asked this because I am familiar with MOOSE which has a function called InitRandomizeTemplate which does just that. It allows randomisation of groups which replace the original group but maintain the pathing. However i'm not a LUA expert so i prefer the DML method !

[cfrag]

Version 0.998 - 20220414

Feature Update: xFlags (Multi-Flag Testing/Combine), Radio Trigger (ME-DML Interface Glue)

Decisions, decisions, decisions. The last big, glaring hole in DML's lineup was a module that allows you to test multiple flags, and only trigger a flag when certain conditions are met. For example, when two of five possible targets are bombed, or at least three players have entered their plane.

 

Adventurous Mission Designers may have noticed the mysterious xFlags module that appeared a couple of weeks ago in the module collection. It's now ready to use, the documentation has been written, and a demo (also with full documentation) is in place.

Also in the mix: Radio Trigger, a comfortable interface for ME "Radio Items" is available that now can generate a flag trigger event every time that radio item is selected. The module is easily understood and even has its own demo (again, full documentation added for both)

Other than that, the new release brings some additional QoL items:

• Messenger has been simplified, saving one attribute. This may result in some notices when you start the mission, simply edit the affected messenger zone.
• Modules are starting to support "zone-local verbosity" (a debug setting) - this will be rolled out to all modules over time
• And finally, it's just a small thing, but it goes a long way: when you bang! a flag, you now also can set it to a fixed value (e.g. 42)

Changes in detail:

Documentation
    - xFlags
    - xFlag Field Day demo 
    - RadioTrigger documentation
    - Radio GoGo Demo 

Modules
    - messenger 1.3.0 
    - xFlags 1.2.1
    - changer (pre-release)
    - group tracker 1.1.1 
    - zones 2.7.4
    - radioTrigger 1.0.0
    - (module template) 
    - ssbClient 2.0.3
    - dcsCommon 2.6.0
    - groundTroops 1.7.5

Demos
    - xFlag Field Day (new) 
    - Radio go-go (new)
    - bottled message 
    - zonal count down 
    - Watchflags Demo
    - track this 
    
Enjoy - and Happy Easter!

-ch

[crispy12]

Thanks for the work

Im finding that I occasionally have issues triggering some actions. For example I can clonezones to consistently trigger when flags are increased, but sometimes it doesn't work consistently when I set trigger method to ON. 

 

I'm using Add radio menu, flag 1 true. 

When flag 1 true, flag 1 off - to switch it off again for a toggled F10 options radio button. 

Clonezones with " f? 1" to trigger.

 

Is there an easier way to make radio toggled triggers?

 

 

 

[cfrag]

On 4/18/2022 at 4:57 AM, crispy12 said:

For example I can clonezones to consistently trigger when flags are increased, but sometimes it doesn't work consistently when I set trigger method to ON. 

Indeed. I'll probably have to expand the manual on this topic to make it more clear, as DML's flexibility can be the Mission Designer's death . DML provides (or will provide when completed) two separate ways to communicate with other modules: one the the way it send signals (the output method that I call "DML Flag", and usually designated by the exclamation point "!" at the end of the attribute's name), and it describes what is sent when the module wants to convey information. This can be 'inc' (the most common, increases the flag's value), or 'On', 'Off', 'flip', a fixed value etc. 

And that's half of the picture. DML modules (those that have the "Watchflag" ability, also slated to be rolled out to all over time) look at their inputs (flag attributes with question mark "?" in their name) and try to decide if they should trigger. Again, most common is the 'change' method: the module triggers when the flag's current value changes. 

So let's put this together: Let's say you have two modules: 'sender' that sends on 'out!', and 'receiver' that waits for a signal on 'in?'. Now, let's put together some combinations to see how the output and input methods work together, or, sadly, sometimes don't correctly understand each other.

Before I begin, two perhaps important points on how DML works behind the scenes:

• When a module 'sends' a signal on the xxx! flag, it simply sets that flag to the value that the DML Method tells it to. In some cases, this can mean that that new value and the old value are the same.
• When a module 'receives' or listens for a signal on the yyy? flag, it regularly inspects the value of the flag. By default, a module checks once a second. IMPORTANT: The module only does does something if the new value is different from the last time it checked. Input flags require a value change before anything else.  

Now, with that said:

• The most common case is sender's DML Method is set to 'inc' and receivers Watchflag to 'change'. Any change put to the flag's value by 'sender' results in 'receiver' to detect the change in value, and then to trigger 
• Now lets change the receiver's watchflag method to '>4', and assume that at the start of the game, the underlying flag's value is zero (0). Sender's method stays at 'inc'. The first four times that sender sends a signal, the flag's value changes from 0 to 1, 2, 3 and 4. Each time that the flag changes, receiver sees the change, but ignores it. The fifth's time the flag's value is set to 5. Upon inspection, Receiver detects the change, sees that the new value is ">4" and triggers. Since modules check input flags regularly, it will not trigger the next time it checks the flag (usually once a second) because although the flag's value is >4, it did not change. Watchflags require a change on the watched flag to trigger. When Sender again changes the flag's value, this time to 6, receiver again triggers. And will trigger every time when Receiver sees that the flag's value has changed from the last time it checked.
• And now let's set receiver's watchflag back to "change", while sender is set to 'On'. Now, the first time sender triggers, it set's the flag to On (1). Receiver detects the change, sees the value '1', and triggers. Next time sender is triggered, it again sets the flag to On (1). The problem is, though: it already was On before. Sender does not mind, it has done it's job. Receiver sees that the flag has a value (1 = On), but since there was no change to the previous value (which was also 1), it ignores the current value and continues waiting for a change.

So here's the big take away: Watchflags trigger on change. If there is no change, the watchflag does not trigger. So if multiple modules have the 'On' method as their DML method and they all connect to the same flag, only the first flag to set 'On' will trigger a module listening for a 'Change'. After that, the flag stays on the 'On' value (1), even when the other modules trigger and set the flag to 'On'. To the listening receiver, the flag stays the same, and no change is detected, nothing is triggered. This is intentional: that way you are able to trigger a central reaction exactly once from multiple possible triggers: only the first triggers a reaction, all others senders no longer elicit a response. To make it more clear you may want to change the watchflag's method to 'On', but that's not strictly required

To make this perhaps a bit clearer, and to show just how potentially broad this concept of triggering on flag is: A receiver is connected to the IN? flag. That is to say, it is NOT connected to a particular sender module. Receiver doesn't care nor know about senders. All it concerns itself with is the value of the IN? flag, and when it changes. So you can (and often do) have multiple modules connect their OUT! ports to same flag. And you can have (and often do) multiple modules connect their IN? ports to the same flag. All senders and receivers work independently from each other, some can be connected or disconnected at will, and they will work together without ever knowing about each other. Only one thing is certain: if any sending module changes the out! flag, all listening receivers will react, and otherwise ignore the current value.

 

Edited April 19, 2022 by cfrag

[cfrag]

6 hours ago, crispy12 said:

Is there an easier way to make radio toggled triggers?

Have you tried the Radio Trigger module?  

Check the Radio GoGo Demo and Documentation, it might be just what you are looking for.

 

Edited April 18, 2022 by cfrag

[crispy12]

3 hours ago, cfrag said:

Indeed. I'll probably have to expand the manual on this topic to make it more clear, as DML's flexibility can be the Mission Designer's death . DML provides (or will provide when completed) two separate ways to communicate with other modules: one the the way it send signals (the output method that I call "DML Flag", and usually designated by the exclamation point "!" at the end of the attribute's name), and it describes what is sent when the module wants to convey information. This can be 'inc' (the most common, increases the flag's value), or 'On', 'Off', 'flip', a fixed value etc. 

And that's half of the picture. DML modules (those that have the "Watchflag" ability, also slated to be rolled out to all over time) look at their inputs (flag attributes with question mark "?" in their name) and try to decide if they should trigger. Again, most common is the 'change' method: the module triggers when the flag's current value changes. 

So let's put this together: Let's say you have two modules: 'sender' that sends on 'out!', and 'receiver' that waits for a signal on 'in?'. Now, let's put together some combinations to see how the output and input methods work together, or, sadly, sometimes don't correctly understand each other.

• The most common case is sender's DML Method is set to 'inc' and receivers Watchflag to 'change'. Any change put to the flag's value by 'sender' results in 'receiver' to detect the change in value, and then to trigger 
• Now lets change the receiver's watchflag method to '>4', and assume that at the start of the game, the underlying flag's value is zero (0). Sender's method stays at 'inc'. The first four times that sender sends a signal, the flag's value changes from 0 to 1, 2, 3 and 4. Each time that the flag changes, receiver sees the change, but ignores it. The fifth's time the flag's value is set to 5. Upon inspection, Receiver detects the change, sees that the new value is ">4" and triggers. Since modules check input flags regularly, it will not trigger the next time it checks the flag (usually once a second) because although the flag's value is >4, it did not change. Watchflags require a change on the watched flag to trigger. When Sender again changes the flag's value, this time to 6, receiver again triggers. And will trigger every time when Receiver sees that the flag's value has changed from the last time it checked.
• And now let's set receiver's watchflag back to "change", while sender is set to 'On'. Now, the first time sender triggers, it set's the flag to On (1). Receiver detects the change, sees the value '1', and triggers. Next time sender is triggered, it again sets the flag to On (1). The problem is, though: it already was On before. Sender does not mind, it has done it's job. Receiver sees that the flag has a value (1 = On), but since there was no change to the previous value (which was also 1), it ignores the current value and continues waiting for a change.

So here's the big take away: Watchflags trigger on change. If there is no change, the watchflag does not trigger. So if multiple modules have the 'On' method as their DML method and they all connect to the same flag, only the first flag to set 'On' will trigger a module listening for a 'Change'. After that, the flag stays on the 'On' value (1), even when the other modules trigger and set the flag to 'On'. To the listening receiver, the flag stays the same, and no change is detected, nothing is triggered. This is intentional: that way you are able to trigger a central reaction exactly once from multiple possible triggers: only the first triggers a reaction, all others senders no longer elicit a response. To make it more clear you may want to change the watchflag's method to 'On', but that's not strictly required

To make this perhaps a bit clearer, and to show just how potentially broad this concept of triggering on flag is: A receiver is connected to the IN? flag. That is to say, it is NOT connected to a particular sender module. Receiver doesn't care nor know about senders. All it concerns itself with is the value of the IN? flag, and when it changes. So you can (and often do) have multiple modules connect their OUT! ports to same flag. And you can have (and often do) multiple modules connect their IN? ports to the same flag. All senders and receivers work independently from each other, some can be connected or disconnected at will, and they will work together without ever knowing about each other. Only one thing is certain: if any sending module changes the out! flag, all listening receivers will react, and otherwise ignore the current value.

 

 

Regarding this receiver listening state, does that mean that a flag will have to be activated for the minimum "listening" period? I set the radio trigger to "true' and self switch back to "false" immediately upon activation. Is the inconsistent activation due to the flag being activated for too short a period of time?

I just saw the Radio Trigger module and am very excited... I was under the misconception that it was to do with the aircraft radio instead of the radio buttons

Thank you so much for such detailed replies. I really appreciate the effort you put in!

 

[cfrag]

1 minute ago, crispy12 said:

Regarding this receiver listening state, does that mean that a flag will have to be activated for the minimum "listening" period?

By default, a module polls it's input flags once a second, so if you don't change that setting with a config zone, the minimum duration is one seconds. Anything less, and you are inviting a 'race condition' - a situation where pure chance dictates if the time was enough for the flag to be read before it is reset. The radio trigger should easily resolve that for you

 

[Apothecary]

Hey cfrag, thanks for all the updates!

So as we've been testing the mission out I've been working on, I've noticed weird issues popping up related to flags triggering maybe when they shouldn't and along with the DCS AI acting dumb. I'm thinking this might be related to the degradation of the DCS code after running a mission for 7 to 8 hours on my server. Is there a way to make a mission save state and then relaunch the mission so we could continue where we fell off?

 

Thanks for all your work!

[cfrag]

30 minutes ago, Apothecary said:

Is there a way to make a mission save state and then relaunch the mission so we could continue where we fell off?

Alas, Mission Persistence currently remains the "DCS Unicorn". I have it on DML's roadmap, but it requires some foundation support from ED before I'll even attempt it. Currently, there is no way to reliably save a mission's state - you can't even save and then restore the day's time, much less a groups state. And you have to compromise DCS's security and grant DCS arbitrary write access to your storage. That's not DML's fault - it's a fundamental shortcoming of DCS itself, and most likely a reminder of just how old DCS is (put differently: it shows just how good the ED people were when they put in DCS's foundation when we see how far it has come). So no, currently there is no way to save a mission's state. IMHO, all currently existing implementations are clever, but fundamentally flawed. I hope that sometime this changes and we can save and resume our missions like real simulators  

[Sinclair_76]

I am trying to spawn a static RNLAF C-130 with the following attributes.

 

A couple of things are not going as I intend. First of all the C-130 spawns without the flag being set to 1. It has the wrong heading (still north) and is not Dutch (still USAF). What am I doing wrong?

[cfrag]

4 minutes ago, Sinclair_76 said:

First of all the C-130 spawns without the flag being set to 1.

I'll check the rest ASAP (when I have access to my main machine) - here just a quick comment: the Attribute "f?" = "1" means that whenever the flag "1" changes its value, the spawner will spawn. Is that what you intend? 

Also note: Things may be easier for you if you placed the Herc with ME and simply used a clone zone instead: they automatically use the objects you place in ME (including country), so you know that everything will be right during mission design.

 

 

[Sinclair_76]

1 minute ago, cfrag said:

I'll check the rest ASAP (when I have access to my main machine) - here just a quick comment: the Attribute "f?" = "1" means that whenever the flag "1" changes its value, the spawner will spawn. Is that what you intend? 

Also note: Things may be easier for you if you placed the Herc with ME and simply used a clone zone instead: they automatically use the objects you place in ME (including country), so you know that everything will be right during mission design.

 

 

Clone zone also works with statics? Cool!

[Sinclair_76]

Did this:

This is what came out...

What am I doing wrong?

EDIT: only happens with statics. dynamic appear normally

 

Edited April 19, 2022 by Sinclair_76

[cfrag]

Can you include the mission? I'll take a look asap

-ch

 

(I have the sinking feeling that I screwed up the turn code, but I'll have to verify)

Edited April 19, 2022 by cfrag

[cloose]

Hi cfrag!

I'm new to mission editing and DML. So the chances are big that I'm doing something wrong.

I do not get the Embarking/Disembarking commands working with troops and AI controlled helis spawned by clone zones. Is this expected, a bug or am I doing something wrong. Would be great if you could take a look at the attached mission where I tried to re-create the issue with a very simple mission.

Thanks!

Christian

DCS OpenBeta v2.7.11.22211
DML v0.997

DML Troop Transport.miz

Edited April 19, 2022 by cloose
Added some information

[cfrag]

42 minutes ago, cloose said:

I do not get the Embarking/Disembarking commands working with troops and AI controlled helis spawned by clone zones

Huh. Now that's an embarrassment. Looks like I completely forgot that. Embarking troops reference a helicopter group, and since the original gets deleted, the clones can't find it. Since I have very little experience with embarking troops, can I trouble you to throw together a functioning mission (no DML) that uses embarking troops and post it here, and I'll then add the relevant code to DML to support that as well.

 

[cloose]

vor 12 Minuten schrieb cfrag:

Huh. Now that's an embarrassment. Looks like I completely forgot that. Embarking troops reference a helicopter group, and since the original gets deleted, the clones can't find it. Since I have very little experience with embarking troops, can I trouble you to throw together a functioning mission (no DML) that uses embarking troops and post it here, and I'll then add the relevant code to DML to support that as well.

 

Wow, that was quick.

As I said, I'm no expert either but the attached mission w/o DML works for me.

On the infantry there is an "Embark to transport" action defining a zone:

The helicopter has an "Embarking/Disembarking" action defining which troops to load:

Hope that it helps and thanks for working on this!

Troop Transport without DML.miz

[cfrag]

23 hours ago, cfrag said:

(I have the sinking feeling that I screwed up the turn code, but I'll have to verify)

Confirmed, re-produced and fixed. A single-character typo in dcsCommon (dang!). Will be rolled into the next code drop planned for Thursday.

 

[cfrag]

Version 0.9985 - 20220421

Feature Update: civAir (Automatic Civilian Air Traffic)

So... Civ Air. That module has been included with DML since forever. It's one of the modules that predate much of DML itself. Accordingly, it did not fit well with DML's UX. I took multiple attempts at writing the docs, until I finally decided to rip out most of the code, streamlined it, and made it much easier to use - made it a DML module, to be exact. 

Now it just, uh, flies. It's simple to set up, works straight out of the box, and by adding just a couple of zones you can customize it to provide your mission with nice, believable and efficient civilian air traffic - for the entire duration of your mission - even if that mission takes days to complete (in other words: it's server-safe). There's not just one but two quick demos to show just how easy it is to add civAir to your mission, and how quickly you can curtail it to your needs. 

The docs have also been updated, so now there's nothing to keep you from making your mission come to life even more than before.

Other changes include a fix for a silly typo that bugged clone zones for objects when using turn, another typo in SSB client, and small QoL enhancements to unitZones, xFlags, delayFlag and cfxZones. The changer module is also nearing completion (it's still not quite done). In all, though, DML is progressing nicely towards a full "One Dot Oh".
 

Documentation
    - added sections on methods and polling
    - CivAir 
    - Virgin Air demo / Air Caucaus II demos 
    - CivAir QuickRef

 

Demos
    - Virgin (Civ) Air
    - Air Caucasus II 
    
    
Modules
    - unitZones 1.2.1
    - cloneZones 1.4.2
    - dcsCommon 2.6.1
    - cfxZones 2.7.5
    - delayFlag 1.2.2
    - xFlags 1.2.2
    - changer (still pre-release)
    - SSB Client

 

Enjoy,

-ch

 

Edited April 21, 2022 by cfrag

[crispy12]

Just wanted to let you know that cfxGroudTroops.lua is also mispelled
It still works but it's just been bugging me for days...