Jump to content

DML - Mission Creation Toolbox [no Lua required]


Recommended Posts

4 hours ago, crispy12 said:

cfxGroudTroops.lua is also mispelled

It bugs me as well - like heck 😈. I'll hopefully get to change it for 1.0 - the reason I'm not doing it now is because of SCM's source tracking and I want to be able to revert.

Thanks for the heads-up, and keep them coming 🙂 

Link to comment
Share on other sites

Really love the work and quick updates you've put into your script. I made a training mission for our group - consisting of spawnable/despawnable SAM sites, patrolling armoured convoys, CSAR and static targets. All of which are toggled/triggered by F10 radio buttons.  Also included random BFM and BVR zone, incredible that I created that within 30 minutes. Best part is it's so easy to adjust later on for mission balancing purposes. Love the ability to create a huge clonezone/wiper - I can toggle on and off entire zones just with a single flag. Well done!

One thing i find is that i'm usually end up loading every single module in my missions. I know you made this to be lightweight and modular but with so many great tools... I tend to end up using all of them


Edited by crispy12
Link to comment
Share on other sites

Whats the difference between:

in?
spawn?
f?
clone?

In a clone zone attribute

And I've set up a bunch of static clones on a airfield. Is there any way to randomize that in the attributes of the zones? In stead of using flags?


Edited by Sinclair_76
Link to comment
Share on other sites

16 minutes ago, Sinclair_76 said:

Whats the difference between:

in?
spawn?
f?
clone?

They are all synonyms, and map to the same input. Synonyms are a purely user QoL feature and can be used to 'wire together' multiple modules on the same zone. If you look at the docs (big momma or quick ref):

Quote

DML Watchflag. When triggered, the cloner starts a new clone cycle. Defaults to <none>

You can use any synonym, but only one per zone

So use whatever you like best as long as you don't stack modules on the zone. If you do, make sure they mix well.

18 minutes ago, Sinclair_76 said:

And I've set up a bunch of static clones on a airfield. Is there any way to randomize that in the attributes of the zones? In stead of using flags?

Yes, quite easily so. When you supply multiple templates in the "source" attribute for a cloner, it picks one template by random each time you give it a signal on "clone?"

Quote

The source for the clone template, must be the name of a clone zone. When a clone cycle is initiated, the template is fetched from the source zone, and the units are then spawned around If this zone’s center.

If this attribute is present, this zone is not scanned for units to create a template from.

If you supply more than one template zone names, separated by comma (e.g., “SAM 9 small, SAM 9 big”), each time a clone cycle is initiated, the clone zone picks one template by random.

Defaults to <not present, zone scanned for units to create a template from

Have fun,

-ch

Link to comment
Share on other sites

2 minutes ago, cfrag said:

They are all synonyms, and map to the same input. Synonyms are a purely user QoL feature and can be used to 'wire together' multiple modules on the same zone. If you look at the docs (big momma or quick ref):

So use whatever you like best as long as you don't stack modules on the zone. If you do, make sure they mix well.

Yes, quite easily so. When you supply multiple templates in the "source" attribute for a cloner, it picks one template by random each time you give it a signal on "clone?"

Have fun,

-ch

I scanned the big one, as per RTFM guideline 😉

Just that I don't understand the difference between the stated synonyms. 

Also I placed empty templates in the source to randomize if the statics are there or not. Sometimes it's so simple.

Link to comment
Share on other sites

6 minutes ago, Sinclair_76 said:

Just that I don't understand the difference between the stated synonyms

Yes, I probably need to explain that better, thanks. As a non-native English speaker, some of my thoughts get lost in translation. 🙂 

So to be clear: you can use any of those, but only one per zone. They are different names for the same input, purely for convenience. Nobody said that was a good idea 🙂 

Here's the longform explanation:

Quote

Many modules offer multiple different names (‘Synonyms’) for the same input signal. For example, a clone zone can use the name ‘spawn?’, ‘in?’ and ‘f?’ all to trigger a new spawn cycle. When you set up your spawn zone, you can use one, and only one of these per Zone to trigger a cloning cycle.

Cool - but why?

The reason for this is to facilitate module stacking. In DML ‘module syntax’, most modules support the generic ‘f?’ or ‘in?’ as input. This makes sense, as it’s easy to remember, and often, if you stack modules on the same zone, you want them to trigger at the same time. Use a single ‘f?’, and all anchored modules that understand ‘f?’ as input will trigger when that flag changes.

In the example on the right, we have two modules that stack on the zone: a cloner, and a messenger. Both cloner and messenger support ‘in?’ as input flag (here set to flag 401). When flag 401 changes, both the cloner and the messenger modules activate and do their thing.

But what if you want to stack two modules that share the same input name, but you don’t want them to activate at the same time? A common case is if we build a small ‘circuit’ directly on the zone. The example on the right uses a delay module to delay the incoming signal on flag 200 by 2 seconds before passing it ‘out!’ on 201. Since 201 is ‘wired’ into the cloner’s ‘spawn?’ input, this causes the cloner to spawn 2 seconds after the timeDelay received a signal.

If we look at delayFlag’s and cloner’s documentation, we’ll find that they both share ‘in?’ and ‘f?’ as inputs. So we can’t use these synonyms as they would cause both to activate. We have to use an input name that we can tell apart: delayFlag supports the uniquely named ‘startDelay?’ input synonym (i.e. cloner does not recognize this attribute), while the cloner supports ‘spawn?’ (which delayFlag does not recognize). If we use the two synonyms that are not shared, we can connect the input lines to different signals, and thus are able assemble this little signal delay ‘circuit’ on the same zone without getting our attributes crossed.

 


Edited by cfrag
  • Thanks 1
Link to comment
Share on other sites

My compliments to you guys. I am not a programmer but I'm able to do some cool stuff. I'll bet this tool will create a new avenue for creative souls to design missions.

 

One thing I would really like is the ability to spawn units, as per spawn zone, at a random position within that zone. 

Link to comment
Share on other sites

25 minutes ago, Sinclair_76 said:

One thing I would really like is the ability to spawn units, as per spawn zone, at a random position within that zone. 

That should be easily doable, but usually with disastrously results: the unit could be placed inside buildings, water, on trees, or within other units. Let me see what I can come up with and you can decide if it's useful. I think I'll simply adding a 'randomizedLoc' attribute could engage that feature.   


Edited by cfrag
Link to comment
Share on other sites

Version 0.9986 - 20220428

Feature Update: baseCapture Module

We are ever getting closer to "1.0", and DML's architecture is stabilizing nicely. Not all features are even, and DML will have to undergo some clean-up, with creakingly old modules due for an overhaul post-dot-oh, but in all I'm quite happy with how DML progresses. 

This week includes a contribution by @cloose, who proposed and provided the initial code base for the new baseCaptured module that makes this update's feature: a module to create flag signals when a base (airfield, FARP, air service providing ship) is captured. Since ships currently can't be captured, this rally only applies to airfields and FARPS, but it will also work when (if) ED provides us with the ability to capture ships (and those will be great helicopter missions indeed - "Pirates! in the Caucasus", so to speak. Sid Meier would love it). The new module also laid bare a glaring oversight: no direct ability for modules to count. So now the xFlags module has that ability, and the capture mission also demonstrates xFlags' new ability.

image.png

Other than that, it took less than half a day for new ideas to come in for civ air (thanks, people!). CivAir can now restrict airfields to take-off or land only, to better regulate the direction of air traffic.

And to round out this update, CloneZone's ability to also work with embarking / disembarking troops has been added. Now, I don't trust troop embarkation further than I can throw it, and this DCS feature still feels a bit haphazard. But CloneZones now does support it. 


Other changes:
Documentation
    - baseCaptured main doc 
    - baseCaptured quick ref 
    - count bases blues demo doc 
    - one way air demo doc 
    
Demos
    - One-Way Air
    - count bases's blues
    
Modules
    - civAir 1.5.1 
    - cloneZones 1.4.4
    - baseCaptured 1.0.0
    - xFlags 1.3.0
    - LZ (experimental)

Cheers,
-ch

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, cfrag said:

That should be easily doable, but usually with disastrously results: the unit could be placed inside buildings, water, on trees, or within other units. Let me see what I can come up with and you can decide if it's useful. I think I'll simply adding a 'randomizedLoc' attribute could engage that feature.   

 

Thanks,

Never thought that placing units or objects on top of each other would be a thing. 😕

Link to comment
Share on other sites

On 4/28/2022 at 7:46 PM, cfrag said:

That should be easily doable, but usually with disastrously results: the unit could be placed inside buildings, water, on trees, or within other units. Let me see what I can come up with and you can decide if it's useful. I think I'll simply adding a 'randomizedLoc' attribute could engage that feature.   

 

Yes that could be quite useful, as long as designers are given the options. This is a feature of both MIST and MOOSE. We can choose between RND clonezones, randomizedLoc, or RND randomizedLoc for truly randomised gameplay!

Link to comment
Share on other sites

On 4/28/2022 at 1:18 PM, Sinclair_76 said:

One thing I would really like is the ability to spawn units, as per spawn zone, at a random position within that zone. 

OK, here's a preliminary implementation, please provide feedback.

The general idea is:

  • if the cloner's attribute (note: cloner, not template!) is 'rndLoc' and value is true, then the positions of the valrious units and objects are randomized
  • by how much, you ask? Well, by the size of the zone, of course 🙂 -- each unit is individually offset by a random vector (offset) that is at maximum as long as the destination clone zone. So if you make the zone big, all can be displaced by big values (but since it's true random, may be small), if it's small, the individual changes will also be small.

Below we have three zones:

image.png

  • small source,
  • larger clone zoen NO randomization
  • even larger cloner, WITH randomization 

Result:

  • the first two look identical,
  • the third (randomized) is all over the place

image.png

So, if you have really big zones (say 3000 meters radius), and two infantry inside, they can end up 6000 meters and more awway from each other.

Below is a demo miz as poc.

(ah, and the cargo manager integration is also in there, have been working on that as well)

Should all be ready for the next drop, planned for next week. If you can't wait, simply copy/paste the clone zone text to your own mission and it should work.

clone rnd test.miz

  • Thanks 1
Link to comment
Share on other sites

Version 0.9987 - 20220505

Feature Update: limited Airframes

Limited Airframes. Awkwardly Named (because it actually limits the number of player pilots), this module has been with DML since forever. It's one of the central 'balancing/gamefication' modules: 

  • it can be used to balance red and blue sides by setting a different limit on the number of pilots each side can lose
  • it is often used for more casual mission set up - where the players expect to be shot down, and continue the mission after respawning. In those scenarios, limiting the number of times a player can be shot down (especially when combined with automatic CSAR missions when players successfully eject) introduces new fun flavors.

The old code from way back then is now updated: DML flags, config zones, and pilot safe zones that integrate well with the other modules, all shiny and new.

image.png

Other changes include the usual suspects:

  • cloneZones has gained the ability to randomize the individual positions of the cloned objects/units, and any cloned cargo is now automatically handed of to CargoManager (if installed) 
  • pulseFlags has gained the ability to randomize the number of pulses
  • RND flags has received more DML polish (it's now RND!, and supports zone-local verbosity)

The changes in full:

Documentation 
    - Limited Airframes 
    - Limited Airframes Quick Reference 
    - Pilots at their Limit demo documentation 

Modules
    - cfxZones 2.7.7
    - pulseFlags 1.2.1
    - RNDFlags 1.3.0
    - limitedAirframes 1.4.0
    - CSARManager 2.1.1
    - cloneZones 1.4.5

Demos
    - Pilots at their Limit
 

Enjoy,

-ch

  • Like 1
Link to comment
Share on other sites

Version 0.999 - 20220512

Feature Update: Changer, pulse, "lohi", "hilo" (not a Disney reference)

One of the last releases before we go Full Monty, we now (finally) have the changer module that is a bit like the combination of duct tape and swiss army knife: a way to on-the-fly transmogrify a flag value, and provide a 'switched gate' to regulate the flow of information. The demo 'Gate and Switch' is there (fully documented) to illustrate that use.

image.png

And finally, after much deliberation, the 'pulse' method and Watchflag counterpart 'lohi' have made it into DML. In conjunction with switched gates and the opportunities they allow in mission design, adding this advanced control method outweighed it's obvious drawback: complexity.

image.png

Unlike other methods, a pulse isn't a one-time change of a flag value, but two: one to set, and - a few seconds later - a re-set. It's fully automatic, so there's no up-front cost to using it. Just be sure to understand how a pulsed flag works, or you may inadvertandly get two activations of your module instead of one (because, from DML's 'detect change' default behaviour, a pulse is *two* value changes of a flag rolled into one. So Caveat Emptor. 

image.png

Changes:

Documentation
    - changer documentation 
    - Pulse, lohi, hilo documentation 
    - Gate and Switch documentation 
    - Quick Reference: Changer Documentation 
    
Demos
    - Gate and Switch 
    
Modules
    - ALL MODULES
        - support for pulse bang! Method
        - support for 'lohi', 'hilo' Watchflag method
    - Changer 1.0.0 
    - cfxZones 2.7.8 
    - cloneZone 1.4.6
    - unitZone 1.2.2

Enjoy,
-ch

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Hi cfrag

I have downloaded and tried your Toolbox, it’s fantastic mission-building experience, especially for someone that has zero background knowledge for lua coding like me.

 

However I have currently encountered some difficulty in trying to build a urban conflict style mission on the Mariana map using your toolbox, and I wonder if it is possible for you to kindly provide some assistance. Thank you in advance!

 

a) SpawnZones

i. When I set ‘orders’ to ‘guard’, the AI will only search for enemy units once. And after the AI set their first and initial waypoint, they will not automatically adjust their waypoint or search for enemies again. Even there are new enemy units approaching afterwards, the AI will still stay on their initial waypoint without further action. It is then very easy for enemy units to travel around the guarding units and to attack the objective that the AI guarding units are supposed to guard.

 

ii. When I set ‘orders’ to ‘attackZone’, it seems that the AI will not identify whether the target zone is friendly or foe before initiating the attack. Is it possible to provide options for AI to IFF the target zone and decide whether or not to initiate the attack? Also is it possible to provide options for the attacking AI to actively search for enemies within a pre-defined area? This is particularly important for urban conflict set-up as the AI enemy units can easily hide behind buildings or obstacles beyond reach of attacking AI units. And the objective will become impossible for AI to capture or neutralise as there are still enemy units in the objective that cannot be destroyed.

 

iii. Is it possible to provide options to limit the maximum total number of attacking groups on the map? I am aware the existence of ‘maxSpawns’ function, but ‘maxSpawns’ can only limit the number of times the AI attacking groups spawn, but not the maximum total number of groups on the map. The function I would like to achieve is to set a ‘cap’ for the number of AI attacking groups on the map, once the ‘cap’ is reached, the system should stop spawning new groups until the existing groups on the map are reduced to a lower amount. This is relevant as I have some guys with relatively low-end rigs having performance issue playing my mission, and I think this ‘cap’ function can reduce the overall pressure on hardware for the players.

 

b) cfxOwnedZones

It will also be very nice to have a ‘cap’ function for this as for ‘SpawnZones’, as described above in a) iii.

 

c) cfxCommandernull

i. When I set ‘cfxCommander.forceOffRoad’ or ‘cfxCommander.noRoadsAtAll’ value to ‘false’, the mission is very prone to CTD, especially for urban environment like towns on Mariana map. But if I don’t set the value to ‘false’, the AI will stuck themselves among woods or buildings because they can only travel in a straight line.image.png

ii. I hope ‘cfxCommander.forceOffRoad’ and ‘cfxCommander.noRoadsAtAll’ can be designated to individual unit, as sometimes I wish part of the units to travel only on roads and part of the units to travel off-road. For the time being I can only try to let the AI engage each other on the roads as they are so easy to stuck among buildings in an urban environment.

 

iii. Is it possible to provide options to designate targets for ‘attackOwnedZone’ and ‘cfxOwnedZones’? For example I have five zones, A, B, C, D, E, and F. I wish the units in zone A to only attack zone B and C, and units in zone D only attack units in zone E and F. The ‘untargetable’ option I have currently cannot fulfil the function of target zone designation, only to decide if the zone is to be attacked by AI or not, and having no limit about which AI group is going to attack that zone. This can lead to the situation that AI in every other zones are trying to despatch a group to attack that particular frontline zone regardless of the time and distance, between zones, causing unnecessary pressure on hardware.

 

I am aware that it can be very difficult for the current AI in DCS World to perform urban combat scenarios, but I have a potential walk-around idea for OwnedZones. Is it possible to calculate and compare the number of units presenting in a zone, so that when one faction has substantially more units than the other, the zone can be captured and the remaining enemy units automatically de-spawn? This maybe a solution to the issue mentioned in a) ii.

 

Thank you for your time and attention in reading this. I am looking forward to your input and the release of Toolbox version 1.0.


Edited by MsKatze
Link to comment
Share on other sites

@MsKatze, thank you so much for your feedback!

21 hours ago, MsKatze said:

a) SpawnZones

i. When I set ‘orders’ to ‘guard’, the AI will only search for enemy units once

DCS is built like a 'Lego' set, with modules building their abilities on others. SpawnZones internally hands off all units it spawns to GroundTroops, where the real trouble lies. Now, this doesn't help, 🙂 but it hopefully explains my answer and how I'll try to tackle the issues in the coming weeks. Unfortunately, the GroundTroops module belongs to the 'advanced topics' set of modules and needs a basic user interface (which it has, of sorts - I'll explain below)

With regards to GroundTroops, that module currently possesses only rudimentary AI supplementary capabilities. It doesn't so much build on DCS's native AI, it merely uses it. And truth be told, DCS's troop AI is currently marginal at best. On my roadmap for 'beyond 1.0' is an overhaul for GroundTroops to add some AI augmentation. The 'guard' and 'attack' loops are currently simplistic; for example in 'guard' mode, GT regular checks to see if the group is unengaged, and if they are, looks for an enemy group in range. If it finds one, the group is ordered to move towards that group and waits until that enemy group is destroyed. GT relies on DCS to handle the task of approaching the enemy, re-loading and attacking; The results can be abysmal. The AI built for lasing shows that GT can be used effectively, but it's also a drain on CPU and works against DCS's native 'AI'. I'll have to revisit the entire 'orders' code soon, and I'm grateful for your feedback and suggestions, as it matches my own experiences and frustration. 

21 hours ago, MsKatze said:

Is it possible to provide options to limit the maximum total number of attacking groups on the map?

Now that's a great idea!  I'll see if I can design a global 'governor' module that can be configured individually for red and blue. Spawners and cloners can automatically check before they spawn if their side is over that limit.  

As a stopgap, use GroundTroops' "scheduledUpdates' attribute in a config zone and set "maxManagedTroops" to sensible cap, say 60 groups. GT then no longer manages (i.e. issue orders) to more groups than the cap, although more can exist. Whenever a managed group is destroyed, GT then fills it's management queue back until the cap is reached. 

 

21 hours ago, MsKatze said:

When I set ‘cfxCommander.forceOffRoad’ or ‘cfxCommander.noRoadsAtAll’ value to ‘false’, the mission is very prone to CTD, especially for urban environment like towns on Mariana map

I'll have to check, but I suspect a CTD is triggered by DCS running out of memory on a pathing task inside DCS's AI itself, and is often the result of a combination of long distances, many roads, difficult terrain, and (mostly) lots of groups. Lua script can't cause a CTD, but calling into DCS with Lua can (simply set a flag to a sting, and see how quickly you can CTD 🙂 ), and my own experience with pathing/ordering is that yes, giving move orders to a a group can crash DCS under the right (or better: wrong) circumstances. It's one of the reasons that GroundTroops has the optional cap on managed troops and scheduledUpdate options. It will merely delay the onset of slow-down/crash, but it may help. As you suggest, putting a definite cap on spawned units is probably the only surefire way to avoid CTD.

 

(image of Lua break on Line 262 in GroundTroops)
Yes. (blush). Fixed. If you are interested in the fix right now, please replace line 262 in version 1.7.5 of Ground troops with this one:

if not group:isExist() then

 

21 hours ago, MsKatze said:

Is it possible to provide options to designate targets for ‘attackOwnedZone’ and ‘cfxOwnedZones’?

I'm working on this, and the existing 'attackZone' attribute is a first attempt at this. However, I'm not at all impressed with my work here, and I'm looking for a better, more intuitive and flexible way to 'attract' groups to a zone. Since the entire GroundTroops module is slated for overhaul, this will have to wait, and I'm always open to suggestions ideas.

21 hours ago, MsKatze said:

I hope ‘cfxCommander.forceOffRoad’ and ‘cfxCommander.noRoadsAtAll’ can be designated to individual unit

Unfortunately, that's a DCS limitation. Orders can only be given to entire groups, not single units.

21 hours ago, MsKatze said:

Is it possible to calculate and compare the number of units presenting in a zone, so that when one faction has substantially more units than the other, the zone can be captured and the remaining enemy units automatically de-spawn?

Yes, and it is already implemented in GroundTroop's "Tie Breaker" functionality - but that only works with groups managed by GT. I think you are on to a great idea indeed, that I may need to flesh out later - a designated "auto-resolve combat zone" where one side wins if they achieve a significant advantage. Is that what you suggest?

 

Cheers,

-ch

 


Edited by cfrag
  • Thanks 1
Link to comment
Share on other sites

Version 0.9991 - 20220519

Feature Update: unGrief (PVE rules, griefer deterrent)

The original unGrief module was written in February as a response to a request from @DTS_Maton and was then upgraded to DML a week later. I've now had time to complete integration into DML and add some more polish:

  • PvE mode: when active, it punishes PVP activity
  • Wrathful mode: when active, your second transgression is your last.

unGrief now is fully documented, and comes with its own demo ("Good Grief") that is also fully documented, so if you want to add some grief-repellent or create a simple PVE-only server, unGrief is just a few clicks away. 

image.png

Change Details
- Documentation
    - unGrief module 
    - Good Grief demo 
    
- Demos
    - Good Grief 
    
- Modules
    - unGrief 1.1.0
    - GroundTroops 1.7.6

Enjoy,
-ch

Link to comment
Share on other sites

Version 0.9992 - 20220526

Feature Update: PvP Zones in PvE Missions (multiplayer only)

Building on the PvE mode added to unGrief, we now can have dedicated PVP zones on a PVE map. PVP rules can be strict or relaxed (the difference being who must be in the PvP zone at the point of the kill), and I've also added the requested ability to warn players when they enter and leave a PVP zone. As always, there's a new demo to analyse the new features in action.

Other changes are mainly bug fixes and polish for the upcoming 1.0 release.

image.png


Change Details
- Documentation
    - unGrief PvP update 
    - The Danger Zone demo documentation 
    
- Demos
    - The Danger Zone 
    
Modules 
    - cloneZone 1.4.7 
    - csarManager 2.1.3 
    - dcsCommon 2.6.3
    - groupTrackers 1.1.2
    

Enjoy,
-ch

Link to comment
Share on other sites

Version 0.9993 - 20220602

Maintenance Update

A busy week, and I'm happy to see that DML is approaching stable conditions. A new demo for the extended functionality of spawnZones, and the updates to the docs. Intrepid explorers will find a new experimental module that may or may not make the 1.0 cut.

Change Details

- Documentation
    - Spawner update 
    - Spawner Demo 
    - Quick Ref updates 

- Demos
    - Moving Spawners II
    
- Modules
    - spawnZones 1.6.0 (trackwith: support)
    

Enjoy,

-ch

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

I have another request.

In Recon Mode, the current messaging system is very simple. If a unit is detected I would still have to look up the coordinates etc. Is it possible to let the lua generate a message in SALUTE or SALT  format (https://store.forwardobserver.com/building-blocks-of-intelligence-salute-and-salt-reporting/)?

I know you're probably busy with the 1.0 release so I thought you could use some extra requests. 😄


Edited by Sinclair_76
Link to comment
Share on other sites

4 hours ago, Sinclair_76 said:

the current messaging system is very simple

Ah, well, that’s something I could look into - maybe not fully fledged SALUTE, but perhaps a SALT variant. May have to wait until after 1.0, though.


Edited by cfrag
  • Thanks 1
Link to comment
Share on other sites

Version 0.9995 - 202206029

Featured Updates: Radio Menu

So maybe - just maybe - one of the most helpful modules arrives dead last. I'm in the process of finishing off my laundry list of useful modules for the dot-oh send-off. Belatedly I now realize that "radio menu" should have been made available much earlier: it resolves so many problems for budding mission builders, is easy to use, and gives access to mission functions that are difficult to do outside of Lua.

image.png

Well, it's here now. For what it's worth, as for coming in next to last, it profits from the full spectrum of DML abilities from the get-go.
 
'RadioMenu' can add DML-style "F10 Other..." communication menus (with up to four items/commands per menu) with integrated flag handling (multiple activations possible of course), and built-in cooldown handling to boot. So, adding Radio Menus (as opposed to simply commands) has never been easier. 

And yeah, you read that right: built-in cool-down handling. How cool is that?

image.png

The final late-joiner is 'delicates', a module that makes units and static objects 'delicate' to the touch: as soon as they are damaged, they explode. Use them for harrowing, nail-biting escort missions, or to create spectacular effects when raiding a base. 

image.png

Finally, another QoL update has arrived: messenger gained the ability to interpret the value flag as time and format it the same way a the cooldown message for menus 

  
All Changes in detail:


- Documentation 
    - RadioMenu module doc 
    - Delicates module doc 
    - Reinforcements A La Carte demo doc  
    - Delicate Subjects demo doc 
    - Endless Looping Spawns demo doc  
    - messenger HMS format update 
    
- Demos 
    - endless looping spawns (new)
    - delicate subjects (new)
    - Reinforcements A La Carte (new) 
    
- Modules 
    - cfxZones 2.7.9 
    - delicates 1.0.0 
    - radiomenu 1.0.0
    - dcsCommon 2.6.4
    - messenger 1.3.1
    - wiper 1.1.0
    

Enjoy,

-ch

  • Thanks 1
Link to comment
Share on other sites

On 6/8/2022 at 5:20 PM, Sinclair_76 said:

Is it possible to let the lua generate a message in SALUTE or SALT  format

I've completed some preliminary testing. It's not pretty as DCS does not allow scripts access the current task in the controller, but I've put some simple SALT reporting into recon mode, and added a LOT of QoL to bring this module up to DML standard. It may even make it into 1.0

This how the report looks in the message log. Coords can be in LatLon or MGRS.

image.png

And this is how it looks on the map marker (obviously it does not require coordinates).

image.png


Edited by cfrag
  • Thanks 1
Link to comment
Share on other sites

Version 1.0 - 20220616

 

image.png

'nuff said. 

Changes/Updates:

Demos
    - DML Intro
    - Artillery Recon (new, dev)
    - Missile evasion
    - Recon Mode Reloaded (new)

Modules
    - reconMode 2.0.0
    - messenger: 1.3.2
    - dcsCommon: 2.6.5  
    - artillery zones 2.2.1
    - Guardian Angel 3.0.0
    - radio Menus 1.0.1

 


Edited by cfrag
  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...