DML - Mission Creation Toolbox [no Lua required]

[DD_Friar]

50 minutes ago, cfrag said:

Let's fix the mission instead

Sir, that was my intention of posting the scenario in a specific mission that demonstrates the logic (and where I am going wrong) so that I can correct it.

With respect to your Lordship, I will have a look at how I can use the debugger in the future.

[cfrag]

3 minutes ago, DD_Friar said:

I will have a look at how I can use the debugger in the future.

I'm building a new tool into the debugger that helps identifying misspelled flag names, should be a great help. I'm running it on "Expansion" as a test case and it already discovered two 'hanging' flags (i.e. one unmatched pair, where I misspelled a flag name on one side)

 

Edited November 5, 2024 by cfrag

[DD_Friar]

1 hour ago, cfrag said:

I'd like to get you into the habit of using TheDebugger

Having just now looked at what it can do, I see now instead of me having to place units in the ME that go and do things to trigger the flags I need, I just need to use the debugger to manually change them.

For example, at the moment in my test I have an airfield zone and manually drive a vehicle into the zone to capture it / trigger the "ownerairfield" flag value to change.

Now all I have to do is to add a mark point and give it "-set ownerairfield 2" 

I now get the massive potential and assistance this can give. Shame on me for not exploring this sooner...

null

Edited November 5, 2024 by DD_Friar

[cfrag]

7 minutes ago, DD_Friar said:

Having just now looked at what it can do, I see now instead of me having to place units in the ME that go and do things to trigger the flags I need, I just need to use the debugger to manually change them.

Shhhhhhhh...! It's DML's best kept secret  

When this becomes common knowledge, my renown godlike debugging skills become all too common...

 

Edited November 5, 2024 by cfrag

[DD_Friar]

On 11/2/2024 at 9:51 AM, DD_Friar said:

Modules: Convoy and Clone Zone (and possibly Airfield)

Issue: Difference in spawn logic at mission start

Salute Sir,

I think I may have found a difference in the way the two (or three?) modules behave at the start of a mission. I believe the new logic you added for the convoy module may differ slightly from that of the approach the Clone Zone (and airfield?) uses.

Clone Zone example - I have an "ownedZone" set to "red" within the parameters. I then have a nearby "cloner" that uses the "ownedBy#" flag and a "cloneTriggerMethod" set to =1 for the spawn to take place. If the town is captured by blue I do not want them spawning next time the mission starts (I will be running this mission with persistence). When the mission starts the units I require get spawned in the town (I am using the "inBuiltup" parameter set to 15 and it is working really nicely by-the-way). All good.

Convoy example - I have an airfield which is set to red within the mission editor, it also has cloned red units which are activated onto the airfield at mission start (onStart=true). I then have a nearby convoy that uses the "ownedBy#" flag as well and the new "convoyTriggerMethod" set to =1. At mission start the convoy is not triggered. I am assuming that it is not detecting the value of the flag already set and is only looking for change?

If I change the airfield to neutral in the editor, the occupying cloned red forces change the ownership to red and the convoy starts as expected (with helicopter escort which is another nice feature).

If I am correct this shows a slight difference in the "at mission start" logic. If this is what it has to be, no problem, it still works this way but I thought I would highlight this in case it was not what you intended and/or point it out for other builders.

As always, many many thanks for all the hard work and regular updates and new features you add to this excellent toolbox.

Cheers

Friar  

@cfrag - Please may I ask, did you see the above post I made a few posts ago? It was in the middle of a couple of my posts where I answered myself and may have got lost in the mire.

[cfrag]

2 minutes ago, DD_Friar said:

did you see the above post I made a few posts ago?

I did indeed - thank you. I did not see a question to answer. Always remember that I'm not a native English speaker, so a direct approach using small words helps silly me to better understand. And according to the most important person in my life, I "don't understand obvious hints to do things", I'm just a silly male.  

Edited November 5, 2024 by cfrag

[DD_Friar]

ok, sorry about that. Let me put it a different way then.

Can you check please the way the convoy module looks for the state of flags when the mission starts.

I believe that it does not check their status and only reacts when they are banged AFTER the mission has started.

My example was the owner of the airfield was set in the ME so was red when the mission started. Convoy seems to react only when a flag gets changed due to it being banged by another module.

[cfrag]

18 minutes ago, DD_Friar said:

I believe that it does not check their status and only reacts when they are banged AFTER the mission has started.

That is true. I can't check before the mission starts. If you want a convoy to start at mission start, I think that the best way to do that is use a raiseFlag that runs 0.5 sec after mission start.

20 minutes ago, DD_Friar said:

Convoy seems to react only when a flag gets changed

Indeed. That is default module behavior. It seems you want to exploit a particular implicit setup that may result in a flag change at mission start-up, but does not. I strongly recommend that you always make these things explicit - for example by using raiseFlag.

[DD_Friar]

@cfrag Please find attached a small test mission where I am trying to solve my logic issue.

It now has the debugger and I have been using it to change values of flags.

My convoy only starts when keyBuildingDestroyed = 1 which is incorrect.

If you have a minute are you able to take a look and suggest what I am doing wrong please?

EDIT: After posting this mission I came up with an idea which I think solves the issue.

At mission start I had added RaiseFlag to set the value of keyBuildingDestroyed to 1 (1 now equals a live building). I have added a method change parameter to "off" on the "objectdestructor" module which will change the 1 to a 0 when the building is destroyed.

With this value the gate is then closed that passes the signal to the goConvoy. 

ChangerLogic.miz

Edited November 5, 2024 by DD_Friar

[cfrag]

2 hours ago, DD_Friar said:

If you have a minute are you able to take a look and suggest what I am doing wrong please?

This is a truly odd one. There is a trailing blank at the airfield's "ownedBy#" attribute. It seems that this is something that some attributes don't like, and therefore do not register as an output. If you remove the trailing blank, it works. I'll try and see if I can guard against this in the foundation itself so that this silly oversight will no longer matter.

 

[DD_Friar]

11 hours ago, cfrag said:

There is a trailing blank at the airfield's "ownedBy#" attribute

Many thanks for taking the time to have a look. I fully suspect that was caused by me doing copy paste from the quick reference guide (as I often do). Usually I am aware of it and delete it out.

11 hours ago, cfrag said:

If you remove the trailing blank, it works

Ok I will take another look with the edits I added after posting (keyBuildingDestroyed set to 1 at mission start and the objectDestroyed parameter set to off to change from 1 to 0 when banged) to see if my original logic would have been ok.

 

[DD_Friar]

@cfrag

I have checked my logic and adding the raiseflag at the start to set the value of the keyDestroyedBuilding seems the only way to get this working.

As I plan to use Persistence on this mission, should I produce 2 versions, the first version that has the raiseflag function at the start and another that does not for subsequent runs of the mission where flag values are loaded as I do not want to re-set the destroyed building values if they were hit in a previous session?

[cfrag]

6 hours ago, DD_Friar said:

I fully suspect that was caused by me doing copy paste from the quick reference guide

Ah, perhaps. But even if so, that's no excuse for DML to work that way. I thought I added code to remove leading and training whitespace, and I hope to have it in place for toworrow's (planned) update 

1 hour ago, DD_Friar said:

should I produce 2 versions, the first version that has the raiseflag function at the start and another that does not for subsequent runs of the mission where flag values are loaded as I do not want to re-set the destroyed building values if they were hit in a previous session?

Good thinking - but as of version 3 of raise flag, persistence is supported for raiseFlag and it knows if and when to fire on reload  - so you only need one version.

 

 

[Dallatorre]

Hello! May i ask a little help? I am a bit rusty with coding,
I was looking to code into a mission the feature where a well-defined AI Unit will callout Fox-2 / Fox-1 when that unit fires (not using the default DCS voices). 

Messenger is pretty self explanatory to use, but still requires a flag trigger from the ME, so i don't actually need all that.

I thought about butchering Bomb Range and skin that script down to the bare minimum, but I'm finding myself a bit lost, may i get a hand into scrapping everything from that script? surely i don't need the timers nor the comms menu, and for now I understood that the magic happens at 

if event.id == 1 then -- shot event, from player

and put a 

trigger.action.outSoundForCoalition(0, fileName.ogg)

somewhere...

From there do I just remove all other events and clean up all the unused functions from there? am i on the right track?

I also don't understand something around event.id: according to the code in dcsCommon "1" is "shot", but what just from players? what should change for it to be triggered by another unit? edit: found out you were using a sneaky return juts 2 lines above 

Thanks man!

Edited November 6, 2024 by Dallatorre

[cfrag]

9 hours ago, Dallatorre said:

From there do I just remove all other events and clean up all the unused functions from there? am i on the right track?

Yes and no. DML is not designed to be code-modified. It's not intended for code heads at all, it is designed to be used as is, from people who do NOT want to modify, or dabble in, code

So if all you need is some script that plays some sound file, and you feel sure enough about mission scripting, you can take DML's modules as some source of inspiration how to go about that. Bomb Range could be such an inspiration, Guardian Angel another. Your scrip would center on an event handler that traps 'shot', lhen looks at who shoots, analyses the weapon that was shot, and if all matches as desired, you play the sound file. On your way, you'll probably discover some of DCS's idiosyncrasies. To quote Calvin's Father: "they build character". I do not discuss code in this thread, though. For code discussions, I recommend that you open a separate thread or PM me.

Edited November 7, 2024 by cfrag

[cfrag]

Version 2.3.6 -- 20241107 -- Feature Update 

Recently, while assisting a fellow mission designer, I ran into a communications challenge: I tried to convey how modules talk to each other and realized just how inadequate all explanations that involve flags and methods and whatnot were. I needed a new, better approach that allows non-technical people to easier grasp how this works. As I so often do, I kicked the issue up to a bright friend of mine, who also happens to be an artist. It took us more than a bottle of wine, and some of her free-associative thinking, but we came up with what I now call the "Yeller Model". It's become part of the documentation, and I hope that it may help many aspiring mission designers to grasp more easily how modules interact, and it allows most of them to craft great missions without ever using the word flag. Please see the documentation.

Other than that, this release also sees a major new feature for one of DML's prime modules: heloTroops. Based on a request I added 'dropZones' that can kick up heloTroops' functionality a notch, while (of course) staying completely backwards compatible. It comes with its own new demo 'Inferno at sea', which is basically an endless extraction mission for helicopters, put together in a few minutes. 

Also, The Debugger has received a feature update which will bring great relief to a tiny goup of mission designers who actually use it: it now sports a feature to identify misspelled flag names ("commands" in "yeller" parlance). If you build a mission and for reasons unknown two modules seem to have problems talking to each other, a misspelled input or output is often the root cause. The Debugger's new "-x !" command (appropriately cryptic, don't you think?) lists all outputs that do not connect with an input (and vice versa), making it very likely, that one of the names was misspelled.

Oh, and finally - which has unfortunately been par for the course in the past few months - a new DCS update came with game-breaking changes: this time on the Syria map. For reasons unknown, that map breaks one of DCS's cardinal rule that no two objects may have the same name. In Syria, well over 100 airfields now have the same name "H", which can break any existing script that accesses airports by name. I hardened DML's modules, and I am sure that there will be lingering issues until the kind folk at ED/Ugra correct this breathtakingly obvious blunder.

 

All Changes in Detail

Documentation
    Main
        Yeller Model (new)
        HeloTroops 
        Debugger cunconnected in-/output detection  
        Yeller Model demo (new) 
        Inferno at Sea demo (new)
        
    Quick Ref 
        Yeller Model
        HeloTroops
        
Demos
    Inferno at sea: dropZones (new)
    Yeller Model (new)
    heloCargo (update)
    

Modules 
    cargoReceiver 2.1.0
        new noBounce Attribute 
    
    cfxZones 4.4.3
        additional hardening of property processing 
    
    civAir 3.1.0
        hardening for Syria's 100+ airfields known as "H"
        
    convoy 2.1.0
        new convoyTriggerMethod 
    
    heloTroops 4.0.0 
        new dropZone 
        new enforceDropZones
        
    playerScore 4.0.0
        improved event handling 
        suppress landing event after player spawn 
        
    theDebugger 3.1.0
        new detect unconnected inputs/outputs tool 
 

Enjoy,

-ch

 

Edited November 7, 2024 by cfrag

[DD_Friar]

@cfrag We the un-worthy are forever in your shadow of greatness for providing so many great updates.

Just to re-assure you, I too am now a devotee of the Debugger Module, I have seen the light...

Salute and many thanks once again.

Regards

Friar

[DD_Friar]

@cfrag ref Yeller Documentation

Just to support you in your method, as a job, I provide consultancy and support for a set of applications that share common data e.g. employee information. They have exactly the same approach. Each application when produced, has a set of values that it is willing to offer or "publish", it also has a set of values it requires or "subscriptions". For example the HR application will offer up a new employee name, start date, address. The Payroll application is listening for that information, the payroll application will offer up last pay date which the HR application is listening for.

To sum up you have exactly hit on an approach that is currently being used by a multi-million pound software house.

[cfrag]

4 minutes ago, DD_Friar said:

you have exactly hit on an approach that is currently being used by a multi-million pound software house.

Some good wine there, I guess  

[DD_Friar]

I don't actually work FOR the software house, well, used to, but they decided they no longer needed my services so I set up on my own, but funnily enough I was once the IT Manager for a Wine Merchants

 

[HanuXXL]

Thank you for the Yeller model explanation. I've had hard time grasping this, but I think that even a blockhead like me understood this.

[Guest]

Hi all,

for the life of me, I can't see how to 'clear' a Flag.  I realise it must be painfully simple.  I can raise a Flag when a Helo lands in a LZ (landed!) but just don't understand how to clear that Flag when the helo departs the zone.  I know there is departed!, but that isn't the same thing, right?

Sorry for the Noob question.  (I've read the excellent documentation, but just can't see it.)

Thanks

'52

Edited November 7, 2024 by Gunslinger52

[cfrag]

1 hour ago, Gunslinger52 said:

for the life of me, I can't see how to 'clear' a Flag. 

Perhaps you are overthinking this. Put differently, why do you think that you must clear a flag, what are you trying to achieve? When all you need is one DML module talk to another one to have it do something, DML takes care of lol that for you. In that case I also recommend that you look at the brand new chapter “Yeller Model” that may help you take a much simpler approach to combine modules.

Edited November 7, 2024 by cfrag

[Guest]

Thanks @cfrag

I will do that tonight.  I was also looking at the changer.

I think my issue is I am trying to mix DML with ME's triggers, and making a big mess.  And over thinking it   I will look to go DML only if that's possible.

Appreciate the suggestions!

'52

 

EDIT:  Just downloaded the new version.

Yeller = excellent

Geez even I get it now (fingers crossed)

Edited November 8, 2024 by Gunslinger52

[DD_Friar]

@Gunslinger52

When using the LZ module, as you say you have two flags landed! and departed! (these two have ! at the end meaning they are flags being updated)

Your other modules that are watching these two flags for activity are not just looking for it to be equal to 1 (although you can achieve that if that is what your mission logic needs but I don't think that is applicable here) they are looking for a change in its state/value.

Lets say you have the flag "landedAtZone1" against the landed! parameter and "departedZone1" against departed!

I land in the zone, "landedAtZone1" is hit and, by default, incremented. I have a another module, lets say a cloner. You want a vehicle to activate on the landing. That will have a parameter called clone? and flag that is "landedAtZone1" (LZ is the Yeller, Clone is the Listener "LZ to Clone are you receiving Over - Go ahead LZ Over, - This is LZ, we have a landing in Zone 1, Over - Roger That LZ I will send out the trucks, this is Clone Out.").  "This will action every time landedAtZone1 changes". Multiple landings means multiple clones. Same applied to "departedAtZone1".