DML - Mission Creation Toolbox [no Lua required]

[Hellfire]

Your an idiot? I'm an idiot. I did not know that worked that way. Ok so now It starts off neutral, blue aggressors come down and instantly drive the French(neutral) out and turn the base blue including troops and service vehicles. Red aggressors come through but have to make a complete loop through the base so they can destroy all the blue units and then farp is turned red and all the service vehicles and red troops are spawned on the farp. COOL! In order to do this all I had to do was put down a farp, 2 aggressor groups with waypoints and a trigger zone and plug in some options. Now to duplicate all that it's just copy and paste 4 different objects to another location and boom done after adjusting waypoints. Awesome. On to baseCaptured.

 

 

[Hellfire]

This error is generated when running "demo - base captured.miz"

2022-11-07 14:51:13.738 ERROR   SCRIPTING: Mission script error: [string "baseCaptured={}..."]:83: Parameter #2 (delay) missed
stack traceback:
    [C]: ?
    [C]: in function 'outText'
    [string "baseCaptured={}..."]:83: in function 'triggerZone'
    [string "baseCaptured={}..."]:110: in function 'onEvent'
    [string "Scripts/World/EventHandlers.lua"]:13: in function <[string "Scripts/World/EventHandlers.lua"]:11>

 

[cfrag]

That's a strange one. Can you make sure that you have included baseCaptured version 1.0.1 (see attached) in your mission? Please replace the entire script, just to make sure.

 

 

baseCaptured.lua

[Hellfire]

This is the demo mission that comes with DML and its basecaptured.version = "1.0.0". I updated the mission with the latest basecaptured.lua and that fixed it.

I can see where this could be a pain in the butt trying to keep the demo missions updated with the latest *.lua code changes. The date on the mission file is 10/27 and basecaptured.lua is 11/5. Going forward I will update the demo's as I use them.

 

[Hellfire]

Don't want to be the one thats a pain in the butt but I'm pretty sure the 4.4.25 baseCaptured in the documentation is incorrect. In my estimation the problems begin at 4.4.25.3 Module Configuration and “baseCapturedConfig”. Naming a zone exactly that would mean there could be only one and I see that is a common practice to use *.Config to modify a module but the options (4.4.25.4 ME Attributes) that come next are for multiple basecaptured modules. I hope I'm making myself clear here but more than that I hope I'm not completely wrong. If that is the case, can you straighten me out?

[cfrag]

22 minutes ago, Hellfire said:

This is the demo mission that comes with DML and its basecaptured.version

Thanks! Updating right now.

 

[cfrag]

42 minutes ago, Hellfire said:

Naming a zone exactly that would mean there could be only one

DML uses specially (uniquely) named zones to configure the entire module, to set up that particular module's behavior. That setting in a modules config zone is applied to all instances of  that module, and therefore the Highlander Principle applies: "there can only be one". baseCaptured only has a single config setting: 'verbose', which is then applies to all baseCaptured! instances, so this module's config zone has little practical use. This may change in the future...?

42 minutes ago, Hellfire said:

the options (4.4.25.4 ME Attributes) that come next are for multiple basecaptured modules

Yes. Any zone that has a baseCaptured! attribute attaches an instance of the baseCaptured module, and the attributes listed in that table can be added to individual instances.

These are some of the fundamental ways of DML:

• A single, uniquely-named config zone configures how aspects of that entire module behave - this would be a 'baseCaptured.cfg' file if we did old-school configurations, but using a specially named trigger zone is so much more elegant and better fits with missions because you can edit them from within ME. I also - for reasons I forgot - like to color them yellow and be able to tell config zones apart from functional zones
• A module-specific keyword (here "baseCaptured!") marks a zone as a "functional" zone for that module - the zone is to be watched and managed by that module, it's regarded as a functional 'instance' of that module. You can have multiple functional zones in your mission.

You'll see that each module's description is structured similarly in the doc: module (general) configuration, followed by functional configuration of individual instances. If you haven't had to check them out already, sections 4.2.1 and 4.2.9 could shed a little more light on this.

Edited November 7, 2022 by cfrag

[Hellfire]

Roger that, 4.2 is the core/power of DML in my estimation. My problem right now is I'm like a kid in a candy store trying to taste all the different flavors/modules. 

[Hellfire]

Only 2 zones setup in this mission and the problem child is the BMP-3-Spawn. Nothing is spawning, what am I missing? Beyond that I'm really curious to see what happens with the orders that have been given, are those correct also?

To save you from running the mission all that happening is at start of mission a blue unit seizes the neutral base FARPLondon, that should trigger BMP-3-Spawn and that spawned unit should attack / move towards FARPLondon. ???? 

You can't see a portion of the FARPLondon properties but that is just rPhiHRes and FARP.

DML-TEST.miz

Edited November 7, 2022 by Hellfire

[Hellfire]

Just noticed that when blue captures FARPLondon this is all I get.

 I would expect +++bCap: banging blueCaptured! FARPLondonCapturedBlue or something to be listed in there also.

 

Edited November 7, 2022 by Hellfire

[Hellfire]

Plot thickens!

I setup a clonezone for blue to clone a ME group of blue when red takes the farp (FARPLondonCapturedRed). Like the spawn zones blue version of this problem it would not spawn when red captured the zone but it would spawn/clone for FARPLondonCaptured which is baseCaptured! flag.

[cfrag]

7 hours ago, Hellfire said:

Nothing is spawning, what am I missing?

At first blush I'd recommend also including the cfxSpawnZones module when loading DML.

Happens to me as well, so just grin.

The spawner then immediately spawns the BMP, and will continue to do so every 60 seconds (that is default spawn behavior), so I also added an attribute paused = true to prevent overwhelming the blue guys before they can cap the farp.

The flag FARPLondonCapturedBlue is banged, baseCap's verbosity is merely lacking. I've updated baseCaptured for more verbosity (see below), but that's purely cosmetic.

If you want an easier time watching flags, add the debugger and find out just how comfortable debugging can be without all that pesky verbose stuff.

baseCaptured.lua DML-TEST3cf.miz

[Hellfire]

The Cloner is not cloning when red captures base. Best I can tell is baseCaptured is broken and redCaptured! is not banging FARPLondonCapturedRed which is what CLONE-Blue-1 "clone?" watches.  onStart, BlueCaptured! and baseCaptured! work to fire CLONE-Blue-1. I can use debugger (thanks for that) to -set  FARPLondonCapturedRed 1 and that fires cloner.

 

DML-TEST.miz

Edited November 9, 2022 by Hellfire

[Hellfire]

I have seen this happen off and on during testing. It will cap the zone before all the units are dead. The French are back.  Probably a DCS freak show. ???      sorry pics out of order in this post  

Other thing I wanted to point out in this pic is the "banging redCap! with *none", different from the "banging blueCap with  FARPLondonCapturedBlue".

How about those debugging skills?  Change your documentation at the point where you show how to doscript the modules, just go ahead and say you might as well add the debugger. Loving this thing but be sure to start it out simple, just do mark on F10 map enter in -? and the rest gets obvious.

 

 

Edited November 9, 2022 by Hellfire

[cfrag]

4 hours ago, Hellfire said:

Best I can tell is baseCaptured is broken and redCaptured! is not banging FARPLondonCapturedRed which is what CLONE-Blue-1 "clone?" watches

That's a fact. I found a typo in the code that looks for the 'redCaptured!' synonym (that's why my tests with red! worked, but yours with redCaptured! did not). Thanks for being persistent!  -- It now (finally!) works (see enclosed updated baseCaptured and mission)

silly null

DML-TEST4cf.miz baseCaptured.lua

Edited November 9, 2022 by cfrag

[cfrag]

3 hours ago, Hellfire said:

It will cap the zone before all the units are dead.

That's probably a symptom of one of the more annoying 'features' that was introduced with a recent DCS version: when units are dead, but "cooking off" (burning), DCS internally regards them as dead, switches them to static objects, but visually keeps them looking alive. It *also* messes up the Unit_dead event, but luckily DML has been hardened against that (mostly) and can deal with that. So the capture event is logically correct, while visually it looks as if the other units are still alive. Very disconcerting. In the image you show the situation looks different, and yet DCS generated the cap event, which is indeed strange.

Edited November 9, 2022 by cfrag

[Hellfire]

Had some comments and questions on this image. What's happened here is the BMP3, a spawner with orders to move to this trigger, but it seems to have stopped firing and has killed only 1 of the defense units and 4 of the service units. I think it's gun can't quite traverse to whatever unit it has targeted and is stuck here. So that's the image. Now I have played this scenario out quite a few times and the outcome is generally pretty (slightly) different each time, so much that it is notable. My question to Cfrag is does the spawners orders to move include any randomness in the order or the destination? There are some slight variations on the end point. The route is pretty much the same each time although when it fires rockets on blue aggressor it will miss on occasion and that alone can obviously change the outcome. I wanted to point this out to any would-be mission makers that no matter how perfect your plan DCS is going to change things up on you so be ready. Here the outcome has failed but there have been other times were BMP3 actually maneuvers on the defense units, which is quite cool to witness when happens, but it was rare.

This is the point where I segway to the question or problem that should be quite clear in this test mission, the Capture Circle Jerk (CCJ) that is performed by the static aggressors. CFrag do you have any tricks up your sleeve for this? I have remedied the problem before by spawning defense units only in randomized trigger zones and the static aggressor's path was set to travel through all the possible defender zones but there is the problem of defilade. I read somewhere in your docs about the Guard orders and how a unit will respond to and I'm assuming maneuver on, and here is an important distinction, detected units or units that are within the defender's trigger zone, which is it? My wishful line of thinking is how cool it would be if the afore mentioned BMP3 could maneuver on everything in a zone whether it actually detected it or not so in the case of the BMP3 it could be shifted into a guard mode and then attack the remaining units in a contended zone after its initial arrival. Maybe DML can't handle this directly at this time, but I bet its capable of handling the situation a little more eloquently than CCJ. I suppose another angle could be the zone defense units, any way to shift them to guard orders after they are placed? 

[cfrag]

4 minutes ago, Hellfire said:

if the afore mentioned BMP3 could maneuver on everything in a zone whether it actually detected it

DML can only do so much with orders, it still relies on what DCS terms AI and then occasionally tries to update the orders. Sadly, DCS ground AI is somewhat lackluster. It gets worse when units have expended their ammo - because then they only sit around doing nothing and stare at each other. There's really very little DML can do to improve the situation, and I have therefore resigned myself to only start work on DML's Order mechanics when that part of the game has improved. 

[Hellfire]

Persistence failing on start. Nothing special about my saved games directory so I went with the defaults in persistenceConfig.

2022-11-10 02:17:46.551 ERROR   SCRIPTING: Mission script error: [string "persistence = {}..."]:442: attempt to index global 'lfs' (a nil value)
stack traceback:
    [C]: ?
    [string "persistence = {}..."]:442: in function 'readConfigZone'
    [string "persistence = {}..."]:512: in function 'start'
    [string "persistence = {}..."]:616: in main chunk

 

Also the mapMarker Test Mission isnt doing anything. That is, I'm assuming it should print out Test Mission on the map during the mission. ????

And to elevate nuisances one more level, spellcheck please.

 

DML-TEST.miz

[cfrag]

3 hours ago, Hellfire said:

Persistence failing on start.

The good new is that your DCS is behaving as it should. The 'lfs' library is one of the three sensitive libraries in DCS that are walled off in normal installations for security reasons: they allow Lua scripts to write to your disk, and no script should be able to do that without your explicit, active participation. In your installation, 'lfs' is still disabled. If you want to use persistence (and that goes for anyone who wishes to host a mission from you that includes persistence), you must enable this by 'de-sanitizing' DCS. It's not difficult, and it's described in section 4.8 "Persistence" - with some dire words about security and warnings that the world will come to an end if you screw up  

 

3 hours ago, Hellfire said:

the mapMarker Test Mission isnt doing anything

I'll have a look. Map Marker harkens back to a time when we could not use ME's "draw" ability, so it's almost pointless today. I'll review it for the next update cycle, thanks!

 

3 hours ago, Hellfire said:

spellcheck please.

I'm not a wizard. Oh, spelling-check? I'm too cool for that  (thanks, I'm on it.)

[cfrag]

Version: 1.1.9 - 20221110

Featured Update: Massive enhancements to messenger, new counter module, new "+"/"-" output method for all

This update brings another massive update to the messenger module: wildcards that can be used to give *relative* information to the message receiver, like bearing to another unit or zone, closing velocity, aspect or a target etc. This upgrade is a result of a request from @Hunter Joker, so thank you for the inspiration!

While at it, I also added a new ability to provide multiple 'canned' text messages that I call "responses", which can then be accessed dynamically during the mission (meaning: the selection which of the pre-supplied responses is taken can depend on a flag or other unit)

Messenger's abilities have escalated to such a degree, that the simple demo mission that I wrote became so much fun that it merits sharing with everyone (much like the "Tango" missions that grew out of cloner's new ability to randomly distribute units on street patterns). So, while DML receives a version with the Su-25T to fly, just to show that it takes only a minute to replace the relevant planes, I've put up the MB-339 version (which incidentally came out a few days before and gave me some hours of fun learning a new type) for everyone.

Writing the formation trainer mission also gave me the opportunity to include the newest member to DML's family of modules, the counter module. It's very modest, simple to understand, and will find a home in many missions I'm sure.

GuardianAngel new has the ability to play a sound file every time that a missile is launched or when a missile is removed by the Angels - as requested by @Sinclair_76. See the updated demo.

Another big change I added under the hood: all modules now have access to expanded output methods "+" and "-" that will add or subtract a flag or number from the targeted flag - exceedingly useful, and requrested a number of times. 

Other changes include fixes to bugs (three of them were identified by @Hellfire alone - thank you so much!) and some ancillary updates to usability and QoL.
 

Changes in Detail

Documentation
    Manual
        - New counter module 
        - Messenger Update 
        - new "+" and "-" output methods 
        - "Formation Trainer" demo (messenger, counter)
    
    Quick Ref 
        - Counter module (new)

Demos    
    - Formation Trainer (new) 
    - Guardian Angels Reloaded - updated with audio feedback

Modules
    - baseCaptured 1.0.2
        - fixed redCaptured! typos

    - cfxMon 1.0.1
        - fixed Static Object event bug 
        
    - SpawnZones 1.7.1
        - improved verbosity 
        - Fix for 'Scattered' formation 
        
    - cfxZones 2.9.1
        - New "+"/"-" output methods 
        - evalRemainder() (new)
        
    - changer 1.0.4
        - increased verbosity 
        
    - counter 1.0.0
        - initial version 
        
    - dcsCommon - 2.7.9
        - getGeneralDirection() (new)
        - getNauticalDirection() (new) 
        - hardened getUnitSpeed()
        - bool2Num() (new)
        - aspectByDirection() (new) 
        - fixed minDist bug for 'scattered'
        - randomPointInCircle() hardened 
    
    - GuardianAngel 3.0.4
        - intervention sound 
        - launch sound 
        
    - messenger 2.1.0
        - massive upgrades to the wildcard abilities
    
    - unitZone 1.2.4
        - added verbosity 
 

Enjoy,

-ch

 

[Hellfire]

Sorry, another unforced error. I just started using this laptop for DCS mission stuff and since the other systems are already sanitized, I didn't snap to it here. I stared at 'lfs' in the error as if I recognized that from somewhere. Should have run it down and it would have been obvious. Argh.

Ditch the marker. Which by the way, initially I struggled with using the markers on the map for the debugger. Could not place a marker until I realized that you have to be somebody in DCS, as in pilot or commander. Hope that helps someone.

Offhand question. Do you use Beta or Stable to test in?

 

 

[cfrag]

15 minutes ago, Hellfire said:

Do you use Beta or Stable to test in?

Beta. Everything else is for sissies  

 

[Hellfire]

Moving on to owned zones. 

Can you not set the properties for attackingTime defendingTime etc. differently for each zone? I was thinking that the Config zone was for setting the defaults for whatever properties globally, and then you could set the property differently for each zone if you included it in the owned zone itself. No?

Another observation. See how the first cloned zone falls. You will notice that it appears that it's not going to fall because the tank can't see the extra static targets I put in the zone, but since the zone is never capped it attempts spawn a defense unit which is quickly dispatched by the tank and then even with surviving units, the zone is immediately capped. THAT SOLVES A HUGE PROBLEM. Something similar happens over on the FARP during the second blue capture sequence. I'm not expecting any kind of resolution here, just pointing it out.

Hoping that the properties issue is bugged and not planned. Owned zone will be an awesome piece of kit. Battle zones in a box.

Persistence is bugging for me on this mission on it's first write. Curious if you get the same, if so just remove from mission.

Almost forgot. There is a way to disable the GUI error popup screen so that it doesn't disrupt the running of the sim on errors, it just logs them and moves on instead of freezing the sim. Do you know how to set that? I've got it somewhere but it's going to take a deep dive to locate it.

DML-TEST.miz

[Hellfire]

Hmm, after watching it do the cap on the northern owned zone 3 times, I ran it again and it didn't do it. It did do it over on the farp. Whatever, you could go crazy working with the randomness baked into DCS.