DML - Mission Creation Toolbox [no Lua required]

[cfrag]

11 hours ago, Sinclair_76 said:

The linked zone does not move, it stays in the original position

I believe that is because (as I see it in the mission that you kindly provided) you link the zone to a unit that is named '1' - but there is no unit with that name (you probably wanted to link to unit named "1-1" of group "1". Personally, I use non-numbered group/unit names to make the mission more readable)

silly null

If you turn on verbosity for the cloner, DML will put out a warning if it can't link that zone to a unit:

annoying null

Edited December 28, 2022 by cfrag

[Sinclair_76]

1 hour ago, cfrag said:

I believe that is because (as I see it in the mission that you kindly provided) you link the zone to a unit that is named '1' - but there is no unit with that name (you probably wanted to link to unit named "1-1" of group "1". Personally, I use non-numbered group/unit names to make the mission more readable)

silly null

If you turn on verbosity for the cloner, DML will put out a warning if it can't link that zone to a unit:

annoying null

 

Pretty sure I tried that as well. In the uploaded file iirc the UNIT NAME is the same as the linkedUnit (edit: it isn't but I tested that iteration as well, and for completeness done in the uploaded file below with same results).

The unit that servers as anchor (tank-1 in the new miz) is within a cloner zone (template). What I hope to do is clone the anchor (tank-1) with the linked unit zone L1. But at the start of the run tank-1 disappears. The linkedUnit zone L1 remains (as it is predicted). But once tank-1 clones to Tblisi the zone L1 remains and does not reattach to the cloned tank-1. I kind if thought (hoped) that even though the name would change with a cloning, the attached zone would be able to keep up.

 

test2.miz

Edited December 28, 2022 by Sinclair_76

[cfrag]

1 hour ago, Sinclair_76 said:

What I hope to do is clone the anchor (tank-1) with the linked unit zone L1.

Oh, now I get it! Unfortunately, cloners don't clone zones. Currently, DML behaves like vanilla DCS in that it does not create zones on-the fly. An interesting concept to think about for sure, but I would first have to figure out how this would integrate with the rest of DML (since DML modules are attached to zone, this would also have to be taken care of, and might well end in a recursive loop, or cause other inconsistencies).

I feel that I understand the modified example better (thank you for the added context), but it is still not entirely clear to me what you are doing: you have a clone zone "1" within a clone zone "L1". L1's cloner uses another template (cloner in zone "2") as source. So whenever L1 is triggered via a signal on f?, it clones the template from "2" (the ZBD) to somewhere within L1's area.

L1 is linked to  unit "tank-1" and moves centered on, and with, that unit. Now, since "tank-1" is inside a cloner "1", the unit 'tank-1' is removed when the mission starts up (standard cloner behavior. EDIT: Note that since L1 is using the source template, it does NOT remove units inside its zone). This means that there is no unit 'tank-1' for L1 to follow. Now, if you removed the cloner attributes from "1", the zone "L1" would only move once (to center on tank-1) and then no  more because "tank-1" itself isn't moving (it has no path). It seems to me that I'm missing one important piece of the puzzle, and once that I fully grasp what you are trying to do, we can get this resolved  

Also - just to make sure that this is intentional - with the current setup, you can use the "push flag 2" radio item exactly once to trigger the L1 cloner. Once flag "2" is set to 1, it remains at that value; subsequent issues of the radio command will not create new clones, because L1 cloner is set to trigger on changes on f?, and the value of flag "2" doesn't change when you set it to 1 when it already is 1.

Finally, silly me left a bug in the verbose messages for the cloner. I corrected that in the attached update.

 

test2newer.miz

Edited December 28, 2022 by cfrag

[Sinclair_76]

I am looking for high precision and low (or random) accuracy. 

I was hoping that the small linked zone (L1) could take care of the precision part and the randomized location of the tank could take care of the low accuracy.

12 hours ago, cfrag said:

Also - just to make sure that this is intentional

Yes. Small example is all. My full blown .Miz has all the DML bells and whistles. 

Edited December 28, 2022 by Sinclair_76

[cfrag]

Version 1.2.0

Feature Update: Support for ME's new 'LINK UNIT' ability in the Zone Editor

 

About that new LINK UNIT zone ability in ME 

The ability for a zone to follow a unit's movement is an important tool for any mission designer, and ME has provided some indirect and sparsely documented help for that. DML provides an expanded version of that for any zone (if only inside the context of DML) with the 'linkedUnit' attribute (and additional capabilities like following at a set distance, and turn with the unit it follows).

A few weeks ago (in December 2022), a new version of DCS 2.8 dropped, and it contained an unannounced, undocumented important update to ME's good old Zone Editor: the LINK UNIT drop-down. 

Since it's entirely undocumented, there's no certainty what and how this new interface element works, but I've made the bold deduction that it's going to be used to link this zone to the unit that can be selected in the pop-up.

After much research and experiments, I was able to integrate this new (much better from a UX perspective) zone-to-unit link-up into DML. One important decision was whether to remove the old method or keep two slightly different methods (attribute and pop-up) to basically achieve the same. After some analysis and deliberation, I determined that it would be best to keep both, even if it may be slightly confusing:

• Backwards compatibility. If DML dropped the 'linkedUnit' attribute, all missions that use linked units would have to be updated to the new method.
   
• The abilities are not the same. While ME's LINK UNIT is much, much easier to use and error resistant (bye, bye to mis-spelled unit names, and if you change the name of a unit that the zone is linked to, this auto-updates, a very nice feature), there is one case that is not supported: linking to units that spawn dynamically (i.e. aren't placed by ME). This may be an edge case, but it is an important edge case.
   
• Mitigation possible. DML now makes sure that if you use both methods (attribute and pop-up) to link a zone to a unit, it outputs a warning:
   

I expect that going forward, most designers will happily use the new ME-provided interface (i.e. the LINK UNIT pop-up), and use the 'linkedUnit' attribute to link zones to dynamically spawned units.

So, here it is: DML 1.2 - with a brand-spanking new integration of a new, fully undocumented ME feature that I hope ED will keep.

 

Changes in Detail

Documentation
    - Main 
        - new LINK UNIT ability, linkedUnit attribute clarifications
        - various corrections 
        
    - Quick Ref 
        - linkedUnit clarifications 

Modules 
    - cfxZones 3.0.0
        - moved common zone verbosity init to own method 
        - support for LINK UNIT as provided by ME's new zone ability 
    
    - dcsCommon 2.8.0
        - new API for collecting mission data on start-up 
        - added support methods for ME's LINK UNIT requirements 
        - new accessor methods for unit/group-specific mission data
        - semaphore groundwork (experimental)
        
    - cloneZone 1.6.3 
        - fixed a verbosity bug 
        - name scheme groundwork (WIP, not accessible in missions)
 

Enjoy,

-ch

 

[crispy12]

I'm trying to add a JTAC component to my mission. It's a killbox with random spawns on the ground, and I want to add in a JTAC Reaper MQ9

Can cloner zones utilise orders=laze? I don't seem to see any menu appear like the demo mission.

[cfrag]

1 hour ago, crispy12 said:

Can cloner zones utilise orders=laze?

They should, but I've never tested this for the simple reason that I've never set up such a mission. Can you create a short demo mission for me how this ussually works in ME, and I'll then try to see how this will fit in DML, and if it doesn't, how I can add this ability to DML  

Just so I can understand this correctly - what is the cloner supposed to clone: the targets, or the lazing drone, or both?

Thanks,

-ch

 

[crispy12]

I found cloner overall very much simpler to use, so i've been using it as a spawn zone.

I setup a MQ9 Reaper over the killbox in an racetrack orbit and set it as a clonezone and spawn on mission start. Then I would like to add a command for orders - laze to lase any targets in the killbox area.

I tried to do it with a spawner using the Reaper but didn't seem to work on first try. I will try again later.

[cfrag]

24 minutes ago, crispy12 said:

I found cloner overall very much simpler to use, so i've been using it as a spawn zone.

I agree, the cloner should be able to to it and be the best choice for this task. But since I'm very capable to screw up the code, the cloner may need a fix.

Can I trouble you to please attach a mission with the 'vanilla' (i.e. ME only) setup that I can then try to integrate into DML?

Edited January 2, 2023 by cfrag

[cfrag]

Version 1.2.1

Feature Update: Highly advanced new CloneZone abilities

 

To paraphrase an (admittedly very complimentary) comment: "Clone Zones alone make it worth adding DML to your mission".

Well, CloneZones just got significantly better. The recent addition of ME's ability to directly link zones to units made me take a closer look at cloners, and how their clones can't trigger ME-based conditions.

Well, now they can - and they can do a lot more. Unlike previous DML releases, this one focuses entirely on advanced mission design topics, as everything that I added in the past weeks will likely be useful only to mission designers who have some mission design experience under their belt.

CloneZones now sport new, optional abilities:

• to create "identical" clones to a template that can trigger ME conditions for groups and units
• to name units according to new name schemes. When a unit is cloned, and the name scheme matches an existing unit's name (which CloneZone assumes is intentional, hence the "some experience" above) it automatically adds all required information so that the clone will work with ME's trigger conditions for units.

The new nameScheme cloner ability is exceedingly powerful, as - in the right hands - it can be used to exploit some DCS mission idiosyncrasies to successfully pull of tricks that are impossible in ME: units that defect to another coalition, groups that have different compositions, yet still trigger ME unit conditions,  groups that can 'recover-spawn' etc.

I encourage you to read the updated documentation on cloners, and then proceed to the new "Hope you guess my name" demo's description. 
Caveat Emptor, though: this is advanced stuff, and entirely unnecessary to be able use DML. It merely shows off to what depth DML can go to support your mission design.

Changes in Detail

Documentation
    - Main 
      Updates to CloneZones 
      Demo Hope you guess my name (new)
      
    - Quick Ref
      Udates to CloneZones
      
Demos
    - Hope you guess my name (Advanced Clone Concepts) - new
    
Modules
    - cfxMX 1.2.5 
      added new name-to-unitID cross reference 
      
    - ObjectSpawnZones 1.3.1
      baseName can be set to zone name by using "*" shortcut 
      
    - SpawnZones 1.7.2
      baseName can be set to zone name by using "*" shortcut 
      
    - cfxZones 3.0.1
      improvements to linked zone tracking
      
    - CloneZones 1.7.0
      wildcard "*' for masterOwner 
      new identical attribute 
      new nameScheme attribute 
      
    - dcsCommon 
      minor sanity checks for bearingFromAtoB
      
Enjoy,

-ch

Edited January 12, 2023 by cfrag

[Sinclair_76]

Can't wait to dig in. This will be awesome. 

 

[Poker03]

This is awesome in multiple ways!!!

I just made a very quick test, modding your demo.

I changed the "Recoverer" unit to an A10 in flight, and tested it out. I also tried using DML link zones and I also included the useHeading potion to have the A10 respawning in the same heading it was....

In any of the tests, the outcome was always the same.... the plane dissapeared and appeared 2 times (gone-back-gone again-and finally back). So it looked like  on the first Matrix Movie, when they see a Cat repeating the movement (déjà vu) .

Is that normal? Should I consider anything else while trying to clone an alive/flying plane (as yo said, to keep it flying longer, or changing coalition , and such tricks)?

Is there any advantage in using the TE link zone or the DML linkedUnit ?

I also test a multi waypoint route, saving in a variable the actual waypoint, so on every leg, I order the jet to go to the real actual waypoint (on the variable), so it will do so even after being cloned.

Any other advise for fast jets to make this tricks work properly?

 

And, big time thanks for your awesome work!!!!! Keep it up!

 

[cfrag]

3 hours ago, Poker03 said:

I changed the "Recoverer" unit to an A10 in flight, and tested it out. I also tried using DML link zones and I also included the useHeading potion to have the A10 respawning in the same heading it was....

I'll have to check this myself - if possible, please post (or PM) the mission that illustrates the issue so I can be lazy  

3 hours ago, Poker03 said:

In any of the tests, the outcome was always the same.... the plane dissapeared and appeared 2 times (gone-back-gone again-and finally back). So it looked like  on the first Matrix Movie, when they see a Cat repeating the movement (déjà vu) .

Is that normal?

It's most likely a result of a strange DCS quirk where it refuses to clone aircraft groups with existing ID (though I haven't seen such issues with ground forces). CloneZone knows about this issue, and checks the resulting clone against the ID it should have been issued (because otherwise, ED trigger zones won't work with ID-mismatched groups), and re-spawns the group every second until it works. That is the only way to guaranteed that a cloned group with 'identical' attribute will work with ED trigger zones.

The reason that it jumps back matrix-style multiple times is most probably the result of the ID mismatch: the moving zone (when set up using ME's unit pop-up) does not match the new spawn, and remains at the old location. I would hazard a guess that if you use the 'linkedUnit' attribute (which does not use the ID but unit name to follow a zone) instead of the pop-up, that the effect would be less visible (but it would still be there).

 

3 hours ago, Poker03 said:

Is there any advantage in using the TE link zone or the DML linkedUnit ?

ME's version is easier to use, and has some UI niceties (if you move the unit that you linked a zone to, the zone moves with the unit). In order to link a zone to a unit, that unit must exist in ME and the only way to use this with cloners is by using the 'identical' attribute

linkedUnit is more flexible (it can link against units that do not yet exist in the mission) and the only condition for it to work is that at some point in time there will be a unit with the name you specify. Downsides: it can result in errors should you misspell the unit's name and isn't as nicely integrated into the UI.

-ch 

 

Edited January 14, 2023 by cfrag

[Sinclair_76]

In a cloner zone

the source attribute won't work if it is a string of flags say 2-6. It only seems to work if the flags are seperated by a comma. 

Ie

null

Is that a bug or by design?

[cfrag]

2 hours ago, Sinclair_76 said:

Is that a bug or by design?

Good point, thank you for the question! 

DML indeed supports ranges (like "9-13") in flag names, and this harkens back from the days when flag names where number-only, yet they are still supported today.

The source attribute references zone names, and those always supported the entire character set. If I wanted to support numerical ranges (e.g. "2-7") that would mean that I had to to find a way to discern between a zone named "2-7" and the range of zones named "2" through "7". In other words, it would no longer be easy (from a user and coding perspective -- and I'm lazy ) to distinguish between a zone name with a hyphen '-' and a range. Since one of DML's biggest advantages is that you can set up zones to to be self-contained (by using local flags), and then litter the map with pasted copies of such a zone automaton, and since pasted zone names always default to a name with '-' in it, I conveniently decided against supporting numerical ranges when referring to source zones.

So, "It's not a bug, it's a design feature".

Edited January 15, 2023 by cfrag

[Poker03]

En 14/1/2023 a las 19:34, cfrag dijo:

I'll have to check this myself - if possible, please post (or PM) the mission that illustrates the issue so I can be lazy  

It's most likely a result of a strange DCS quirk where it refuses to clone aircraft groups with existing ID (though I haven't seen such issues with ground forces). CloneZone knows about this issue, and checks the resulting clone against the ID it should have been issued (because otherwise, ED trigger zones won't work with ID-mismatched groups), and re-spawns the group every second until it works. That is the only way to guaranteed that a cloned group with 'identical' attribute will work with ED trigger zones.

The reason that it jumps back matrix-style multiple times is most probably the result of the ID mismatch: the moving zone (when set up using ME's unit pop-up) does not match the new spawn, and remains at the old location. I would hazard a guess that if you use the 'linkedUnit' attribute (which does not use the ID but unit name to follow a zone) instead of the pop-up, that the effect would be less visible (but it would still be there).

Sure... 

Same as your demo but changed the ground unit to A10... just use the F10 menu to Spawn the unit, and look at it from the F10 map, or later on the ACMI...  

As said, it really didn´t matter how I linked the zone to the unit (ME or DML style), it always warps a couple of times.

 

Hope there is a way to avoid the glitch.

 

Thaaanks and keep it up!!!!!

 

TEST RESPAWN in FLIGHT.miz

[JimmyWA]

Thank you for what must be an inordinate amount of time working on DML! It is a brilliant add on.

In case someone else has this problem. I've just spent hours trying to work out what I was doing wrong. I had read the manual - yes, truly - and wanted to setup a FARP zone. I placed my DCS FARP heliport, FARP, then created a trigger zone extending a little way out from it. When I went to run the mission I kept getting the error [string "FARPZones = {}..."]:247; Parameter #3 (point) missed....  I ended up removing all the optional parameters, still got the error. I triple checked I was loading the correct modules, overwrote them again in case I'd accidently put a corruption in the DML modules while copying. I wondered if it was because I didn't have the trigger zone right on the zoomed in all the way FARP zone. I looked at the function in the FARP.lua. I tried to work out what was different from my mission to the example one. Finally I noticed that the example mission had a much larger trigger zone than I had in my mission. Mine was set to 800, the example was around 7000 from memory. I went back and changed the trigger zone to 7000 and with just the FARP declared - no optional arguments added - it fixed it. It makes my FARP zone a lot larger than I wanted, but hey, it works, and I will see how low a circumfrance I can go without getting the error again.

I couldn't find anything about this in the large manual, so if I missed it apologies, otherwise can I suggest you add a warning about the minimum size of a FARP?

Edited January 16, 2023 by JimmyWA

[Hellfire]

Just off the top of my head, airbase and FARPs have their own DCS control zones so perhaps that has to be incorporated in the trigger zone.

[cfrag]

3 hours ago, JimmyWA said:

When I went to run the mission I kept getting the error [string "FARPZones = {}..."]:247; Parameter #3 (point) missed....

Ouch. This should not happen. I'll have a look, thank you for pointing this out. I may need some help from you to reproduce the issue, and if that's OK with you, I'll contact you in that case.

3 hours ago, JimmyWA said:

Finally I noticed that the example mission had a much larger trigger zone than I had in my mission. Mine was set to 800, the example was around 7000 from memory.

Although 7000 is the 'correct' size for a FARP (2km radius is the DCS standard for FARPS for capturing it), a DML FARP zone should simply attach itself to the nearest FARP, the zone size should not be an issue. I'll have a look. That being said, I'll revisit the manual (I'm impressed and happy that you RTFM'd!) to make sure that this aspect is better documented.

3 hours ago, JimmyWA said:

It makes my FARP zone a lot larger than I wanted

This is perhaps an important point I should make clear in the manual - the DML FARP zone inherits the DCS FARP's zone (2km) so it will always be that size. The other attributes, however, should work with the Trigger Zone size. 

21 minutes ago, Hellfire said:

FARPs have their own DCS control zones so perhaps that has to be incorporated in the trigger zone

There's a good chance I screwed it up somewhere  

[cfrag]

18 hours ago, JimmyWA said:

I ended up removing all the optional parameters, still got the error.

I found the issue. It seems that some idiot assumed that the FARP's trigger zone would always be placed in such a way that at least one FARP would be inside the trigger zone. If you placed the FARP Zone in close proximity, and made the zone's radius small enough to no not include a FARP Static, the code failed. 

This is now fixed. The changes will be rolled into the next update (scheduled for Thursday next week), and I've included a reference test mission that contains the corrected code below.

 

FARP Test 20230117.miz

Edited January 17, 2023 by cfrag

[cfrag]

On 1/16/2023 at 9:53 AM, Poker03 said:

Sure... 

Same as your demo but changed the ground unit to A10... just use the F10 menu to Spawn the unit, and look at it from the F10 map, or later on the ACMI...  

As said, it really didn´t matter how I linked the zone to the unit (ME or DML style), it always warps a couple of times.

Hope there is a way to avoid the glitch.

I've now had some time to look into this issue, thank you for the miz.

The issue is caused by a DCS oddity where it is unable to spawn aircraft groups with an ID that is equal to an existing or recently existing group. Clone Zones knows about this glitch, and - once it detects it happening - commences to re-spawn the group until DCS complies and spawns the group with the correct ID.

Now, how can we work around this DCS oddity? We could, if we didn't need the unit/group ID. Why do we need the group ID? Because we have set the spawner's trigger zone to follow the unit around and be able to respawn-resume from the last location it was observed alive.

So, can we get by without the aircraft ID? Yes, if we use DML's linkedUnit attribute 

How does it work? DML's 'linkedUnit' attribute homes in on a unit's name. ME's LINKUNIT uses a unit's ID. So, in a first step we need to break that habit of requiring the ID. All DML (not ME!) tracked zone support a 'linkedUnit' attribute that links a trigger zone to a unit, with two important distictions: the unit that the zone links doesn't have to exist in the mission, and you can give it any name you want. The link-up is made whenever that unit exists in the mission. 

So what we do are two things: 

• First, we remove ME's LINKUNIT <Replacer>, and replace that with a "linkedUnit=Replacer" attribute.
• And we have to make sure that a unit of that name will exist at some point in time. The 'identical' attribute could fit the bill, be we know about the DCS glitch that causes the unit to "blink" multiple times because of the ID mismatch. Enter "nameScheme" - we know that units that exist will be replaced by new units that have the same name. And that is exactly what we want, as it will replace the existing (or formerly existing) "Replacer" unit without the 'blink' issue, while retaining the zone following ability (DML homes in on unit names, not ID).  

So, if we followed above's instructions, the following will work without the unit blinking in and out of existence:

Now, above is the full-explanation resolution to the issue. There's an easier fix that I'm going to present now after the full explanation.

The 'real' issue is that DCS has issues with replacing aircraft groups by ID, and the resolution to that issue was using an equivalent "nameScheme" instead of "identical". DML itself is smart enough to make a trigger zone to follow a unit by name, even if that unit was designated via LINKUNIT. 

This means that a much shorter solution is to keep the LINKUNIT popup, and merely exchange 'identical' with the correct 'nameScheme'. 

See attached miz

Cheers,

-ch

 

TEST RESPAWN in FLIGHT resolved.miz

Edited January 18, 2023 by cfrag

[Sinclair_76]

How do you kill the list of active modules at the start or least limit the time?

[cfrag]

26 minutes ago, Sinclair_76 said:

How do you kill the list of active modules at the start or least limit the time?

My apologies, I'm having a slow brain day. Which modules and time for what?

 

[Sinclair_76]

10 minutes ago, cfrag said:

My apologies, I'm having a slow brain day. Which modules and time for what?

 

Slow brain day, story of my life

When you start a mission with DML modules, it will display the active modules for say 30 sec. Is there a way to limit the message to 5 seconds or so?
 

 

Edited January 18, 2023 by Sinclair_76

[cfrag]

10 minutes ago, Sinclair_76 said:

Is there a way to limit the message to 5 seconds or so?

You can't suppress nor limit the startup messages to 5 seconds directly - but you can easily add a "Message To All" action as last action in the load sequence that fires after 5 seconds and uses the Clearview checkbox. It's the easiest way to switch from test to a production mission, and can be edited quickly: