DML - Mission Creation Toolbox [no Lua required]

[bitboy]

cfrag,

Disregard I tested/checked, the in air Comms menu does indeed show who/what you have onboard which is perfect. 

Thxs

[cfrag]

3 minutes ago, bitboy said:

which is perfect

Ah, but your screenshot revealed a glaring issue: The text is missing a closing bracket ")"!!!!!one

[bitboy]

Well, yes but ..... and I know you strive for perfection of course, but no closing bracket in this case....not a show stopper for me. 

[bitboy]

cfrag,

 I think I'm missing something key with the use of Owned Zones and Airbases.

The scenario is pretty straight forward.  1) Start mission with Airfield Zones (controlled by red or blue, no neutrals at start). 2) Have Factory zones that will produce attackers. 3) Have the attackers attack airfield (this was accomplished by using the owner attribute in the airfield zone). Desired behavior: the Airfield stays Blue (in this case because Blue Forces start the mission inside the airfield zone), until such time as the Red attackers eliminate all the Blue defenders. Once blue forces are gone and red is inside the airfield zone, then I would like the airfield to transfer to Red forces. And of course the opposite effect should blue forces counter attack at some point and retake the field.

 Everything works great, but the only problem is that the airfield transfers to Red the moment Red forces get inside the Airfield zone, even with Blue Defenders still available. ??? I'm looking for similar functionality for airfield zones that I can get with Owned and Factory zones. Not sure if I need to use Flags to force the airfield to a certain state or not.

A snapshot attached. Red has entered the zone, and the airfield already transfers to Red despite the presence of Blue forces.

Can you point me in the right direction?

Thxs

[cfrag]

6 minutes ago, bitboy said:

Can you point me in the right direction?

If possible, please PM the mission to me so that I can have a look

[cfrag]

3 hours ago, bitboy said:

Everything works great, but the only problem is that the airfield transfers to Red the moment Red forces get inside the Airfield zone, even with Blue Defenders still available. ???

This one had me stumped for a while.

Then, on closer analysis I noticed this progression:

In other words:

• first AK trooper doesn't cap
• neither second
• neither RGP (not pictured)
• BRDM caps Batumi even though there are boots on the ground in Batumi

WTF? Then I realized that all blue units are infantry, and the capping red unit is armor. Could that be a factor? I broke out the big guns (debugger)

OK, so who is "Batumi Harbor (A) 76551-4"? It's the BRDM-2 scout. 

So, I theorized, maybe armor beats infantry, like a silly 'rock-paper-armor' type game. To test this hypothesis, I switched one of the defending blue units to armor (an APC), and ran again:

Now red no longer caps. 

Preliminary conclusion: There now is (new?) airfield capture logic in DCS that (maybe) goes like this:

• If NO OTHER oppo units are  present, ANY unit caps
• if ONLY oppo INF caps present, any ARMOR can cap, but not INF

Since you may have some contacts within ED, can you ask someone with knowhow what the current capture rules are? Knowing this may come in handy.

In the mean time, a workaround seems to be to place an armored vehicle (maybe a Hummer) inside the cap radius to prevent other armor to insta-cap.

Just a hypothesis for now.

[bitboy]

cfrag,

 Nice analysis, I think you're on to something there. I'll see what "cages I can rattle" to see if ED can provide a definitive answer or definition to the capture rules.

Thanks!

[bitboy]

cfrag,

 So looks like there is indeed a hierarchy for airbase capture. Check out this post from November 2023. 

The testing Grimes conducted appears to clearly call out a hierarchical order, a good list to keep note of for sure. Nothing scripting wise to fix this per se, it's as you mentioned more of how ED has designed the rules. Either way it's enough clarification for me, I'll just keep this little list handy and go from there. 

Thanks,

bitboy

[Recluse]

Interesting effect on farpZones since the Resource Vehicles are auto-spawned with the coalition (and country) that owns the FARP. I believe they are STATICS, so maybe they have that extra power that was observed in the testing above.

I was expecting to see some hierarchy, but I didn't get a capture until the Resource static vehicles were destroyed.  I didn't test exhaustively, though, so maybe a SINGLE Armor unit doesn't beat all the Resource vehicles.  The armor unit WILL kill the Resource statics

Before the FARP is captured, the units (or an airstrilke) have to kill all the the resource vehicles, so it requires some pretty good firepower. A squad of 4 M249 soldiers managed to eventually kill them and capture the FARP, but I guess a single infantry unit shouldn't be used as a capture element in that situation. So not sure about the hierarchy here.

 

Edited February 8, 2024 by Recluse

[cfrag]

7 hours ago, Recluse said:

Interesting effect on farpZones since the Resource Vehicles are auto-spawned with the coalition (and country) that owns the FARP. I believe they are STATICS, so maybe they have that extra power that was observed in the testing above.

That's a good point. I've done some more tests, and think that there are some more rules involved. If FARPS have functioning services, the can't AFAIK use static objects, they must have AI Units. Now, looking into their descriptions, many of those vehicles have an attribute

["NonArmoredUnits"] = true,

and all infantry have the same attribute

["NonArmoredUnits"] = true,

which leaves me to posit that DCS looks for the "NonArmored Units" and if so, discounts any unit when a unit appears that has an attribute 

["Armored vehicles"] = true,

like the BRDM-2. 

To test this, I used @bitboy's test mission, and exchanged one of the infantry soldiers with a Refueler ATMZ-5, which has the "NonArmoredUnits" attribute. The entire zone was captured when the "Armored Vehicles" Scout entered the zone. So I think that this adds evidence to the hypothesis that there is a (as of now undocumented) more complex rule set at work than simply 'any unit captures when empty, else contested'.

8 hours ago, bitboy said:

Check out this post from November 2023. 

Somewhat belatedly I now realize that goldfishbrained me even participated in that discussion <blush>>

 

[bitboy]

Very interesting indeed, good info.  

Well don't be too harsh, your "Goldfish Brain" came up with DML and that's pretty slick. Coach Lasso would be proud. 

On another note, the heloTroopsConfig module, in terms of the "legalTroops" attribute, I've tried adding a Mortar 2811 to the list, however the group fails to appear as a pickup option in the Airlift troops section. Is this because it's not "infantry"? Would an edit to the Helo Troops LUA make that possible? (Not planning on doing that, just curious.) Not looking  at the whole sling loading thing, but the ability to transport a small mortar team would be nice. Maybe it's something already in the works for the next DML version? 

Thxs

Edited February 8, 2024 by bitboy

[cfrag]

54 minutes ago, bitboy said:

I've tried adding a Mortar 2811 to the list, however the group fails to appear as a pickup option

Can you check the typestring? According to DCS that type is 

2B11 mortar

Note "B" (letter, not number), and case

 

Edited February 8, 2024 by cfrag

[bitboy]

Yes that's correct, 2B11 mortar as you indicated (my feeble eyes fail again). I used the MrSkortch DB of units and just copy-pasted. I also tried just added it as a single entry for the legelTroops and with a copy and paste of the defaults units in documentation....along with adding it at the end of the string. Also added the mortar to the spawners for the Helo Troop pickup areas. If the mortar is considered a "legal unit" at the LUA level, in other words there are no restrictions to adding artillery to the list, versus adding armor for example, then I'm likely doing something wrong. 

[cfrag]

19 minutes ago, bitboy said:

I'm likely doing something wrong. 

welcome to my world

It seems to work for me (see demo below). Let's see your config zone.

morty me.miz

[cfrag]

49 minutes ago, bitboy said:

I'm likely doing something wrong. 

... and in case you are wondering: I'm in the process of putting together the next DML drop, and am realizing that I've fixed something in heloTroops with regards to 'legalNames'. So maybe that was the issue. You'll soon find out

 

[cfrag]

Version 2.0.2 - Feature Update -  20240208

So here's the bad news, and I'll tell it straight: DML has been a tremendous success, and support from the community (you) has been great. Unfortunately, this can attract less savory characters, and now it has happened:

This release of DML contains a module of dubious provenance: "Scribe". It's a bean counter module. Often requested (under the preamble: "not for me - for a friend of mine"), I have now created a module that sits in the background, eats processor cycles and simply tabulates what people are doing. Added benefit? Like in real life - very few. But for some damned reason it scratches an itch that many people have: to see some numbers.

Scribe only counts player's actions: engine start-ups, take-offs, landings, crashes, and stick time. All itemized by airframe and total (Of course). And yes, it comes with persistence to boot (them beancounters are difficult to get rid of). If you are developing a mission, especially an open-ended server based mission (like Marianas Proving Grounds or the soon to be released rescue server mission "Angels Of Caucasus", which is currently in open stress-test on my "DML Testbed" server and is slated for release soon) people seem to really like this stuff (or maybe us pilots are naturally drawn to tables and statistics - fact is, we simply like the comfort of solid numbers).

To make matters worse, Scribe is going to follow the nature of their professions and going to expand: it is going to be the first module that will support cross-mission persistence, and be able to share data among multiple missions, so soon you'll be able to link scribe from multiple missions to a single shared source, allowing your players to accumulate data across multiple missions.

If you delve deeper, you'll notice another new addition, the "names" module. It's currently in there solely for csarManager's new ability to generate realistic names for missions. Why? Because I could. As a non-mission placeable module, "name" has no documentation. Oh yeah - I've also added a couple of nice features to csarManager: integration with Scribe, and a time limit so that missions now can expire.

All changes in Detail:

Documentation
    Main
        - scribe (new)
        - various: corrections, clarifications 
        - demo - On the Record (stub)
    
    QuickRef
        - scribe (new)
        - various: corrections
        

Demos    
    - On the Record (Scribe)
    
Modules 
    - Bomb Range 1.1.1
        - clean up 
    
    - cfxMX    
        - new groupHotByName XRef dict 
        
    - csarManager 3.1.0
        - *rnd option for mission names (requires names module)
        - missions are sorted by distance 
        - mission time limit implemented 
        - pickupSound attribute 
        - lostSound attribute 
        - integration with scribe 
        
    - dcsCommon 3.0.2
        - getPlayerUnit() new 
        - new createStaticObjectForCoalitionInRandomRing()
    
    - heloTroops 3.0.2
        - fixed an issue with legalTroops 
        - fixed a typo in a menu 
        
    - messenger 3.1.0
        - msgGroups supports multiple groups 
        - msgUnit supports multiple units  
        
    - names 1.0.0 - initial release 

    - radioMenu 2.2.1
        - corrected activation of ackD
        
    - scribe 1.0.0 - initial release 
    
Enjoy,
-ch

 

Edited February 8, 2024 by cfrag

[Panthir]

3 minutes ago, cfrag said:

Version 2.0.2 - Feature Update -  20240208

So here's the bad news, and I'll tell it straight: DML has been a tremendous success, and support from the community (you) has been great. Unfortunately, this can attract less savory characters, and not it has happened:

This release of DML contains a module of dubious provenance: "Scribe". It's a bean counter module. Often requested (under the preamble: "not for me - for a friend of mine"), I have now created a module that sits in the background, eats processor cycles and simply tabulates what people are doing. Added benefit? Like in real life - very few. But for some damned reason it scratches an itch that many people have: to see some numbers.

Scribe only counts player's actions: engine start-ups, take-offs, landings, crashes, and stick time. All itemized by airframe and total (Of course). And yes, it comes with persistence to boot (them beancounters are difficult to get rid of). If you are developing a mission, especially an open-ended server based mission (like <Marianas Proving Grounds> or the soon to be released rescue server mission "Angels Of Caucasus", which is currently in open stress-test on my "DML Testbed" server and is slated for release soon) people seem to really like this stuff (or maybe us pilots are naturally drawn to tables and statistics - fact is, we simply like the comfort of solid numbers).

To make matters worse, Scribe is going to follow the nature of their professions and going to expand: it is going to be the first module that will support cross-mission persistence, and be able to share data among multiple missions, so soon you'll be able to link scribe from multiple missions to a single shared source, allowing your players to accumulate data across multiple missions.

If you delve deeper, you'll notice another new addition, the "names" module. It's currently in there solely for csarManager's new ability to generate realistic names for missions. Why? Because I could. As a non-mission placeable module, "name" has no documentation. Oh yeah - I've also added a couple of nice features to csarManager: integration with Scribe, and a time limit so that missions now can expire.

All changes in Detail:

Documentation
    Main
        - scribe (new)
        - various: corrections, clarifications 
        - demo - On the Record (stub)
    
    QuickRef
        - scribe (new)
        - various: corrections
        

Demos    
    - On the Record (Scribe)
    
Modules 
    - Bomb Range 1.1.1
        - clean up 
    
    - cfxMX    
        - new groupHotByName XRef dict 
        
    - csarManager 3.1.0
        - *rnd option for mission names (requires names module)
        - missions are sorted by distance 
        - mission time limit implemented 
        - pickupSound attribute 
        - lostSound attribute 
        - integration with scribe 
        
    - dcsCommon 3.0.2
        - getPlayerUnit() new 
        - new createStaticObjectForCoalitionInRandomRing()
    
    - heloTroops 3.0.2
        - fixed an issue with legalTroops 
        - fixed a type in a menu 
        
    - messenger 3.1.0
        - msgGroups supports multiple groups 
        - msgUnit supports multiple units  
        
    - names 1.0.0 - initial release 

    - radioMenu 2.2.1
        - corrected activation of ackD
        
    - scribe 1.0.0 - initial release 
    
Enjoy,
-ch

 

Great option

[bitboy]

The Bean counters!!! Like'em or not...they do make the world go round. DML 2.0.2 looks great, thanks for sharing. 

[bitboy]

cfrag,

Reference the Mortar addition to the heloTroops - legalTroops scenario. Ran your Morty and Me mission, worked just fine. The only difference from what I was doing is, I was using a requestable spawner to pop the mortar team in. I took your mission, added the spawner and presto it worked as expected. (I even used the now "old" Spawner 2.0.1 with the newer DML 2.0.2 stuff).

So my conclusion is, I probably fat fingered an entry on an attribute at some point. 

Thxs

 

[Recluse]

9 hours ago, cfrag said:

That's a good point. I've done some more tests, and think that there are some more rules involved. If FARPS have functioning services, the can't AFAIK use static objects, they must have AI Units. Now, looking into their descriptions, many of those vehicles have an attribute

["NonArmoredUnits"] = true,

and all infantry have the same attribute

["NonArmoredUnits"] = true,

which leaves me to posit that DCS looks for the "NonArmored Units" and if so, discounts any unit when a unit appears that has an attribute 

["Armored vehicles"] = true,

like the BRDM-2. 

To test this, I used @bitboy's test mission, and exchanged one of the infantry soldiers with a Refueler ATMZ-5, which has the "NonArmoredUnits" attribute. The entire zone was captured when the "Armored Vehicles" Scout entered the zone. So I think that this adds evidence to the hypothesis that there is a (as of now undocumented) more complex rule set at work than simply 'any unit captures when empty, else contested'.

Somewhat belatedly I now realize that goldfishbrained me even participated in that discussion <blush>>

 

So there is still something weird (or I am missing the obvious) about FARP support vehicles.

 

Here is a little mission (FARPCapTest.miz)that has a farpZone owned by RED with spawned Resource vehicles.  I have a Radio trigger to trigger either 1 or 3 Blue M2A2 to enter the zone.  In fact, you can trigger all four of them. They are initially set to ROE Weapons Hold and the FARP does NOT get captured when the Bradleys enter the zone.  It isn't until they kill some number of the resource vehicles (when they reach WP1 with ROE Weapons Free) that the FARP is captured.

 

 

NOW if I switch from a farpZone to a normal ownedZone, and place similar vehicles: (FARPCapTest2.miz)

null

A single M2A2 captures the zone immediately on entry. (note: I also increased the number of vehicles to 8 to mirror the FARPZone and the M2A2 still captured)

If I replace these with STATIC Vehicles, (FARPCapTest3.miz) a single Bradley AGAIN captures the FARP upon entry to the zone.

null

 

FARPCapTest.miz

FARPCapTest2.miz FARPCapTest3.miz

Edited February 8, 2024 by Recluse

[bitboy]

cfrag,

 Is there a means of using the Commander module to set specific orders for spawned troops? For example, it looks like requestable spawn helo troops default to "guard" which is fine, but is there logic in place currently that would allow orders like "assault" so that helo troops dropped into a LZ would behave like factory spawned units.....seek out enemy owned zones/factory zones and attempt to capture? 

 Currently they way I handle this is the DCS "Player can drive/control ground units" option, thereby letting players go to the F10 map and issue orders to deployed units.

Thxs

[cfrag]

1 hour ago, bitboy said:

is there logic in place currently that would allow orders like "assault" so that helo troops dropped into a LZ would behave like factory spawned units

Yes, especially in conjunction with spawners you can prepend 'wait-' to the orders, and these units wait around until picked up and only activate their 'real' orders when they are dropped by a helo.

[bitboy]

Excellent, I'll have to dive into the documentation to sort that out, probably review several of the example missions to see the config in action. Thxs

 

Update: Ok found exactly what I was looking for (Orders for Spawning units), it was there all along but I kept jumping over the section in rush to read the next cool thing. 

Edited February 8, 2024 by bitboy

[bitboy]

cfrag,

A few quick questions about the Spawn Orders. So I ran some tests this evening, I'm looking to have two types of groups spawn for Helo operations. One type would called Garrison and they would use the default order of Guard. The other group would be called Assault, the orders for this spawn group is attackOwnedZone.

Spawning works great, no issues with types (although I came across a typeMult attribute...tried it and it didn't seem to do anything), but formation and everything worked fine on the spawners. I had placed an enemy zone (a factory zone owned by Red with a few infantry defenders), nearby. When I dropped the Assault group they never moved, in fact I would get the message that they "deployed to the ground with orders to guard". (This was using the "wait-" parameter with the orders when they units first spawned in, prior to helo pickup).

The problem seemed to get resolved when I added a range parameter to the attackOwnedZone command. 

Does the attackOwnedZone command require a range parameter? (Well for me it did, in the documentation it appeared that it did not require it). ??  I was assuming behavior just like attackers produced at a factory...seek out and attack any enemy or neutral zones anywhere on the map.

What does the attribute typeMult do? (I was thinking it multiplied the number of unit types defined in the spawner?

BTW I like how the units indicate what there doing with attack commands, for example "Team -1 is engaging enemy forces at 2200 meters"

Thxs

 

[cfrag]

Well, that part of DCS is old, and harkens back to a time where I thought that we can do a lot more with AI that what currently is possible. Still, the things that groundTroops promises to do should still work, so let's see if and where there might be bugs (heloTroops has advanced a lot since then, groundTroops... not.)

5 hours ago, bitboy said:

Does the attackOwnedZone command require a range parameter?

I don't think so  if you have a demo miz, that would of course help, I'll try to track down those issues over the week-end. A miz that demonstrates the issue will shorten the time to for bug hunting and allow me more time to not document the scribe demo. What the attackOwnedZones command does need is an enemy-owned owned zone. Since I messed with zone ownership management, that may be a possible culprit, I'll check.

6 hours ago, bitboy said:

What does the attribute typeMult do? (I was thinking it multiplied the number of unit types defined in the spawner?

That is exactly it. The idea is that if you add "typeA" as types, and then set typeMult to 6, it should spawn a group of 6 typeA. Now, I need to go over the code to see if I screwed up the multiplication code, but it *should* support multiple types as well (e.g. "Type A, Type B" with mult 3 should get "Type A, Type B, Type A, Type B, Type A, Type B".  I'll have a look.