DML - Mission Creation Toolbox [no Lua required]

[DD_Friar]

Salute @cfrag

Sorry to bother you but I have another quick question. What is the best / correct way to delete a group of infantry?

My scenario:

Troop pickup - Huey enters zone, unit of 4 infantry are Cloned and walk out to meet the Huey. they are picked up (human flying by the way) and taken back to a FARP. They are disembarked and follow a couple of waypoints. They then are give a "Hold" at the last waypoint.

As this process could be repeated many times on our server, I don't want to end up with a queue of troops as long as a one as users of DML wanting to shake your hand and say thank you.

I am therefore trying to delete them once they have got to the last waypoint following the disembarkation from the Huey.

At the moment I have the end waypoint covered by a Unit Zone that bangs a flag that is also referenced by a wiper zone to fire that is inside the Unit zone.

I have the Wiper set to Lookfor "unit" (I do not have quotes around unit in my settings)

This does not seem to be working. I am aware of an issue with the standard DCS triggers for zones and deleting, could this be affecting DML as well? (or am I just doing it wrong, a stronger possibility)

Any nudge would be welcomed.

Cheers

Friar

 

[cfrag]

1 hour ago, Recluse said:

So I get this output: SSB says BluDude is BLOCKED but I can still get in it!!

On my machine it appears to work as expected:

That's a good indication that something with SSB itself on the servers borked. So let's compare notes. What does your SSB configuration look like? This is how mine looks:

ssb.showEnabledMessage = true -- if set to true, the player will be told that the slot is enabled when switching to it
ssb.controlNonAircraftSlots = false -- if true, only unique DCS Player ids will be allowed for the Commander / GCI / Observer Slots


-- New addon version 1.1 -- kicking of players.
ssb.kickPlayers = true -- Change to false if you want to disable to kick players.
ssb.kickTimeInterval = 1 -- Change the amount of seconds if you want to shorten the interval time or make the interval time longer.
ssb.kickReset = false -- The slot will be automatically reset to open, after kicking the player.
ssb.kickTimePrev = 0 -- leave this untouched!


-- If you set this to 0, all slots are ENABLED
-- by default as every flag starts at 0.
-- If you set this to anything other than 0 all slots
-- will be DISABLED BY DEFAULT!!!
-- Each slot will then have to be manually enabled via
-- trigger.action.setUserFlag("GROUP_NAME",100)
-- where GROUP_NAME is the group name (not pilot name) and 100 is the value you're setting the flag too which must
-- match the enabledFlagValue
ssb.enabledFlagValue = 0  -- what value to look for to enable a slot.

take especial care when you look at "ssb.enabledFlagValue = 0" in SSB itself. If it's anything else you must tell ssbClient about that

Below is the mission that works well on my machine, "repaired" for most recent modules and DOSCRIPT for easier debugging.

 

BobsSlotBlockerCFR.miz

[cfrag]

19 hours ago, Recluse said:

Could you please take a look at the airfield.lua?

The good new is that I found the issue. ED have regressed their fix for getCategory, and then also applied it to the previously unaffected airfield tree. So suddenly, the script got strange airfield codes, and the safety checks happily discarded them. Below please find a new airfield that should run at least as flawlessly as the previous

 

airfield.lua

[cfrag]

2 hours ago, DD_Friar said:

At the moment I have the end waypoint covered by a Unit Zone that bangs a flag that is also referenced by a wiper zone to fire that is inside the Unit zone.

I have the Wiper set to Lookfor "unit" (I do not have quotes around unit in my settings)

That should work, but I recommend an even simpler approach: regularly (say every 10 minutes) invoke the wiper and wipe any units inside. Your wiper setup seems fine. To make sure it's working, place some units inside, and turn on verbosity to see if it wiped the units inside on the wipe command.

[Recluse]

Thanks!

30 minutes ago, cfrag said:

On my machine it appears to work as expected:

That's a good indication that something with SSB itself on the servers borked. So let's compare notes. What does your SSB configuration look like? This is how mine looks:

take especial care when you look at "ssb.enabledFlagValue = 0" in SSB itself. If it's anything else you must tell ssbClient about that

Below is the mission that works well on my machine, "repaired" for most recent modules and DOSCRIPT for easier debugging.

 

BobsSlotBlockerCFR.miz 211.26 kB · 0 downloads

 

That was it! My SSB lua was somehow corrupt.

Your REPAIRED version similarly did not work on my machine at first.

 

When I opened SSB in NotePad++ to compare it to your extract, the formatting was way off and crazy, so it got corrupted somehow.  I re-opened the original from the download and it looked fine. When I replaced it in my HOOKS, everything worked as expected!  THANKS! Sorry for pointing the finger at your module!!

 

 

 

[Recluse]

22 minutes ago, cfrag said:

The good new is that I found the issue. ED have regressed their fix for getCategory, and then also applied it to the previously unaffected airfield tree. So suddenly, the script got strange airfield codes, and the safety checks happily discarded them. Below please find a new airfield that should run at least as flawlessly as the previous

 

airfield.lua 17.54 kB · 0 downloads

Unfortunately, the same thing happens with this one as with the previous one.  Same messages about the ownership with grace period, and eventually, both cloners fire. So far the 1.0.0 version is the only one that works for me.

The recent getCategory swings back and forth messed up a lot of MIST and MOOSE based missions we flew (Foothold, *Power) but the authors fixed them (twice) and they are working again. 

Edited January 19, 2024 by Recluse

[cfrag]

Just now, Recluse said:

Unfortunately, the same thing happens with this one as with the previous one.  Same messages about the ownership with grace period, and eventually, both cloners fire.

Now that we go the category thing figured out, let's get this one too  

How do I force the ownership issue so I can trace it down and stamp on it hard?

 

[Recluse]

22 minutes ago, cfrag said:

Now that we go the category thing figured out, let's get this one too  

How do I force the ownership issue so I can trace it down and stamp on it hard?

 

I set some Radio Menu items like the demo to force the base to be RED or BLUE based on the flags in the Airfield zone (if I did it right).

Use this mission.  I separated out the slot block stuff and the cloner stuff for ease.  This one has the 2.1.1 airfield.lua as Do Script

Base should start out RED and fire the REDCAP cloner.

A UH-1 takes off from Senaki to drop troops which should turn it BLUE and fire the BLUECAP cloner.

I had to use flags outside DML to get the cloners to fire looking at the Ownership flag value to decide which cloner to fire  I'm sure there is a better way to do it, but this was the easiest for me for testing purposes.   (AHHH I could have just used the KUTRed and KUTBlue flags set by RED! and BLUE! outputs from Airfield, but I had an idea that I wanted them to Fire off again a certain time AFTER they fired the first time but I didn't put that time delay in yet).

There is an LAV sitting outside the Kutaisi perimeter that I originally used for ownership change before configuring the helo. But it does nothing now but try to shoot at the Red planes taking off

DML_DynamicMission_TEST.miz

Edited January 19, 2024 by Recluse

[cfrag]

26 minutes ago, Recluse said:

Base should start out RED and fire the REDCAP cloner.

Ha. I found the issue, and it is a really nasty one, one that DML detects and then corrects - but too late.

The issue are the 4 blue NASAMs that you have placed inside the cloner. Although they get removed at mission start, even before that, DCS notices the four ground troops inside Kutaisi, and immediately changes Kutaisi to blue ownership. Since at mission start there aren't (yet) any modules patched into the event handler, this event gets lost, and airfield recognizes the mismatch between the recorded owner (airfield - red) and actual owner (Kutaisi: blue).

To get around this, I recommend that you set up a cloner template outside the airfield proper (2km capture radius) and then import the clone template.

Tricksy, tricksy little DCS...

Edited January 19, 2024 by cfrag

[Recluse]

I can see that this wouldn't be an issue when there was ONE cloner, and the cloned units took on the ownership of the base, but this would be a GENERAL issue whenever a Cloner has ground units spawning specifically of the opposite faction.  Interesting!  LOL I was a purist and wanted RED  specific units for RED and BLUE specific  units for BLUE, hence the complications.

But it is odd that it doesn't happen with 1.0.0 of the airfield.lua?

Originally I didn't have the NASAM's in there, but after I solved the script errors with 2.0.0 by putting version 1.0.0 in,  I put them in, and then made a new problem when you updated the airfield.lua.

Too many variables!!  IT works just as you expected when the SOURCE of the NASAMS is off the base. Thanks again.  At least I helped you find some bugs

 

[DD_Friar]

@cfrag

Sir, I am desperately trying to get my head round using Helo Troops (I want to use the UH-60L mod and it does not allow for the "embarking / disembark" that in game helos use (unless I am being a numpty)

I am reading the guide but can not find any information on cfxCommander or cfxGroundTroops. A number of modules declare that they are pre-requirements, but in either v2 or 1.97 I can not see any guide on how they fit in?

I need to be able to change the default "guard" formation to start with and also sort out the Comms (F10) menu structure. I have looked at "send in the clones" but did not find it helpful, sorry.

Could you advise please?

Many thanks and kind regards

Friar 

[Recluse]

@DD_Friar

 

I don't pretend to be @cfrag, but I did get the UH-60L (and the OV-10 Bronco) working with HeloTroops. I hope I understood your question.

Just added them to the allowed types in the troopCarriers setting of the  heloTroopsConfig zone along with other allowable helos. I started with the Demo mission as a base and modified for testing. Got everything working.  I meant to also try the ALL or ANY configuration to see if the UH-60L got added, but I didn't get to it yet. 

NOTE: as it says in the manual, The module installs an “Airlift Troops…” command into a player’s Communication→F10 Other… menu to allow them to load, unload, and set troop transport preferences.. Don't use the DCS built in AIRBORNE TROOPS menu at the top level.

Look at the demo - Helo trooper.miz to see how he setup the spawn zones for troops. I basically just added the UH-60L and Bronco to that mission and made the edits to troopCarriers and everything worked.  

 

My module loading (actually @cfrag's from his demo mission) is:

 

Edited January 20, 2024 by Recluse

[cfrag]

1 hour ago, DD_Friar said:

I want to use the UH-60L mod and it does not allow for the "embarking / disembark" that in game helos use

As @Recluse already kindly mentioned, HeloTroops does not use DCS built-in embark/disembark mechanics, but is a module that allows player-controlled helicopters (and others) to pick up and deploy *any* infantry on the map if you land close to them (obviously, they must be from your faction, else they negotiate a ride with lead to your face). Controlling pickup and deployment happens through the communications-->other... menu. It does not tie into the 'Airborne Troops' menu.

Control of which aircraft are allowed to be used as transport is (again my thanks to @Recluse) controlled with heloTroop's config zone, that has the 'troopCarrier' attribute for this.

1 hour ago, DD_Friar said:

I am reading the guide but can not find any information on cfxCommander or cfxGroundTroops.

Just like dcsCommon, cfxZones or cfxMX (and some others), those modules have no mission-designer accessible functions, and provide low-level functionality for other modules. For brevity of the manual (don't groan, I really tried hard to keep that thing short )  I do not document those (internal-use only) modules. As of version II of DML, they are now called "commander" and "groundTroops".

 

[Recluse]

@cfrag

 

Not a big deal at all, but I was messing around with WilliePete and indeed the supported munitions in the manual are correct. However, I noticed the Harrier can also carry FFAR 2.75" M156 WP in addition to the Hydra M156 that are supported.   Is it possible to add this as a supported type for WilliePete?  I only ask because others might tear their hair out like I did when the  Arty doesn't recognize the smoke. Finally turned VERBOSE on and saw the message that it didn't think it was a Willie Pete munition. I think the FFAR are OLDER models which were superseded by the HYDRA. Normally I pick the HYDRAS in all cases but I guess I didn't for my WilliePete testing 

[cfrag]

40 minutes ago, Recluse said:

Is it possible to add this as a supported type for WilliePete? 

Yes. I just need to know the DCS internal designation. I'll try and see if I can suss it out, if you know how they are called internally, so much the better.

[Recluse]

45 minutes ago, cfrag said:

Yes. I just need to know the DCS internal designation. I'll try and see if I can suss it out, if you know how they are called internally, so much the better.

Based on the LOG file when I shot one, I believe it is:

 

FFAR M156 WP

[cfrag]

13 hours ago, Recluse said:

FFAR M156 WP

Yes its is! Here's a new version of WP that should support your Harrier's older FFAR phosphorous rounds and a miz to try it out:

 

 

When Harry met Willie.miz williePete.lua

[DD_Friar]

Salute @cfrag,

Sir, I am trying to keep all of my mission controls within DML, however I am a bit stuck at the moment. What would be the best way of checking for the death of a single unit that had been placed on the map, for example a tank or truck. Its not a clone and not part of a group. I want to use its death as a random trigger for something else.

At the moment I have only found to use the standard trigger for "UNIT DEAD", so have the condition as unit death and actions as increase flag.

Is there a DML option for this? or is the old way the least complicated to do for this scenario?

regards

DD_Friar

 

[cfrag]

21 minutes ago, DD_Friar said:

What would be the best way of checking for the death of a single unit that had been placed on the map

For something that basic, I'd set up a ONCE trigger, with Condition UNIT DEAD and have an action INCREASE FLAG applied to the flag that you want to trigger some higher-level (DML) activities. DML is designed to work together with old-school mission design, and if you use the 'INCREASE FLAG' action, that works exceedingly well with any module input (ends on "?") that triggers on a change (which is the default for all module inputs). 

You could use a groupTracker, but IMHO that's overkill. 

 

[Recluse]

Another question in my continuing WilliePete saga.

 

Pretty sure I know the answer, but wanted to check to be sure there is nothing else going on.  Last night we flew an MP Willie Pete enabled mission.  I was conscious of the warning that

Quote

WP does not fully support multi-unit player groups. Make sure that each player has their own group.

and

The group xxx has two player units in the same group. Note the WARNING that the mission gives at start-up. Using multi-unit player groups is not recommended with WP and can lead to unpredictable results.

So just wondering if THIS was one of the unpredictable results.  I was the client, and the Host and I were in a multi-aircraft group.  I successfully called in Arty with WillePete in several zones, but the host kept getting this script error:

 

 

Yeah, my bad again for using Do Script File instead of Do Script, but I am 99.9% sure this refers to the WilliePete.lua since the line referenced is useing 'theGroup' in a function:

I took the chance and I guess FA and FO, but just wanted to be sure that the script error was indeed coming from the used of multi aircraft groups. Got all the warnings up front about all the GROUPS that WilliePete saw on startup (and subsequently suppressed those messages).  Aside from the host having to acknowledge and click through numerous script errors like the one above, everything ran well.

[cfrag]

18 minutes ago, Recluse said:

I took the chance and I guess FA and FO, but just wanted to be sure that the script error was indeed coming from the used of multi aircraft groups.

I can't really tell since I don't usually build test cases against my own recommendations. I'll see if I can reproduce the issue - can I trouble you to resolve single-user player groups in your mission and test if the error appears again? 

-ch

[cfrag]

32 minutes ago, Recluse said:

but I am 99.9% sure

Let's make this 100%.

Please try below amended script. Warning: Untested.

williePete.lua

[Recluse]

Thanks!!   Might be awhile before I can try again in MP (Thursday is our next scheduled session).

Note that I did test in SINGLE PLAYER, but, of course, since all of the GROUP were composed of CLIENTS, only a single aircraft actually spawned when I flew it. So it wasn't quite the same test. I will try putting some AI wingmen in the group and trying it in Single Player.

- WilliePete (even the older module) doesn't seem to care if a CLIENT or PLAYER has AI Wingmen.  Doesn't even flag it in the starting warnings.  Makes sense since it is a human interaction. Guess I have to grab a friend and retest in MP.

 

I was thinking of just adding some Single Aircraft groups and calling them -FAC for use in calling in Artillery if it isn't resolvable through scripting.

 

Edited January 22, 2024 by Recluse

[Chad Vader]

HI,

This is amazing!

Do you have a discord for questions and so forth

One question I have is how does the script know where a sound file is?  For the player score module for example, i set a trigger and set the scoreSound value to the path where the sound file is.. Should that work?

ALso, I get the module loading confirmation when I run the mission in the ME, but I dont get any when I run the mission on my dedicated server.  Any ideas what im doing wrong?

Edited January 22, 2024 by Chad Vader

[cfrag]

1 hour ago, Chad Vader said:

how does the script know where a sound file is?

It doesn’t. DML assumes that the sound files are pre-loaded (meaning: you need to create a trigger that (usually never executes, say time later than 100000) plays all sound files as action “Sound to all” (or similar). This causes DCS to add the sound files automatically into the miz’s sound folder. Then you reference them by their file name (no folders), and DML finds and plays them. Unfortunately there currently is no better way. DML does support a folder structure, but you really do not want the hassle of managing sound files in the .miz

1 hour ago, Chad Vader said:

I get the module loading confirmation when I run the mission in the ME, but I dont get any when I run the mission on my dedicated server.

That rather depends. Often, when the client connects to the server, the messages have disappeared already, they appeared when the mission starts. Also, dedicated servers have no visuals, so you can’t see them there. Try and run the mission self-hosted, and you should be able to see the messages.