DML - Mission Creation Toolbox [no Lua required]

[waterman]

Hi i was playing around with these settings i found on the forum a while back you may find them useful for the detection check out the pics have fun !

They do work ok.

a) This trigger detects the moment when both left and right main wheels are compressed at touch down. The trigger zone assures me that it happens only on the carrier:

b) This next trigger is the same, but also detects if the aircraft is at rest on the deck: three wheels compressed and speed less than 60 (to account for the carrier + wind speed)

[Hallsy]

4 hours ago, cfrag said:

It needs DCS to issue a 'landed' or "runway touch" event, whatever those may be. From my tests, DCS regards an aircraft as landed when the main gear (and probably nose/tail-gear) or skids (helos) are firmly on the ground for longer than a second. Moreover, DCS seems a bit particular when invoking those events for fixed-wing (helicopters can generate those events outside of airfields; fixed wing only in some versions of DCS. This may become relevant if you are setting up missions with road-based runways).

So whatever is coded into DCS, the LZ module uses that to determine a landing / runway touch-down. This arrangement may make it difficult to count the number of 'hops' -- i.e. if players bounce on their landings it may only register as one landing. Also be aware that an LZ doesn't differentiate between players, so counting touches on a runway doesn't work in MP.

I appreciate the response. This is exactly what I expected. I just wanted to confirm it was a DCS side limitation. Thank you!

[Mistermann]

5 hours ago, waterman said:

Hi i was playing around with these settings i found on the forum a while back you may find them useful for the detection check out the pics have fun !

They do work ok.

a) This trigger detects the moment when both left and right main wheels are compressed at touch down. The trigger zone assures me that it happens only on the carrier:

b) This next trigger is the same, but also detects if the aircraft is at rest on the deck: three wheels compressed and speed less than 60 (to account for the carrier + wind speed)

Those only work in SP - in case that matters.

[MrOrangePZ]

Hi, I really like the work you do! Thanks for that

I have a request regarding the valet module. I really like the idea, but what I am missing is the ability to activate and deactivate these zones. I use that on my trainingsmission when people enter a range, it should only be active when the training range is active otherwise it should be not tracking entering and exiting players.

[Recluse]

@cfrag Quick question, though I may answer it myself by just TRYING IT OUT...but just in case:

 

I was messing around with the CFRAG Marianas Proving Grounds, and noticed that when starting up, the Valet module (I assume) provided stats on the aircraft I had flown previously (even previous sessions, via Persistence).

I didn't notice anything special in the valet statement, so is this automatic when persistence is enabled or did I miss another Trigger zone somewhere??

 

Thanks!

[cfrag]

9 hours ago, Recluse said:

the Valet module (I assume) provided stats on the aircraft

It's the Scribe module.

9 hours ago, Recluse said:

is this automatic when persistence is enabled

Yes

On 4/7/2025 at 5:29 PM, MrOrangePZ said:

the ability to activate and deactivate these zones.

Valet currently does not support this. You could assemble this functionality with unitZones and messenger, messenger can be de-activated.

[cfrag]

Version 2.4.7 - minor update - 20250410

I'm still reeling from the near-trollish low quality of DCS' new 'Save State' function that is generating a steady stream of bug reports from people who trustingly used 'Save Mission' and it then destroyed their mission. I'm exasperated that anyone at ED green-lit releasing to production something that is this obviously broken.

DCS can't "save state", period. Create a new mission, add a vehicle, set ROE to 'weapons hold'. Start mission, immediately save mission, run saved mission. The vehicle's ROE state now is weapons free. Failing on such a trivial level can perhaps be explained, but IMHO it's inexcusable if you want to claim any level of quality or professionalism.
Furthermore, calling this function "SAVE MISSION" in the game's UI to me demonstrates a strong disconnect between ED dev team's abilities and their users' expectations. Communication is difficult, I know. This is a complete failure, though. I strongly recommend that ED removed "SAVE MISSION" from the UI for now. 

So I spent the last weeks telling upset players some truly sad facts: No, DML isn't broken - DCS's "Save Mission" feature is. No, unless you have a backup, the mission that you crafted is gone, you overwrote it with "Save Mission"'s broken version. No, I'm not joking, the joke's on you, and ED are the jesters. No, I don't think it funny either.

I had very little time (and energy) left to do actual work on DML. The biggest item is that I provided a playerScore API for  @Special K's Bot - and that's completely under the hood.

Changes
Documentation
    Manual 
    QuickRef
Demos
Modules
    csarManager 4.5.0 
        - better playerScore integration 
        
    heloTroops 5.2.0
        - better playerScore integration 
    
    playerScore 5.3.0
        - API / callbacks 
    
    unGrief 2.0.1 
        - DCS bug hardening 

-ch

Edited April 10 by cfrag

[Recluse]

 

5 hours ago, cfrag said:

It's the Scribe module.

 

Ahhh!!! Thanks!! I saw the scribe loaded but I didn't think to explore it. Always something new in the M to RTF!! 

 

Thanks as always for your constant DML maintenance and tireless support here!!

Sorry that DCS keeps breaking stuff that you have to fix!!  I was anxious to try the new SAVE module, but after reading your take on it, I decided HARD PASS for now especially since DML does it all, and more, and better!!

[Penfold-88]

good afternoon 

what do i need to change to make them go to there waypoint rather than guard ?

regards

 

 

[DD_Friar]

@Penfold-88

Salute

The beauty of using DML for troop movements is that you do not need to give them way-points, just a zone to head for.

If you are generating them via the spawner module and are picking them up via helicopter (that many troops from a Huey is possible but unrealistic  "just because you can does not mean you should" )you give them the parameter "orders". the "wait" prefix means that the action will not be activated until you have deployed them from the helicopter.

The values for this can be

wait-guard  - Places the group in guard mode. It will actively look for enemies and, upon detecting them, will move towards and engage the enemies. After destroying all enemy units, the group goes back to guard mode. If given, range defines to what distance (in m) enemy ground units are detected.

wait-captureAndHold - Like “attackOwnedZone”, except that the units choose the nearest enemy/neutral zone once, and then move to capture it. If the zone is captured, the units continue to move to the zone, and then remain there, switching to “guard” orders. Respects moveFormation

Note - This is the mode I personally like to use and was instrumental in getting cfrag to add it as otherwise using "guard" if you have enemy zones close to each other and within the detection range the troops will keep going from one zone to the next. Be careful with this mode however, it has no range restrictions. Drop you troops off from the helicopter and they will march all the way across the map if they need to !

wait-attackZone - Move to attack the zone referenced by name in the ‘target’ attribute. The name of a Zone is the same as you entered in the “Name” field for the Trigger Zone in ME at the very top. So, to attack the zone defined above you would first enter “attackZone” as value for the “orders” attribute, and then enter “Red Two” as value for the “target” attribute. If the target zone can’t be found, the group’s orders are switched to ‘guard’

Note - I also like to use the "moveFormation" attribute as well. By default the troops will march off in a single file line. This means that when they encounter the enemy only the guy at the front of the line has line of sight and will open fire. I personally like to use "EchelonR" which gives them all a sight and the change to open fire.

Hope this helps.

All of this is in the excellent user guides by the way.......just saying......

Regards

Friar

 

 

Edited April 13 by DD_Friar

[Thunder Chicken22]

I am coming back to DML after quite the hiatus. I am trying to set up the LZ zone to detect landing event when a group or one of the group lands at Kutaisi then fire a flag to spawn the next flight. I have updated all the DML modules but can not get LZ to work properly.  As you can see in the attached message I am getting this weird error about the LZ diameter.  I get this regardless if it is a circle or a quad point.  Via the debugger I can see that the LZ zone is not banging the landed! flag.  I can manually fire the flag in question via the debugger and the next event (a spawn) works. So there is a issue with the LZ zone and I can not figure out what it is other than this error.

Edited Monday at 01:35 PM by Thunder Chicken22
removed bad link

[cfrag]

13 minutes ago, Thunder Chicken22 said:

As you can see in the attached message I am getting this weird error about the LZ diameter.

It's not weird, merely an artifact I left in because goldfish brain. It should not be a factor in the issue.

The zone looks fine, I can see no obvious mistakes so hopefully we can resolve this quickly. If you can't get it to run, please pm the mission (no mods please) to me so I can have a look.

[Panthir]

Hello Gents. At first I would like to wish to Have a Happy Easter for those that are celebrating.

Then I would like to share with you a nice idea that could promote realism especially to those virtual Squadrons that they are keen in organizing dynamic campaigns or sequential missions with limited assets and weapons. 

In DCS world when you land you can refuel and rearm ASAP and be in 5 minutes airborn. In real life rearm, refuel and maintenance is by far more time consuming than in DCS.

During the previous days I worked with CHATGPT for such a script (it is still under development). Middle East Maintenance.lua
The idea is after an aircraft or helo is landed and is stopped for example after 30 seconds, the specific asset to automatically be set under maintenance (the player is removed from the slot and the aircraft from the warehouse for a specific time eg 20minutes). After this time passes it will be available. In this context when you have in an airbase or farp 2 UH-1 in the warehouse, if both of the have just landed you will not be available to get a slot until they finish their maintenance. 

Such a module (working with dynamic spawns as well) will be very useful in PvP missions or campaigns that available assets are in limited numbers, so the teams will have to plan in detail their usage in operations, if they know for example that when an F-16 lands will be available rdy after 30m. In this context, if you have available 8 F-16s at Incirlick and you decide to take off all of them for tasking, you will know that when they land, for the following 30 minutes they will not be available to fly. This realism will finally give to the coalitions the missing windows of opportunity.

I am very confident that Cfrag's unstoppable mind will find a way to implement a module to simulate maintainance. 

Edited 8 hours ago by Panthir

[DD_Friar]

@Panthir

If there was a vote for your idea, I am afraid it would be a thumbs down for me. Mine, like many of my squad mates, flying time is limited. I would not want to participate on a server where if I come into land I have to wait 30 mins before I can fly again. We generally do not even bother with cold starts on our planes.

Personally, I think the requirement for this feature would appeal to a tiny, tiny percentage of players.

 

[cfrag]

10 hours ago, Panthir said:

During the previous days I worked with CHATGPT

I think that's a Bad Idea, you'd get more and better traction if you did it alone, without AI. This may change in a couple of years, but today with mission scripting, the AI results are bad indeed. They might give you an idea where to look, but only if you are already good at mission scripting (which you may well be, dear @Panthir, since, as I know, you have a lot of experience with mission building  ) 

10 hours ago, Panthir said:

The idea is after an aircraft or helo is landed and is stopped for example after 30 seconds, the specific asset to automatically be set under maintenance

That's easy enough accomplished, and using zones you can put in checks to ensure that the aircraft must also be close enough to a base's maintenance shop. Using a slot blocking mechanism, you can then boot the pilot and (unless it is dynamically spawned) block the plane's slot. 

10 hours ago, Panthir said:

the player is removed from the slot and the aircraft from the warehouse for a specific time eg 20minutes). After this time passes it will be available. In this context when you have in an airbase or farp 2 UH-1 in the warehouse, if both of the have just landed you will not be available to get a slot until they finish their maintenance.

Implementing that isn't too difficult, merely some busywork. The real issue lies somewhere entirely different: I discovered (and this is confirmed by other server owners) that players positively loathe missions that try to impose rules on the availability of aircraft/slots. As a result, players won't return to the server, and the mission gains a reputation as 'not fun' or 'player hell'. The mission is kicked off the server's rotation. Not for being a bad mission, but because it tries to assert control over the players who come to play, not bossed around.

DML has some modules that can do similar things: "ungrief" punishes fratricide, "taxipolice" punishes speeding on taxi ways, "limitedAirframes" limits the number of losses per slot. While the ungrief module is accepted (antisocial behavior should be dealt with swiftly), "limitedAirframes" is begrudgingly accepted by roughly half of the players, "taxi police" has almost universally been deemed excessive. There are some players who appreciate enforced order. The majority does not, however, and they avoid missions that are known for imposing (what players deem to be) restrictions on their playstyle. Since server owners want their servers to be popular, they eschew missions that players dislike. Mission creators (like I) want their mission to be popular, and so we would not add a module that is known to cut the potential popularity by 90%.   

Long story short: it's not that difficult an idea to put into reality, and it's currently not a direction (rule enforcements) that I want DML to take.  

[cfrag]

Oh, and of course, as @DD_Friar kindly chimed in, there's the matter of wasting a player's quality time through enforced wait states. That of course ranks even higher than the others in the book of "unforgivable mission creation sins"

Edited 4 hours ago by cfrag

[Panthir]

1 hour ago, cfrag said:

I think that's a Bad Idea, you'd get more and better traction if you did it alone, without AI. This may change in a couple of years, but today with mission scripting, the AI results are bad indeed. They might give you an idea where to look, but only if you are already good at mission scripting (which you may well be, dear @Panthir, since, as I know, you have a lot of experience with mission building  ) 

That's easy enough accomplished, and using zones you can put in checks to ensure that the aircraft must also be close enough to a base's maintenance shop. Using a slot blocking mechanism, you can then boot the pilot and (unless it is dynamically spawned) block the plane's slot. 

Implementing that isn't too difficult, merely some busywork. The real issue lies somewhere entirely different: I discovered (and this is confirmed by other server owners) that players positively loathe missions that try to impose rules on the availability of aircraft/slots. As a result, players won't return to the server, and the mission gains a reputation as 'not fun' or 'player hell'. The mission is kicked off the server's rotation. Not for being a bad mission, but because it tries to assert control over the players who come to play, not bossed around.

DML has some modules that can do similar things: "ungrief" punishes fratricide, "taxipolice" punishes speeding on taxi ways, "limitedAirframes" limits the number of losses per slot. While the ungrief module is accepted (antisocial behavior should be dealt with swiftly), "limitedAirframes" is begrudgingly accepted by roughly half of the players, "taxi police" has almost universally been deemed excessive. There are some players who appreciate enforced order. The majority does not, however, and they avoid missions that are known for imposing (what players deem to be) restrictions on their playstyle. Since server owners want their servers to be popular, they eschew missions that players dislike. Mission creators (like I) want their mission to be popular, and so we would not add a module that is known to cut the potential popularity by 90%.   

Long story short: it's not that difficult an idea to put into reality, and it's currently not a direction (rule enforcements) that I want DML to take.  

The idea of maintenance, despite the fact that it can be customised in accordance to the squadron's needs, we intend to use it in PvP Dynamic Campaigns missions that last 2 1/2 hours. We invested in limited assets and weapons and we extensively use the limitedAirframes in conjuction with CSAR to simulate the lack of pilots and force the oponent coalition to invest in CSAR mission to recover ejected Pilots in order to be able to use all available slots.

Maintenance is what it was mising in our case. Unfortunately, in DCS World when a F-16 lands can be airborne again in less than 3 to 5 minutes. In real life, the maintenance personnel is not unlimited and the weapons need time consuming assembly and transportation. Moreover, the refueling vehicles are not unlimited and a lot of time is needed for them to be refilled. In this context, if you are able to apply a 10-15 minutes maintenance delay, the coalition that will not take it in account in its ops planning in order to maximise sustainabilty, will gift the opponent with opportunity windows to achive its mission objectives. Of course it in not practical in DCS to apply a 45 minutes or 60 minutes maintenance delay, as it maybe in real life.

Especially for @DD_Friar, that most probably didn't understood the whole concept, I would like to highlight that if a Sqn for example during a 2:30 mission has available 18 F-16s in an airbase and the coalition has 10 clients flying the F-16, when they land (let's say that only 8 of 10 managed to land) there will be for the the second shortie, for an immediate take off, only 8 available aircrafts. The other 8 will be available after the maintenance time pass and so on for the rest of the mission. But, why to adopt such a philosophy in my game? What is the reason? Despite realism reasons, that's a motivation for your virtual pilots to optimise fuel and weapons management, for the mission commanders to plan wisely to maximise sustainablity.
Morever, those that they will not be able to get a anymore F-16 slots they contribute to the mission as CSAR pilots, or by flying other aircrafts or HELO.

This is the way of thinking for DCS World in Lock On Greece / DCS World Greece.  

In my opinion, maintenance is something that it is missing from DML (as it was ASUW, RECON and others as well) and it could add a very valuable option for those that they will to invest in realism. 

Edited 3 hours ago by Panthir

[cfrag]

4 minutes ago, Panthir said:

Despite realism reasons, that's a motivation for your virtual pilots to optimise fuel and weapons management, for the mission commanders to plan wisely to maximise sustainablity.

I think that is universally understood. The best approach here seems to me to have a gentleman's agreement to not violate commonly accepted rules of usage -- instead of using software to enforce them. And should a squadron unexpectedly show in full strength, and for whatever reasons you are short a slot, the agreement can be made to utilize a plane that would - per agreement - not be available. If enforced by software, that squadron member is out; for them the evening of a common fun experience is gone. That's IMHO a worst case scenario for a group of friends who want to experience something together.

That is the reason I'm not enthusiastic about restrictions enforced by software: inflexibility and exclusion. An agreement among friends is much simpler. If you can't get your sqn to agree and adhere to some simple rules, methinks you should address that first. To me, It's not a lack of motivation, it's a lack of trust in your squad mates that they will to stick to agreed-upon rules.

To me you are attempting to provide a technical solution for a cultural challenge. The solution won't be elegant, the results can be ugly. A bad match.

[Panthir]

2 hours ago, cfrag said:

I think that is universally understood. The best approach here seems to me to have a gentleman's agreement to not violate commonly accepted rules of usage -- instead of using software to enforce them. And should a squadron unexpectedly show in full strength, and for whatever reasons you are short a slot, the agreement can be made to utilize a plane that would - per agreement - not be available. If enforced by software, that squadron member is out; for them the evening of a common fun experience is gone. That's IMHO a worst case scenario for a group of friends who want to experience something together.

That is the reason I'm not enthusiastic about restrictions enforced by software: inflexibility and exclusion. An agreement among friends is much simpler. If you can't get your sqn to agree and adhere to some simple rules, methinks you should address that first. To me, It's not a lack of motivation, it's a lack of trust in your squad mates that they will to stick to agreed-upon rules.

To me you are attempting to provide a technical solution for a cultural challenge. The solution won't be elegant, the results can be ugly. A bad match.

You are completely right. Of course it could be done manually via rules, but you would have to have more than one guy to keep the maintenance times for all assets. Almost impossible.

So, that the reason that we need such a script or module to do it automatically. It is not a matter of trust or agreement between friends but a matter of practicality. 

Maybe you misunderstood. The maintenance is applied to the aircrafts or landed HELO and not to clients. It not a matter of clients to agree that they will stay grounded for example 20 minutes to simulate maintenance (this is crew rest). The aircraft is set under maintenance and the clients can get immediately another asset if available and fly. Who will keep the maintenance time countdown for several assets landed in different times. 
 

You will have to organise a real logistic office manned with several guys to track all those data manually 

Edited 56 minutes ago by Panthir

[Recluse]

LOL...  when repairing a broken bird, which in real life might take days,  180 seconds in DCS seems too effing long 

Always the tug of war between REALISM and ENTERTAINMENT.. In the latter, ejections and crashes don't hurt as much

 

 

Edited 1 minute ago by Recluse