DML - Mission Creation Toolbox [no Lua required]

[dtruck260]

Can I use DML is somehow to spawn a weapon? I want to spawn the lighting flare (from the a10 or some other a/c) to light an area up at night

[cfrag]

1 hour ago, dtruck260 said:

Can I use DML is somehow to spawn a weapon?

Currently, there is no way to spawn weapons in DCS's scripting environment. As soon as it becomes available, I have some really nice ideas for artillery, nasty missiles, and intercept missions...

 

1 hour ago, dtruck260 said:

I want to spawn the lighting flare (from the a10 or some other a/c) to light an area up at night

There is a function trigger.action.illuminationBomb(table vec3 , number power ) in the scripting environs, which may be what you are looking for. It also makes be believe that there might be a vanilla DCS trigger to do that for you

[dtruck260]

47 minutes ago, cfrag said:

Currently, there is no way to spawn weapons in DCS's scripting environment. As soon as it becomes available, I have some really nice ideas for artillery, nasty missiles, and intercept missions...

 

There is a function trigger.action.illuminationBomb(table vec3 , number power ) in the scripting environs, which may be what you are looking for. It also makes be believe that there might be a vanilla DCS trigger to do that for you

Yep! normal trigger I can use, illumination bomb!

[cfrag]

Version 2.3.1 - 20240829 Maintenance Update 

While trying to get through the dog days (with temperatures routinely exceeding 32°C -- which may not be a lot for you, but for a Northling like me it's just too hot) my thoughts naturally went to the fires of hell (yeah, a Christian upbringing sometimes does that to you), and from there (since I outgrew religious beliefs) to fires - and fire fighting. In Helicopters.

I've experimented with this for some time, and knew that creating a companion module to CSARmanager that focuses on firefighting would require significant development. And so, during the past two weeks, since I couldn't sleep anyways (I live in a beautiful 500+ years old house -- the price being no modern isolation and, being an attic, temperatures at night not dropping below 37° in summer) I got to work. High temperatures and sleep deprivation can play some strange tricks on your mind, yet here they conspired to allow me to cut through some tricky challenges, and I ended up with not one, but two modules that will soon find their way into DML (their experimental stages are already included, to hopefully find conclusion in the coming releases):
"Inferno" is a module that, simply put, creates a conflagration: a fire (using DCS's fire FX) that spreads but will not cross rivers. It's physics modelling is fast (i.e. doesn't gobble up performance like my godson does his sugar-coated cereal), and more importantly, it's purpose-built for 'airtank' the CSARmanager for aerial firefighters. Together you can use them to quickly build fire-fighting missions, and I plan to use them to build some (hopefully fun) missions similar to the "Angels" missions, just focused on fire-fighting.

In case you are wondering: the 'Firestarter' mission included below shows the current state of those missions and ease of integration. There's still some ground to cover, but if you feel the urge to fly some heavily loaded helicopters, try it out - and should you have any feedback, I'm always happy to receive it.

Other than that, you guys were also kind enough to alert me to a number of bugs that still remained in DML in the aftermath of the troublesome past three DCS releases. I hope that I've caught them all, and my thanks to you all for taking the time to point them out.

Here are the changes 

Documentation
    Main & Quickref
        - occasional corrections 
        
    Demos 
        - none
    
    Modules 
        - airtank 0.9.x 
            - experimental firefighting module 
        
        - civHelo 1.0.1
            - Hardening of Liveries code 
            
        - dcsCommon 3.1.3
            - new DCS patch section to patch DCS API 
            - new unit type verification methods 
        
        - heloTroops 3.1.2 
            - captureandhold orders hardening 
            - DCS bug hardening for troop deployment 
        
        - inferno 0.9.x 
            - experimental fire conflagration in zone module 
            
        - limitedAirframes 1.7.0 
            - DCS bug hardening 
            - code cleanup 
            
        - LZ 1.2.1
            - DCS bug hardening 
            - removed typo 
            
        - objectSpawnZones 2.1.1
            - now spawns for correct country 
        
        - ownedZones 2.4.1 
            - correctly guards conquered flag on mission load 
            
        - radioMenus 4.0.1 
            - cfxMX no longer optional 
            
        - reconMode 2.3.1
            - hardened config reading 
            
        - slotty 1.2.0 
            - removed potential race condition with SSBClient  

        - stopGap 1.3.0 
            - new 'noParking' attribute 
            
        
 

firestarter.miz

Edited August 29, 2024 by cfrag

[dtruck260]

Thank you! 

3.1.2 - doLoadGroup - test if group is still alive edge case handling

[iron_fruitman]

Hello cfrag,

first of all, thank you for your work ! 

I am trying to set up a TDZ training mission and I encounter the attached issue when "touching" the runway and again when coming to a full stop (same error message).

First time using this module so it may be a bad setup from my side.

I joined the .miz as well as the logs.

Thank you again !

EDIT : in the miz, the plane is Blue and the airfield is Red. Tried Red on Red but same issue.

dcs.log Mig21 - Caucase - Training - Clement - Multi.miz

Edited August 29, 2024 by iron_fruitman
More details

[cfrag]

16 hours ago, iron_fruitman said:

I encounter the attached issue when "touching"

Thank you for providing the example - there was a silly typo in the code when banging the touchdown! output. Please use below update.

 

TDZ.lua

[iron_fruitman]

@cfrag works like a charm, thank you !

[iron_fruitman]

@cfrag Sorry to bother you again.

Another small-non-blocking issue : the starts / extend parameters are inverted (may also be the case for the expand and stops ; I have not tested them) :

- starts reduces / increases the length of the runway

- extend moves the runway

 

In addition, negative values seem to increase (or move up) the zone (for the respective parameters) instead of reducing / moving down the zone.

I have attached a few screenshots, both in the ME and in game.

[MK-82_1_EACH]

Looking at Documentation concerning the delicates module, there was no reference on whether moving zones were supported (maybe I missed it - I'm old and somewhat dyslexic ).  My testing indicates it's not, otherwise works great.  Not a big deal but you might document that it's not supported for moving zones. Of course I assume that is the intent.    BTW- Thanks for all the work on DML  

[cfrag]

38 minutes ago, MK-82_1_EACH said:

there was no reference on whether moving zones were supported

My apologies for being unclear about this. I'll try to make this easier to understand - in my defense, I'm not a native English speaker, I tend to speak in riddles  . Here's the relevant passage from 5.3.29.1  - Description in the "Shock Block" under DESIGNATING OBJECTS/UNITS AS DELICATES

Quote

Note that ‘delicate’ status is determined at mission start. So units that enter the ‘delicates’ zone later will not become delicate, and units that initially were inside the zone and later leave it remain delicate.

This implicitly means that even if the zone moves after mission startup, it will not add new units/objects to the set that was determined at startup.

Edited August 31, 2024 by cfrag

[cfrag]

On 8/30/2024 at 1:05 PM, iron_fruitman said:

Another small-non-blocking issue : the starts / extend parameters are inverted

That is unfortunately a result of DCS's internal runway handling and the reason that I had to add the ungainly 'left^' and 'right' attributes to a TDZ. You may have to experiment with them and create two TDZ for the same RWY, one left and one right. One of them will be 'wrong' (inverted).

[MK-82_1_EACH]

2 hours ago, cfrag said:

My apologies for being unclear about this. I'll try to make this easier to understand - in my defense, I'm not a native English speaker, I tend to speak in riddles  . Here's the relevant passage from 5.3.29.1  - Description in the "Shock Block" under DESIGNATING OBJECTS/UNITS AS DELICATES

This implicitly means that even if the zone moves after mission startup, it will not add new units/objects to the set that was determined at startup.

 

Thank you and no need for apologies.  Documentation to reach all audiences is a daunting and difficult task.  

[iron_fruitman]

Quote

That is unfortunately a result of DCS's internal runway handling and the reason that I had to add the ungainly 'left^' and 'right' attributes to a TDZ. You may have to experiment with them and create two TDZ for the same RWY, one left and one right. One of them will be 'wrong' (inverted).

My apologie for being unclear : my point is that the arguments starts and extend seem to be inverted in DML.

According to the documentation (sorry for quoting you ^^) :

- extend : Extend the length of the runway (as reported internally by the map’s DB) by this amount of meters.

- starts : Offset (in meters) from the runway threshold (as defined by DCS’s airfield DB) where the TDZ starts

While in my test, when I fill the "starts" argument with a positive value (360 in the exemple above), it shrinks the zone size by 360m.

The extend arg offsets the position of the zone.

Knowing that, I was able to create the mission but I think either the documentation or the module has it inverted

 

Thank you.

[Priest]

Is there a way to restrict a spawner with attackOwnedZone orders from attacking owned zones outside of certain distance from the spawer? Or only attack ownedZones within a certain distance of the spawner.

[cfrag]

4 hours ago, Priest said:

Is there a way to restrict a spawner with attackOwnedZone orders from attacking owned zones outside of certain distance from the spawer?

Currently all Owned zones in the theater are considered, and the units are made to go to the nearest enemy owned zone, even if they have to cross the map for it.

[DD_Friar]

@cfrag Might I impose on you for some advise in relation to capturing an airfield and unlocking plane slots.

On the attached test mission Aleppo airfield starts out red.

I have a blue T51-D allocated to the airfield. If you try and take this plane you get the slot blocked message - all good.

I then take the blue car and drive into my control zone. This changes the ownership of the airfield to blue and the slot becomes open for me to take.

I drive the blue car out of the control zone and then change coalition and take the red car and drive into the control zone.

This changes the ownership of the airfield to red and the plane slot is blocked again.

I drive the red car out of the control zone and change coalition again to blue.

I now drive the blue car into the control zone and the airfield changes ownership to blue.

I then try and take the blue plane again and but get slot blocked message?

What am I doing wrong please with the zones and parameters?

BUMP?

AirfieldCapture.miz

Edited September 3, 2024 by DD_Friar

[Panthir]

Dear Cfrag,
    
I hope you enjoyed your summer holidays.

I would like to inform you about an error we get in our squadron's missions related to the objectDestructDetector.lua.

Specifically, In missions that we use objectDestructDetector module, we found out that when we destroy ground units with (we suspect) high detonation weapons (such as AGM-65D) we get a script error related to the line 150 of this module. The same error may not occur if we destroy the same targets e.g. with Vihrs or guns.

I send you attached a simple mission and the dcs log file. In this mission (multiplayer) I got a KA-50III slot and I destroyed two of 4 tanks tanks with Vihrs without getting any error. Then I left the slot and got a F-16 slot and I fired one maverick against the third tank and I got the following script error that didn't crash DCS but after closing the error pop up window the game continued.

This is a simplified mission in order to produce the error, but eventually this error occurs in all missions we use objectDestructDetector module, regardless the used map. 

 I send you attached the mission and the dcs log.

Cheers I hope I helped You

Test.miz

[cfrag]

8 hours ago, Panthir said:

Specifically, In missions that we use objectDestructDetector module, we found out that when we destroy ground units with (we suspect) high detonation weapons (such as AGM-65D) we get a script error related to the line 150 of this module.

Unfortunately, due to the fact that you are using DoScriptFile instead of "DoScript" it is impossible for me to trace the bug to its origin, While I'm absolutely prepared to believe that ODD is the culprit, there is no line 150 in ODD that invokes getName(). I've hardened on your suspicion ODD against the Jul-11 and Jul-22 DCS bugs (see below). Does this new version make a difference? 

Cheers,

-ch

objectDestructDetector.lua

[Pogon]

Hi
ODD was the culprit but we had older version ( 2.0.3 ) for some reason ...
The error was for getPoint() in line 150 
Looks like It is working properly now with 2.0.4
The handler added if not theObject.getName then return end seems to be correct.
Cheers
All the best

[Panthir]

3 hours ago, cfrag said:

Unfortunately, due to the fact that you are using DoScriptFile instead of "DoScript" it is impossible for me to trace the bug to its origin, While I'm absolutely prepared to believe that ODD is the culprit, there is no line 150 in ODD that invokes getName(). I've hardened on your suspicion ODD against the Jul-11 and Jul-22 DCS bugs (see below). Does this new version make a difference? 

Cheers,

-ch

objectDestructDetector.lua 10.48 kB · 2 downloads

Excellent I will retry and report accordingly Sir

[Pogon]

Hi there
I apologize
After further testing with Panther it seems that the problem is still there
We will try some more testing and we will come back to you
Cheers
All the best

[Panthir]

On 9/2/2024 at 8:52 PM, cfrag said:

Unfortunately, due to the fact that you are using DoScriptFile instead of "DoScript" it is impossible for me to trace the bug to its origin, While I'm absolutely prepared to believe that ODD is the culprit, there is no line 150 in ODD that invokes getName(). I've hardened on your suspicion ODD against the Jul-11 and Jul-22 DCS bugs (see below). Does this new version make a difference? 

Cheers,

-ch

objectDestructDetector.lua 10.48 kB · 3 downloads

Dear Cfrag, we tested the objectDestructDetector.lua in a simple mission and everything worked ok. During further testing in more complex missions (CSAR, Score, Stopgap, Sittingducks, objectDestructDetector, tacan, ndb etc)@Pogon found out that the issue occurred only in missions that sittingducks module was used. In this context, @Pogon applied the same modification you applied in objectDestructDetector.lua to the sittingducks.lua line 32. We tested it in two different missions and it seems that everything is working ok.

I attach the modified sittingDucks.lua. We will continue testing. We wish that we helped you a bit. 

 

 

sittingDucks.lua

Edited September 5, 2024 by Panthir

[DD_Friar]

On 9/1/2024 at 10:00 AM, DD_Friar said:

What am I doing wrong please with the zones and parameters?

@cfrag, sorry to ask but I was wondering if this issue had slipped by you. I described my issue a few posts back? I am having an issue with ownedZones and second time capture.

[cfrag]

19 hours ago, DD_Friar said:

if this issue had slipped by you.

No, it hasn't, but I have not yet found the time to look into it. I will, over the week-end at latest.