DML - Mission Creation Toolbox [no Lua required]

[cfrag]

Version 1.3.1 Major Feature Update -- 20230524

 
After unleashing the flareZone fireworks onto your missions with the last release, another high-octane eye-candy module hits DML: stopGap. Inspired by @Hardcard's seminal SWAPR script, and egged on by @Adalla, the stopGap module today makes it's DML debut. 

stopGap significantly dials up the 'wow'-factor of your missions: usually, all player aircraft slots on an airfield remain empty, making it a lonely experience when you start your engines in a big (read: many different player slots) mission. StopGap swoops in, and replaces all those gaps with static versions of the player planes. Your mission looks much better, and - depending on how many planes, and how many different planes you provide to your players) your frame rate can take a tiny (normally) to perceptible (on extreme missions) hit. Since the replacements are all static, they don't impact the mission's performance much.

Although the stopGap script has its own page here as a stand-alone module, the DML version - being able to rely on DML's powerful framework - is more powerful and easier to use. Admittedly, stopGap isn't that hard to use (you install it, end of story), so 'more powerful' is just me making pompous announcements.

Of course, as always there's a demo for you, with its own discussion in the manual. Oh, and speaking of the shock block: it's now officially "not short".

Then:
It took me a while, and I've now finally completed upgrading (or as we nerds say 'refactoring') the 'ownedZones' module with a bunch of now abilities. During this upgrade process, I separated unit production from ownership, and gave the production stuff its own module: factoryZones. Taken together, ownedZones and factoryZones have gained the following abilities:

 

• zones can now (optionally) be captured by helicopters, planes (very tricky to do unless you are in a Harrier), and naval units. And yes, this means that now water-borne ownedZones (e.g. around oil rigs) are possible.
• they support quad-based (polygonal) zones (finally!)
• custom color schemes. You are no longer restricted to boring red/blue/grey. You now have access to the full RGBA color space. 
• factories use a powerful 'inheritance' model for production that makes it much easier to set up which units a factory produces for which faction.
• a host of additional outputs! for your missions to create signals for other modules as input?
• 99% backward compatibility of ownedZones and factoryZones to the legacy (pre 2.x) version of ownedZones (you may need to add a 'factory attribute for some zones)

There are now two additional demo missions dedicated to conquered zones and factories, and the original demo mission's documentation (using the legacy version of the module) has been amended. The legacy version of ownedZones remains in DML and will be maintained if necessary (bugfixes only). 

Taking to heart some comments from you guys, I spent a good part of the last two weeks revising the main manual's section on flags. It's not a complete overhaul, but I hope that the new graphics and explanation help to understand this somewhat esoteric, yet fundamental topic. My thanks to you for the feedback - keep it coming!

All Changes
Documentation
    Main 
        - flags in DML (rewrite) 
        - liveNumber '#' attribute definition 
        - stopGap documentation (new)
        - factoryZone documentation (new) 
        - ownedZones documentation (rewrite)
        - various modules: update (mainly # attribute updates)
        - no gaps no glory demo documentation (new)
        - owned zones ME integration demo (update)
        - my first factory demo documentation (new) 
        - owned zones and factories demo (new) 
        
Demos 
    - my first factory (new)
    - no gap, no glory (new)
    - once, twice, three times a maybe (update)
    - owned zones and factories (new)

Modules
    - cfxGroundTroops 1.7.8
        strengthen guards before envoking ownedZones methods 
    
    - cfxMX corrected typo in remarks, no change 
    
    - cfxOwnedZones 2.0.0 
        - massive rewrite 
        - colors for zones 
        - capture by sea, air possible 
        - poly zone support 
    
    - cfxZones 3.1.0
        - RGB zone property handling 
        
    - factoryZone 2.0.0
        - split from owned zones 
        - production inheritance 
        - poly zone support 
    
    - limitedAirframes 1.5.4
        - red# and blue# attribute naming updates 
        
    - mxObjects experimental module, do not use 
    
    - playerZone 1.0.1
        - pnum# attribute name update 
        
    - stopGaps standalone (new) 
    
    - stopGaps (new)
    

Phew! Enjoy,

-ch

Edited May 24, 2023 by cfrag

[HungryCoyote]

Looking for bare minimum for zone capture. What am I missing?  Zone Capture Test.miz

[cfrag]

18 minutes ago, HungryCoyote said:

What am I missing?

An 's' in "OwnedZonesConfig"

Everything else is perfect

 

[Panthir]

Dear Cfrag, 

Many thanx for StopsGap module. Excellent support mate. We thank you for your effort. StopsGaps is a very interesting addition that it was missing from DCS. 

Moreover, I have an idea regarding StopGaps future options. I don’t know if it is already implemented but it would be a very interesting, plus realistic, feature to have the option to deactivate the slot of which the static aircraft - helo will be destroyed. In this context all enemy forces will be able to be targeted on ground and by destroying an aircraft on ground you will reduce the available enemy slots.

Edited May 25, 2023 by Panthir

[HungryCoyote]

I knew it had to be something simple. Thank you.

[HungryCoyote]

So I found a work-around to capture an off shore, elevated zone by slingloading. I used a trigger condition Cargo Unhooked to Group Activate a naval unit that actually captures the zone.

Zone Capture By Slingload.miz

[cfrag]

18 hours ago, Panthir said:

I don’t know if it is already implemented but it would be a very interesting, plus realistic, feature to have the option to deactivate the slot of which the static aircraft - helo will be destroyed

If you use DML's ssbClient for this (setting 'single-use' to true), that is automatically supported.

[t349733591]

Hi cfrag: This is a great work,Owned Zones are there any plans to incorporate the concept of airspace in the future,For example, my plane enters a certain area and competes for it in the air. Currently, I have a project that is mainly focused on air combat, but I want to add the concept of an area. However, it is not currently supported for my plane to occupy a certain area in the wilderness. It would be great if I could choose whether the plane needs to land and occupy it.

[cfrag]

9 minutes ago, t349733591 said:

any plans to incorporate the concept of airspace

That sounds like an interesting idea that I'd love to explore further. 

How would such a concept work? Who 'owns' an airspace when, and what are the conditions for a change? 

[t349733591]

Great cfrag:

At present, the creation of Factory Zone is excellent, but there is still a problem as always, which is that when I need to generate units, I need to search for and input a large number of unit names to meet the requirements of unit generation. Although factory can now be used as a value, I need to input a large number of unit names on the factory for countless regions. Can I use a source attribute like cloning to generate units using the name of this template region? This will save a lot of work.

[t349733591]

21 minutes ago, cfrag said:

That sounds like an interesting idea that I'd love to explore further.

How would such a concept work? Who 'owns' an airspace when, and what are the conditions for a change?

The concept of airspace, based on Owned Zones, only transforms occupation from ground to sky, but there will be a conflict in the middle, which is how ground units enter this area and how to judge it. My idea is whether there can be some restrictions on the area, allowing developers to choose whether this area should be used as an air or ground contention point. If it is an aerial battle point, only fixed wing occupation is supported. This will further enrich my mission and require air support to achieve victory. Make fixed wings no longer just a part of ground reinforcement, and air combat a part of the mission.

[t349733591]

28 minutes ago, cfrag said:

这听起来是一个有趣的想法，我很想进一步探索。

这样的概念如何运作？谁在何时“拥有”一个空域，改变的条件是什么？

Air occupation does not require landing, just like Owned Zones. If both sides exist and become a neutral zone, when only one side is left, it belongs to that side until enemy planes enter this area before changing the ownership of this area

[cfrag]

9 minutes ago, t349733591 said:

only fixed wing occupation is supported

That's the part that I think we should clarify more. How does one side gain ownership over an owned zone, how does one side lose it? 

For example, assume that we have zone Z. There are 3 red helicopters inside the zone, and one red attack craft. Also, there are 2 blue fighters in the zone, 10 blue tanks on the ground, and 3 blue missiles in the air.

Who owns the zone? And at what point would that side lose the zone? What are the rules?

Edited May 26, 2023 by cfrag

[t349733591]

8 minutes ago, cfrag said:

这是我认为我们应该进一步澄清的部分。一方如何获得拥有区域的所有权，一方如何失去它？

例如，假设我们有一个z区域，在这个区域内有三架红色直升机和一架红色攻击艇。此外，该区域有2架蓝色战斗机，10辆蓝色坦克在地面上，3枚蓝色导弹在空中。

谁拥有这个区域？那一方在什么时候会失去这个区域？规则是什么？

 

If this area is set as an airspace area, only aerial units will be judged as belonging conditions for this area. Ground units have no impact on this area. The judgment rule is the same as on the ground, where both sides exist in a neutral area. The ownership is only changed when only the red or blue air units are left.

[cfrag]

1 minute ago, t349733591 said:

The ownership is only changed when only the red or blue air units are left

That should be doable, and I think we may want to refine the rules:

• are helicopters air units (I'd say yes)?
• How about missiles (no),
• parachutes (no).
• In order to count, units must be in the air (aircraft on the ground should not count, neither should dead aircraft inside the zone). For example, a Harrier that lands inside the zone should not count, but a Hind hovering above it should.
• What about overwhelming numbers? Let's say Red has 15 Flankers in the zone, blue enters with a single C-130 transport Hercules. Who owns the zone? 

Also - who keeps a zone? Let's assume that blue gains ownership of a zone after destroying all red aircraft. Blue aircraft then leave the zone. Who owns it after the last aircraft left?

 

[t349733591]

13 minutes ago, cfrag said:

这应该是可行的，我认为我们可能需要完善规则:

• 直升机是空军吗(我会说是的)？
• 导弹怎么样(没有)，
• 降落伞(没有)。
• 为了计数，单位必须在空中(地面上的飞机应该不计数，也不应该在区域内死亡的飞机)。例如，一只落在禁区内的鹞不应该被计算在内，但是一只在它上方盘旋的雌鹿应该被计算在内。
• 压倒性的数字呢？假设红色有15个侧翼，蓝色带着一架C-130运输机进入。谁拥有这个区域？

还有，谁有区域？让我们假设蓝色在摧毁所有红色飞机后获得一个区域的所有权。蓝色飞机随后离开该区域。最后一架飞机离开后谁拥有它？

 

You are really a great author with great ideas, well thought out, and I think you are already conceptualizing how to achieve him.To avoid a lot of judgment work, can we just categorize all fixed wing aircraft and helicopters into one class (Air Force class) and use only these units as the judgment criteria for this area, and no other units will provide support for the judgment criteria for this area? However, I currently do not have a good idea how to integrate them into OwnedZones, as OwnedZones is occupied by ground units.The first three rules are very correct，The unit must be in the air, This is a very important judgment condition，What about overwhelming numbers?(Regardless of quantity, as long as it exists simultaneously, it is judged as a neutral zone)Who owns it after the last aircraft left?(Due to being previously owned by the blue side, all aircraft will also belong to the blue side after leaving, and ownership will not change until a red plane appears in this area)

[t349733591]

52 minutes ago, cfrag said:

这应该是可行的，我认为我们可能需要完善规则:

• 直升机是空军吗(我会说是的)？
• 导弹怎么样(没有)，
• 降落伞(没有)。
• 为了计数，单位必须在空中(地面上的飞机应该不计数，也不应该在区域内死亡的飞机)。例如，一只落在禁区内的鹞不应该被计算在内，但是一只在它上方盘旋的雌鹿应该被计算在内。
• 压倒性的数字呢？假设红色有15个侧翼，蓝色带着一架C-130运输机进入。谁拥有这个区域？

还有，谁有区域？让我们假设蓝色在摧毁所有红色飞机后获得一个区域的所有权。蓝色飞机随后离开该区域。最后一架飞机离开后谁拥有它？

 

Great cfrag, this is my perspective on the future of this feature. When there are no aircraft in the airspace at the beginning of the mission, only the initial value can be used as the ownership of airspace, such as the airspace of a certain country. If another country's fighter jets appear, can we understand that this airspace is already a war zone? It is controversial. If there is no counterattack, the airspace will be lost. Of course, as a reward for territorial competition, the designer can generate more ground units for the occupying party. In such a mission, airspace will also serve as an important condition for victory, causing competition between both sides. This will be great. In addition，You are really a great developer.

[cfrag]

On 5/24/2023 at 11:39 PM, HungryCoyote said:

So I found a work-around to capture an off shore, elevated zone by slingloading.

Hmmm. Can't you just drop off some soldiers (e.g. using HeloTroops)? I *think* that should be possible (have not tried, may try over the week-end)

[HungryCoyote]

 I want people to be required to actually slingload to capture the zone.

Edited May 26, 2023 by HungryCoyote

[ClausHoffmann]

Dear CFRAG,

thank you very much for this awesome tool-set. Comming across DML by coincidence I used two modules (civAir and stopGaps) in a mission I am working onright now for quiet some time already. I am thrilled by the ease of use and the stable results. Using your tool-set frees up time for the real content development in a mission. Thank you so much for your work. I am enjoying the extended functionality in my mission very much.

Best regards

Claus Hoffmann

[cfrag]

Version 1.3.2 -- Feature Update -- 20230607

After adding stopGap last time (a surprisingly well received module, thank you for your kind comments!), this update brings an add-on module to stopGaps: sittingDucks. while stopGap makes player slots visible on your airfield, sittingDucks makes player slots vulnerable.

This multiplayer-only module adds new possibilities to missions: it makes it a viable option for players to attack the other side's airfields to deny that side access to some aircraft, while it also requires players to defend their airfield from enemy players to retain access to their own strategic aircraft. Like stopGap before, sittingDucks is an DML-expansion on my "sittingDucks standalone" module, adding DML-only QoL features like the ability to turn it on/off at will, and open up access to restock time to mission designers simply providing a config zone.

Then, people responded well to the ability to add their own colors to owned zones, and - admittedly after some prompting - I have now added a the ability to define colors in a more common way that is reminiscent of CSS/HTML: for example, "#CC3300" is a deep, firetruck red (see below).

And the PlayerScore module has received another important update. Until now, it displayed individual player scores. It now can display coalition score as well. This presented a number of problems, since players can (and do) change their affiliation with a coalition over the course of a mission (especially on long-running missions on a server). Thus, a player's score is held separate from the coalition they are affiliated at any given time, and when they score, that score is added to that of the coalition they currently are aligned with.
But since we live in today's world, there's always the possibility of 'griefers', people who revel in childish behavior and spoil other people's fun. To prevent that kind of behavior from impacting a coalition's score, PlayerScore only adds a score to a coalition if it is positive, and discards negative player contributions. Thus, a player's anti-social behavior cannot negatively impact a coalition's score. Of course, if you can ensure that you don't have to deal with that kind of people, turning this feature off, and allowing unlucky players to ruin their coalition's score is just one attribute away. 

All Changes
Documentation
    Main
        - Sitting Ducks documentation (new)
        - Various updates 
        - Sitting Ducks in a Barrel Demo Documentation (new) 
        - Caucasus Hangar demo documentation (new)
        
    QuickRef
        - Sitting Ducks (new) 
        - Various updates 

Demos
    - Sitting Ducks in a Barrel (new)
    - Caucasus Hangar (new)
    - Later Score (update)
    
Modules
    - cfxOwnedZones 2.0.1
        - allow #RRGGBBAA as color definition 
    
    - cfxPlayerScore 2.1.1
        - coalition score 
        - noGrief option 
        - coalition check of touch-down zone 

    - cfxPlayerScoreUI 2.1.0
        - access to coalition score 
        - soundfile control cleanup 
    
    - cfxZones 3.1.1
        - Access to RGB and RGBA attributes 
        - owner clean-up (global)
        
    - dcsCommon 2.0.8 
        - new RGBA handling methods 
        - new coalition handling methods 
    
    - missionRestart (experimental) 
    
    - sittingDucks standalone 1.0.0 (non-DML) 
    
    - sittingDucks 1.0.0 
        - initial version 
        
    - stopGap 1.0.5
        - improvement to triggerMethod
 

Enjoy,

-ch

Edited June 7, 2023 by cfrag

[Panthir]

My dear Cfrag. Many thanx for your excellent job.

[TBear]

Hi all,

I made a very long lasting single player mission, with some random spawned cloned units (planes), so I'm using PERSISTENCY module to be able to save te situation.

I also spawn some friendly flights (flight escorts) through "radioMenu" module, as i learned from one of the Cfrag's video tutorials. Its all ok axcept the fact that I don't want that the radioMenu spawned units are persistent. I just want them to disappear everytime i leave the mission. I can't understand if it is possible and can't figure out how tho do it.

Thanks in advance for suggestions

 

Edited June 14, 2023 by TBear

[cfrag]

16 minutes ago, TBear said:

I don't want that the radioMenu spawned units are persistent.

I don't know how you create the friendlies that you order by a radioMenu, but if you are using a cloner, use the cloner's "wipe?" input before you save the mission, and that should remove all last spawns. Be aware that 'wipe?' only removes the units added during the last spawn cycle, as cloners do not retain information except for the last spawn. You may want to use a sequencer to first issue the 'wipe' input, and then trigger persistence a second or two later.

 

Edited June 14, 2023 by cfrag

[TBear]

like that?
 

Edited June 14, 2023 by TBear