DML - Mission Creation Toolbox [no Lua required]

[Captain Orso]

4 hours ago, cfrag said:

Hello everyone, 

      this is Chris, and thank you all for your kind words of encouragement, suggestions, and other feedback.

As we are leaving 2023, the second year of DML also draws to a close. It has come a long way, and with no small thanks to you, I was lucky to bring DML from an interesting idea to something that now many people use to make missions more fun for for everyone. 

As I'm preparing Version 2.0 of DML, I'm shifting its focus to better quality of life: better integration with Mission Editor. As a result, I'm de-emphasizing support for scripting. I've removed more arcane features like call-backs and API, and removed and have rewritten some two hundred pages of documentation -- in the hopes of making the easy things more clear, and done away with the geek stuff.

I'm looking forward to the new release in a few days/weeks, and of course your feedback. DML 2.0 is backward-compatible to the current version, so no worries, it will continue to work with your missions.

So, as 2023 ticks over into the new year, please allow me to raise my glass (filled to the brim with joy and good wine) to you all, and

wish you a happy, healthy and above all harmonious 2024!

It has been a pleasure - to many happy returns!

-ch
  

 

That's a whole box full of work, there.

I have one suggestion and one request.

Suggestion: For demo missions, don't use DO SCRIPT for lua files. That's IT on foot. Having to open a lua file, copy everything over to the ME and insert it there is anything but user friendly, and a source for errors. Using DO SCRIPT FILE is simple and even hard to do wrong.

Request: There are some veriable in scripts, which users might want to enter. I only know of one personally, but there might be others. In 'dcsCommon.lua', the variable sets the aircraft which can be used as transports: 'dcsCommon.troopCarriers = {"Mi-8MT", "UH-1H", "Mi-24P"}'. If you want to add, for example the UH-60L community mod, it must be added here. But editing files is not necessarily a good idea. the variable can be modified through the ME trigger command used to load the lua file to include the UH-60L very easily.

This and any other variables, which might be useful--I'm counting on you to know which ones, better than I--ought to be included in the Guide.

Smooth sailing to all, into 2024!!

[SPAS79]

1 hour ago, Captain Orso said:

In 'dcsCommon.lua', the variable sets the aircraft which can be used as transports: 'dcsCommon.troopCarriers = {"Mi-8MT", "UH-1H", "Mi-24P"}'. If you want to add, for example the UH-60L community mod, it must be added here. But editing files is not necessarily a good idea. the variable can be modified through the ME trigger command used to load the lua file to include the UH-60L very easily.

You can actually specify those in the trigger zones. It's all described in the (hefty, I know) manual. Page 304 and following, under 4.5.2 cfxHeloTroops

Edited December 31, 2023 by SPAS79

[Captain Orso]

11 hours ago, SPAS79 said:

You can actually specify those in the trigger zones. It's all described in the (hefty, I know) manual. Page 304 and following, under 4.5.2 cfxHeloTroops

 

Thanks for the reply.

In the documentation it constantly refers to making settings--it seems to me--in the 'config zone' and then goes not to never, ever, anywhere explain what a 'config zone' is, or how to use it. For all I can discover it's a trigger zone you can enter to gain access to some secret F10 radio menu list of choices, but that my just be my imagination running away with me.

Could you please explain this, so that the un-enlightened masses might understand it.

[cfrag]

48 minutes ago, Captain Orso said:

In the documentation it constantly refers to making settings--it seems to me--in the 'config zone' and then goes not to never, ever, anywhere explain what a 'config zone' is, or how to use it

My apologies for being obscure in the documentation. The 'Quick Reference' indeed does not cover the configuration zones, only the module's "action" zones. The full manual has a chapter "4.2.10 Module Configuration Zones" that I hope explains that concept somewhat. In addition to that (also in the Main doc) every module's own chapter should explain, under the heading "Module Configuration" for each module, how to create, place, name, and use a config zone, for example (clone zones):

 

If these chapters do not appear in your copy of the manual, something has gone horribly wrong, and I'll urgently need to check my export parameters. 

[SPAS79]

57 minutes ago, Captain Orso said:

Thanks for the reply.

In the documentation it constantly refers to making settings--it seems to me--in the 'config zone' and then goes not to never, ever, anywhere explain what a 'config zone' is, or how to use it. For all I can discover it's a trigger zone you can enter to gain access to some secret F10 radio menu list of choices, but that my just be my imagination running away with me.

Could you please explain this, so that the un-enlightened masses might understand it.

Cap. 

I'm not the author, that would be @cfrag. He's been super helpful to me explaining concepts and intricacies of this thing. 
I'll try to boil it down as much as my mind can: all of DML works on trigger zones'attributes (and that's the stroke of genius there). 

when you add a module (a lua file with a DOSCRIPT action) they *might* require a configZone (almost all of those I have been playing with so far). To provide that, you (the mission creator) are requested to place a trigger zone *somewhere* on the map, filling it with the config parameters relevant to that module and to your needs. 

The said trigger zone (acting as a module configZone) will not interact with the players/clients at all, it serves merely as a storage and "llok-up table" of sorts for how you want that particular module to behave. 

THEN you can add module-specific trigger zones (which might have some of the same settings of the configZones and override them in that specific instance). 

To explain it further, generally a configZone is where you specify if a module has to act "verbose" or not. ME zones (module-specific trigger zones) are those where you specify the exact behavior you want from the module, within certain parameters. 

The attached picture is all of the config zones I'm working on in my current mission/scenario. I use a color code (Black are regular config Zones, red are those with enabled verbosity, radioMenu is cyan etc...)

[cfrag]

14 hours ago, Captain Orso said:

Suggestion: For demo missions, don't use DO SCRIPT for lua files. That's IT on foot. Having to open a lua file, copy everything over to the ME and insert it there is anything but user friendly, and a source for errors. Using DO SCRIPT FILE is simple and even hard to do wrong.

That is indeed the case - unless you are the unlucky chap who is developing a script. The demos I write are part of the testing cycle, and when I'm finished developing a module I create the demo mission as a test case. Often I detect some error, update the code and then have to re-import it. And that is where ME's DOSCRIPTFILE action shows its neolithic face: it's not "IT on foot" as you named it (  ), it's "IT that hates you": you need to remove the old Lua from the mission, save the mission, then add the new code to the mission. The sequence "Ctrl-A, Ctrl-C, (switch back), Ctrl-A, Ctrl V" is pedestrian, yes. But still not a fraction as agonizing to me as the dance for the imported file. I'm hoping that some fine day, ED add some kind of development support to ME that is worthy of that name.

Edited January 1 by cfrag

[Captain Orso]

Quote

 "IT on foot" as you named it (  ), it's "IT that hates you"

Ah, yes, that is because the ME is too dumb to do it's job. Way back when I used to do application programming, compilers ALWAYS picked up the actual version of every included library call in the code. People would have been up in arms and kicking IBM in the bal... *ehm* nether regions, if they expected you to go through your code every time and delete and read add every library call you added to you code, just to get the newest code.

So, in the light of that, yeah, it kind of does make sense.

THANKS OBAM... EAGLE DYNAMICS!!

[cfrag]

2 minutes ago, Captain Orso said:

Way back when I used to do application programming, compilers ALWAYS picked up the actual version of every included library call in the code.

Huh. Young whippersnappers. You guys had it good, you had compilers with auto-generated makefiles. Actually, you had compilers. Back in the day, my first program was punched into cards (IBM/360 with TSO), and we had to number the cards - in binary numbers -- AND WE LIKED IT!!! Uphill both ways! (ancient Monty Python reference alert)

TBH, we don't need (although it would be very welcome) if our Lua code was compiled/scanned in real-time while coding -- or compiled at all, DCS does AFAIK not use a JITC, just interprets the bytecode -- so we can spot syntax- and reference errors at write time. I'd welcome late 80's IDE features like above mentioned "make" files, some cross referencing (heck, even "Merlin", my 6502 Assembler for the Apple ][ could do that), and (one can hope), some profiling tools. 

Today the best DCS offers us script developers are copy-paste from notepad plus (which by itself is awesome) into a dinky text box. Just imagine how great development could be if we could integrate DCS with Visual Studio, had access to source level debugging and build a mission/test cases on keypress. For DCS I even had to build my own debugger (DML 2.0 has a nice surprise for mission designers here)... 

Alright. Enough woe is me. After all, we have DCS, so I'll stop b****ing  

[Captain Orso]

3 hours ago, SPAS79 said:

Cap. 

I'm not the author, that would be @cfrag. He's been super helpful to me explaining concepts and intricacies of this thing. 
I'll try to boil it down as much as my mind can: all of DML works on trigger zones'attributes (and that's the stroke of genius there). 

when you add a module (a lua file with a DOSCRIPT action) they *might* require a configZone (almost all of those I have been playing with so far). To provide that, you (the mission creator) are requested to place a trigger zone *somewhere* on the map, filling it with the config parameters relevant to that module and to your needs. 

The said trigger zone (acting as a module configZone) will not interact with the players/clients at all, it serves merely as a storage and "llok-up table" of sorts for how you want that particular module to behave. 

THEN you can add module-specific trigger zones (which might have some of the same settings of the configZones and override them in that specific instance). 

To explain it further, generally a configZone is where you specify if a module has to act "verbose" or not. ME zones (module-specific trigger zones) are those where you specify the exact behavior you want from the module, within certain parameters. 

The attached picture is all of the config zones I'm working on in my current mission/scenario. I use a color code (Black are regular config Zones, red are those with enabled verbosity, radioMenu is cyan etc...)

THANK YOU!! 

 

1 hour ago, cfrag said:

Huh. Young whippersnappers. You guys had it good, you had compilers with auto-generated makefiles. Actually, you had compilers. Back in the day, my first program was punched into cards (IBM/360 with TSO), and we had to number the cards - in binary numbers -- AND WE LIKED IT!!! Uphill both ways! (ancient Monty Python reference alert)

TBH, we don't need (although it would be very welcome) if our Lua code was compiled/scanned in real-time while coding -- or compiled at all, DCS does AFAIK not use a JITC, just interprets the bytecode -- so we can spot syntax- and reference errors at write time. I'd welcome late 80's IDE features like above mentioned "make" files, some cross referencing (heck, even "Merlin", my 6502 Assembler for the Apple ][ could do that), and (one can hope), some profiling tools. 

Today the best DCS offers us script developers are copy-paste from notepad plus (which by itself is awesome) into a dinky text box. Just imagine how great development could be if we could integrate DCS with Visual Studio, had access to source level debugging and build a mission/test cases on keypress. For DCS I even had to build my own debugger (DML 2.0 has a nice surprise for mission designers here)... 

Alright. Enough woe is me. After all, we have DCS, so I'll stop b****ing  

LOL I did my apprenticeship on a SYS/370 running VSE 

My colleges did Univac with punchcards until they decided to go "online", but there were still boxes of punchcards in our storage room. We used them for writing notes on. In fact I still have a stack of them for the same purpose 

Make files came MUCH later when we started migrating to AIX, and then to HP-UX, but my then I was out of programming and doing SysAdmin.

I've done some extensive work with shell scripting, but I never got into C and god forbid and OOP . I do want to learn LUA sometime, but I haven't found the right state-of-mind yet - probably a bullet through my brain would do the trick 

So I think I figured out what I needed to find out. All I really wanted to do was add the community mod UH-60L into the CSAR demo. I was trying to do it through the dcsCommons both through simply changing the variable in a trigger and then through a config zone, but dcsCommons doesn't use a config file for 'troopCarriers' and changing dcsCommons.troopCarriers didn't help, bc csarManager changed it in its config zone, so I changed the csarManager config zone and BINGO it works 

Many, many thanks for all the assistance!! 

Edited January 1 by Captain Orso

[SPAS79]

anybody has a list of valid unit names? I'm trying to populate defenders for a farp Zone. 

[SPAS79]

disregard, 
it's at 
https://github.com/mrSkortch/DCS-miscScripts/tree/master/ObjectDB

 

as per documentation

 

[DD_Friar]

Quick question if I may...

I want to have a cloner zone only triggered once. The trigger will be a blue helicopter entering a unit zone

When it enters the unit zone it triggers a flag "goConvoy-1" to release the hold on the convoy. 

The same flag currently will trigger the cloner for the red helicopter.

I want to avoid more than 1 player entering the zone and repeating the clone of the attack helicopter.

Is the correct way to do this to use a unit zone and have the same flag that starts the convoy goConvoy-1, trigger the clone AND turn off the same unit zone via uzOff?

would that work?

Edited January 5 by DD_Friar

[cfrag]

19 hours ago, DD_Friar said:

I want to have a cloner zone only triggered once. The trigger will be a blue helicopter entering a unit zone

One way to do that is to tell the cloner to look at the input? flag and only trigger, if the value of the input flag has changed and is less than two (and also make sure that that triggering flag is incremented, so the first time it is incremented from 0 to 1, cloner triggers, and any time after that, it changes from 1 to 2 or 2 to 3 and so forth, but since the condition '<2' is no longer fuifilled, it will not trigger a new clone clycle. Please have a look at 4.2.3.3 Watchflags in the docs, that may help you.

In addition to that, I'm thinking about a possible 'maxSpawn' attribute, but that will take some time and probably not make it to the next DML release.

 

[DD_Friar]

@cfrag Many thanks for the reply. I was not aware of the condition statement, which would hopefully suit my needs.

[DD_Friar]

@cfrag Read the manual, added triggerMethod <2, works a treat.

This option (which I had so ashamedly over looked before) offers so many more options to the mission build and complexity.

Are you sure is there is no way I can buy you a coffee?

[GWdope]

Hey, I have some questions about the persistence module that I’m too dumb to figure out on my own. 
 

Can one save file, with say saveFlag, info work for multiple missions, like in a stage of a campaign? Also, in the saveFlag attribute, what is the correct grammar for flag values or are values automatically saved if they exist?

I figured it out! But now I want to know if I can prevent the playerScore module form being persistent? 

Edited January 10 by GWdope
self explanatory

[cfrag]

9 hours ago, GWdope said:

now I want to know if I can prevent the playerScore module form being persistent? 

Huh. While I believe it is possible do do so, I honestly never imagined that someone would want to selectively enable persistency. Just goes to show how limited my imagination really is

Now, if you want  a module to not persist, simply load it before persistence is loaded, i.e. place PlayerScore's DOSCRIPT action when you load DML before persistence. If that happens, PlayerScore does not see the persistence module, and does not sign up for persistence, and the scores aren't saved.

I've never tried this, but it should prevent PlayerScore to save the score files when persistence's 'save' is triggered.

[GWdope]

Thanks! As for this use case, I’m using playerScore for campaign stage score/advancement so having a players score persisting from mission to mission in a stage would mess that up. I’m only using persistence for a few flags to control what enemy IADS units get spawned. 

[Panthir]

1 hour ago, GWdope said:

Thanks! As for this use case, I’m using playerScore for campaign stage score/advancement so having a players score persisting from mission to mission in a stage would mess that up. I’m only using persistence for a few flags to control what enemy IADS units get spawned. 

Hello. Incremental score most probably will match you.

[cfrag]

DML II has arrived.

Version 2.0.0 - Major Update - 20240111

Happy new year everyone! We start 2024 with a bang, just like we should. I'm proud to present to you DML II, the next iteration of what once started as my humble homebrew small library of helpful code snippets and - after I hit upon the concept of passing valuable data with trigger zones - took flight in ways I had never imagined.

While a lot of modules have received some upgrade, here are the big hitters for "II":

• The Debugger 2.0 
  There are only few of us that use it, but I've massively increased what it can do, including
  • inspect memory (Lua variables) and - yes - change them
  • intercept DCS 'events' and tell you when they happen 
  • spawn 'generics' so you can better test your mission's reactions 
     
• The "Shock Block" (Main Manual)
  I've extensively re-structured and re-written passages, removed anything too arcane (no more Lua discussion) - all in the hope of making it a bit more accessible to those of you who actually RTFM (my hat's off to you)

And there is one change some of you may not appreciate that much: I've harmonized the file names for modules and removed the "cfx" prefix from most of them. This makes it easier to find them. Note that I only changed the file names, so those of you who import by file name may have to re-jigger their imports. 

So here are the changes in detail:

Manual
    - Main 
        - massive rewrite, better (?) introduction, more consistency
        - The Debugger many additions 

    - QuickRef 
        - many updates 

Demos 
    - artillery with UI - update
    - being persistent - update 
    - boom boom - update 
    - debug events and more *new* 
    - helo cargo - update 
    - moving spawners II - update 
    - moving spawners - update 
    - once, twice, three times maybe - update 
    - player score - update 
    - players in the zone - update 
    - willie nillie - update 
    - xFlags field day - update 
    

Modules 
    - airfield 2.0.0 
        color support 
        farps supported 
        unmanaged airfields 
        
    - artillery (removed)
    
    - artilleryUI 2.0.0 
        dmlZones, OOP, cleanup 
    
    - artilleryZones 2.0.0 
        dmlZones, OOP, cleanup 
        
    - cargoReceiver 2.0.0 
        dmlZones, OOP, cleanup 
        
    - cfxMon (removed)
    
    - cfxMX 2.0.0 
        harmonized with cfxGroups 
        cleanup 
    
    - cloneZone 2.0.1 
        better handling of deffered cloning with empty!
        cleanup 
        
    - objectDestructDetector 2.0.1
        added sanity checks: location for object 
        
    - objectSpawnZones 2.0.0 
        cleanup 
    
    - persistence 2.0.0
        dmlZones, OOP
        cleanup 
    
    - playerScore 3.0.1
        cleanup 
        
    - playerScoreUI 2.1.1
        cleanup
    
    - pulseFlags 2.0.1
        cleanup 
        
    - smokeZones 2.0.0 
        cleanup 
        
    - spawnZones 2.0.0
        cleanup
    
    - cfxSSBSingleUse 2.0.0
        libcheck at startup 
        cleanup 
        
    - cfxZones 4.1.1
        cleanup 
        getBoolFromZoneProperty() now supports "on" and "off" 
        evalRemainder() updates 
        
    - cloneZones 2.0.0 
        cleanup 
        
    - countDown 2.0.0 
        dmlZones, OOP, cleanup 
        config zone upgrade 
        output method defaults to 'inc' 
        
    - dcsCommon 3.0.0 
        fixed stringStartsWith()
        point2text new intsonly option 
        arrangeGroupDataIntoFormation hardened 
        cleanup 
        new pointInDirectionOfPoint() 
        createGroundGroupWithUnits now supports liveries 
        new getAllExistingPlayersAndUnits() 
        
    - delayFlag 2.0.0 
        cleanup
        
    - factoryZone 3.0.0 
        dmlZones, OOP 
        support for liveries 
        
    - fireFX 2.0.1 
        fixed rndLoc 
        
    - groupTracker 2.0.0 
        dmlZones, OOP, cleanup 
        legacy support 
        
    - messenger 3.0.0 
        removed f?
        removed in? 
        cleanup 
        
    - playerZone 2.0.0
        dmlZones, OOP
        new red#
        new blue# 
        new total#
        
    - radioMenu 2.2.0 
        cleanup 
        
    - TDZ 1.0.2 
        manual placement option 
        filters FARPS 
        
    - The Debugger 2.0.0 
        dmlZones, OOP, cleanup 
        new eventmon 
        adding events 
        eventmon last 
        query 
        write 
        analyze 
        smoke 
        spawn system 
        spawn generics 
        spawn generics config zone 
        event? attribute 
        bug fixes 
    
    - unitPersistence 
        dmlZones
        cleanup
        
    - williePete 2.0.0 
        dmlZones, OOP, cleanup 
        guards for multi-unit player groups 
        new getFirstLivingPlayer
    
    - xFlags 2.0.0 
        dmlZones, OOP, cleanup 
        xDirect#
        xCount#
 

Enjoy,

-ch

 

Edited January 11 by cfrag

[Panthir]

7 hours ago, cfrag said:

DML II has arrived.

Version 2.0.0 - Major Update - 20240111

Happy new year everyone! We start 2024 with a bang, just like we should. I'm proud to present to you DML II, the next iteration of what once started as my humble homebrew small library of helpful code snippets and - after I hit upon the concept of passing valuable data with trigger zones - took flight in ways I had never imagined.

While a lot of modules have received some upgrade, here are the big hitters for "II":

• The Debugger 2.0 
  There are only few of us that use it, but I've massively increased what it can do, including
  • inspect memory (Lua variables) and - yes - change them
  • intercept DCS 'events' and tell you when they happen 
  • spawn 'generics' so you can better test your mission's reactions 
     
• The "Shock Block" (Main Manual)
  I've extensively re-structured and re-written passages, removed anything too arcane (no more Lua discussion) - all in the hope of making it a bit more accessible to those of you who actually RTFM (my hat's off to you)

And there is one change some of you may not appreciate that much: I've harmonized the file names for modules and removed the "cfx" prefix from most of them. This makes it easier to find them. Note that I only changed the file names, so those of you who import by file name may have to re-jigger their imports. 

So here are the changes in detail:

Manual
    - Main 
        - massive rewrite, better (?) introduction, more consistency
        - The Debugger many additions 

    - QuickRef 
        - many updates 

Demos 
    - artillery with UI - update
    - being persistent - update 
    - boom boom - update 
    - debug events and more *new* 
    - helo cargo - update 
    - moving spawners II - update 
    - moving spawners - update 
    - once, twice, three times maybe - update 
    - player score - update 
    - players in the zone - update 
    - willie nillie - update 
    - xFlags field day - update 
    

Modules 
    - airfield 2.0.0 
        color support 
        farps supported 
        unmanaged airfields 
        
    - artillery (removed)
    
    - artilleryUI 2.0.0 
        dmlZones, OOP, cleanup 
    
    - artilleryZones 2.0.0 
        dmlZones, OOP, cleanup 
        
    - cargoReceiver 2.0.0 
        dmlZones, OOP, cleanup 
        
    - cfxMon (removed)
    
    - cfxMX 2.0.0 
        harmonized with cfxGroups 
        cleanup 
    
    - cloneZone 2.0.1 
        better handling of deffered cloning with empty!
        cleanup 
        
    - objectDestructDetector 2.0.1
        added sanity checks: location for object 
        
    - objectSpawnZones 2.0.0 
        cleanup 
    
    - persistence 2.0.0
        dmlZones, OOP
        cleanup 
    
    - playerScore 3.0.1
        cleanup 
        
    - playerScoreUI 2.1.1
        cleanup
    
    - pulseFlags 2.0.1
        cleanup 
        
    - smokeZones 2.0.0 
        cleanup 
        
    - spawnZones 2.0.0
        cleanup
    
    - cfxSSBSingleUse 2.0.0
        libcheck at startup 
        cleanup 
        
    - cfxZones 4.1.1
        cleanup 
        getBoolFromZoneProperty() now supports "on" and "off" 
        evalRemainder() updates 
        
    - cloneZones 2.0.0 
        cleanup 
        
    - countDown 2.0.0 
        dmlZones, OOP, cleanup 
        config zone upgrade 
        output method defaults to 'inc' 
        
    - dcsCommon 3.0.0 
        fixed stringStartsWith()
        point2text new intsonly option 
        arrangeGroupDataIntoFormation hardened 
        cleanup 
        new pointInDirectionOfPoint() 
        createGroundGroupWithUnits now supports liveries 
        new getAllExistingPlayersAndUnits() 
        
    - delayFlag 2.0.0 
        cleanup
        
    - factoryZone 3.0.0 
        dmlZones, OOP 
        support for liveries 
        
    - fireFX 2.0.1 
        fixed rndLoc 
        
    - groupTracker 2.0.0 
        dmlZones, OOP, cleanup 
        legacy support 
        
    - messenger 3.0.0 
        removed f?
        removed in? 
        cleanup 
        
    - playerZone 2.0.0
        dmlZones, OOP
        new red#
        new blue# 
        new total#
        
    - radioMenu 2.2.0 
        cleanup 
        
    - TDZ 1.0.2 
        manual placement option 
        filters FARPS 
        
    - The Debugger 2.0.0 
        dmlZones, OOP, cleanup 
        new eventmon 
        adding events 
        eventmon last 
        query 
        write 
        analyze 
        smoke 
        spawn system 
        spawn generics 
        spawn generics config zone 
        event? attribute 
        bug fixes 
    
    - unitPersistence 
        dmlZones
        cleanup
        
    - williePete 2.0.0 
        dmlZones, OOP, cleanup 
        guards for multi-unit player groups 
        new getFirstLivingPlayer
    
    - xFlags 2.0.0 
        dmlZones, OOP, cleanup 
        xDirect#
        xCount#
 

Enjoy,

-ch

 

 

Many thanks for this great update. I would like to address an issue related to the cfxObjectDestructDetector.lua, scenery objects and the way you can award score to their destruction (playerscore integration). For example the bridge that you can see in the screenshot is divided in 4 scenery objects. Although each trigger zone has deferent name (car_bridge_4line-1, 2 etc) the "NAME" attribute is exactly the same (car_bridge_4line). So if you prepare a PvP mission, due to the fact that the vast majority of the bridges are consisted of several car_bridge_4line scenery objects, it is not possible to setup bridges as targets for both coalitions (the same issue occurs for several other scenery objects), because if you use the "NAME" in the playerScoreTable to assign a score value, DML will not be able to know to which coalition will award the score (it's confirmed through extensive testing that although the Blue coalition destroys a Red Bridge the score is awarded several times to the Red Coalition). Moreover, OBJECT ID (in the past was working perfectly for both playeScoreTable and red and blue ScoreTables) it is confirmed that is working correctly only if you assign to the scenery object a Flag value "f!", to award score to coalitions via the red and blue ScoreTables. So, I didn't notice any change in DML II version related to the aforementioned subjects. The most appropriate solution IMO would be to be able to use only flag values "f!" for both playerScoreTable red and blueScoreTables. In this context, awarding score to scenery objects will be without any trouble. I don't know how difficult will be for you to implement such a change.

Edited January 11 by Panthir

[cfrag]

5 hours ago, Panthir said:

it is not possible to setup bridges as targets for both coalitions

If both coalitions have the goal to destroy the same (identical) scenery object, then indeed that currently can't always work. Then again, it's difficult to argue here which faction should be awarded the points as both have reached their goal (the bridge is down). 

If you, on the other hand, have two different (scenery object) bridges A and B, they indeed can have the same NAME (e.g. "car_bridge_4Lane") and only differ in their OBJECT ID. If blue targets bridge A while red targets bridge B then I think that you should be able to set up one objectDestructDetectors for each bridge that bangs on their separate flags that can feed PlayerScore via the redScoreFlags and blueScoreFlag options  - just as you state.

5 hours ago, Panthir said:

The most appropriate solution IMO would be to be able to use only flag values "f!" for both playerScoreTable red and blueScoreTables. In this context, awarding score to scenery objects will be without any trouble. I don't know how difficult will be for you to implement such a change.

 Apologies, I'm not entirely sure what you mean - my impression is that this is already implemented: you set up a flag (say 'bridgeAdown') and bang that with an objectDestructDetector over BridgeA, and a flag 'bridgeBdown' with an ODD that bangs on that flag for bridge B. Then put bridgeAdown in blueScoreFlags' attributes, and bridgeBdown in redScoreFlags's attributes. This should work unless both A and B target the same bridge. And yes, if with this setup red blows bridge A (blue's target), blue will get the award. That's fair to avoid either side from blowing their own bridges to deny the other side points.

How do you suggest we change this, and which case will that cover? With some luck we can close the remaining gap quickly.

 

Edited January 11 by cfrag

[Panthir]

14 hours ago, cfrag said:

If both coalitions have the goal to destroy the same (identical) scenery object, then indeed that currently can't always work. Then again, it's difficult to argue here which faction should be awarded the points as both have reached their goal (the bridge is down). 

If you, on the other hand, have two different (scenery object) bridges A and B, they indeed can have the same NAME (e.g. "car_bridge_4Lane") and only differ in their OBJECT ID. If blue targets bridge A while red targets bridge B then I think that you should be able to set up one objectDestructDetectors for each bridge that bangs on their separate flags that can feed PlayerScore via the redScoreFlags and blueScoreFlag options  - just as you state. (After extensive testing: A main issue is that OBJECT ID doesn't work at all. In the past it was working perfectly when it was used in playerScoreTable and redScoreFlags and blueScoreFlag, as well).

 Apologies, I'm not entirely sure what you mean - my impression is that this is already implemented: you set up a flag (say 'bridgeAdown') and bang that with an objectDestructDetector over BridgeA, and a flag 'bridgeBdown' with an ODD that bangs on that flag for bridge B. Then put bridgeAdown in blueScoreFlags' attributes, and bridgeBdown in redScoreFlags's attributes. This should work unless both A and B target the same bridge. And yes, if with this setup red blows bridge A (blue's target), blue will get the award. That's fair to avoid either side from blowing their own bridges to deny the other side points. (flags are working ok only for the redScoreFlags and blueScoreFlag).

How do you suggest we change this, and which case will that cover? With some luck we can close the remaining gap quickly.

My suggestions:

a. Solve the issue that OBJECT ID is not working. It will be a useful option.

b. add as an option for playeScoreTable to be able to handle flags as well.

I hope I helped you.

 

14 hours ago, cfrag said:

 

 

[cfrag]

9 minutes ago, Panthir said:

a. Solve the issue that OBJECT ID is not working. It will be a useful option.

Unfortunately, ObjectIDs for scenery objects can (and do) change without warning (nor notification) between any DCS releases. That was the main reason that objectDestructDetector silently failed after a DCS release - and that made many missions suddenly stop working in critical parts. Hunting down ObjectIDs after every DCS release is something supremely unfun to mission designers. This is the reason that they no longer work with PlayerScore - it introduces a ticking time bomb into any mission that you are referencing an ObjectID in - for it will fail sometime. And you won't know until you either check after each update - or your players complain that they achieved the objective, but the mission did not respond. So, ObjectIDs are not to be trusted, and DML now uses the (sadly not unique) name of scenery objects instead.

9 minutes ago, Panthir said:

add as an option for playeScoreTable to be able to handle flags as well.

Now this sounds interesting! How do you envision how that works, and how is that different from  red/blueScoreFlags? It sounds like something that we could get running quickly.

Edited January 12 by cfrag

[Panthir]

3 hours ago, cfrag said:

Unfortunately, ObjectIDs for scenery objects can (and do) change without warning (nor notification) between any DCS releases. That was the main reason that objectDestructDetector silently failed after a DCS release - and that made many missions suddenly stop working in critical parts. Hunting down ObjectIDs after every DCS release is something supremely unfun to mission designers. This is the reason that they no longer work with PlayerScore - it introduces a ticking time bomb into any mission that you are referencing an ObjectID in - for it will fail sometime. And you won't know until you either check after each update - or your players complain that they achieved the objective, but the mission did not respond. So, ObjectIDs are not to be trusted, and DML now uses the (sadly not unique) name of scenery objects instead.

Now this sounds interesting! How do you envision how that works, and how is that different from  red/blueScoreFlags? It sounds like something that we could get running quickly.

 

At first, Red/blueScoreFlags award score only to coalitions. The player that bangs the flag (destroys the target) doesn't get any points. If you remember, Red/blueScoreFlags were created to provide the mission designer with an option to award score to teams for targets that were destroyed by AI. 

Secondly, given the fact that OBJECT ID is not working anymore, a mission designer is able to set up score for scenery objects, only in Red/blueScoreFlags via flag usage. It will be a nice option to allow flags to be used in playerScoreTable, as well. This option will give the mission editor flexibility to allow score award to players for destroyed scenery objects.

Dear @cfrag Moreover I tested the following ownedzones mission template3 ring circus Blue and Red 120 sec coundown.miz and it seems that although zones are changing hands and you get the relevant messages, the "resetting" 120sec countdown is not working anymore.  

Edited January 12 by Panthir