DML - Mission Creation Toolbox [no Lua required]

[cfrag]

7 hours ago, Chess96 said:

I realized that the French smoke rockets are not recognized as a valid target marker by the script.

Turns out that while WP recognizes the Gazelle's WP, it doesn't recognize the F1's. In DCS they are different weapons. Why? REASONS!

Below please find the updated WP module, will be part of the next update.

williePete.lua

[cfrag]

1 hour ago, Sinclair_76 said:

It seems to stay at the original location. My hope was, that it moves with the lead vehicle.

Please test with below new versions and check if it now works. Note: required changes to common and zones.

 

dcsCommon.lua cfxZones.lua

[Sinclair_76]

36 minutes ago, cfrag said:

Please test with below new versions and check if it now works. Note: required changes to common and zones.

 

dcsCommon.lua 112.16 kB · 1 download cfxZones.lua 121.1 kB · 1 download

Pasted the updated scripts but it doesn't appear to work.

[mimamema]

8 hours ago, cfrag said:

AFAIK, spawning a FARP isn't yet fully supported in DCS, although this may have changed in the past few months; I have seen nothing that would suggest so, and I'd be happy for any links that show working FARP spawns so I can get to work on this important feature. With DCS's current slot system, spawned FARPS can't allow players to slot in (enter the game) from there, but hopefully it will allow them to refuel and rearm.

I'm aware of some interesting work being done on 'teleported' FARPS ("teleportation" is pretty much identical clones in DML). These are FARPS that already exist and are then moved to a new location, and they even can allow players to enter the game from there. A hack, and IMHO not ready for prime time, too many open questions -- but interesting nonetheless. 

https://github.com/brihernandez/DCSBuildableFARPs

 

 

Yes, sorry,  I should have specified that my idea goes more towards being able to repair, rearm and refuel a unit than being able to spawn from it. I read about being able to spawn on them a wee while ago as well, maybe the new dynamic slots/spawns are creating new possibilities in this regard.  

My question was more going in this path RotorOps PERKS · spencershepard/RotorOps Wiki · GitHub and how you can get a fat cow even with a flyable helicopter RotorOps/scripts/RotorOpsPerks.lua at main · spencershepard/RotorOps · GitHub . I would be even happy if we could get the IA to do it either with DML, but yes, both player and IA would be ideal and an amazing possibility in DML. I could even think of carrying ammo trucks next to a SAM unit you have deployed before so they can have more ammunition, I don't know, I´m just trying to give more possibilities to what we can do, all within DML and not having to add modified versions of MIST and other scripts like CTLD that may worth the effort for more complex things. 

[cfrag]

1 hour ago, Sinclair_76 said:

Pasted the updated scripts but it doesn't appear to work.

Let's try this again

 

dcsCommon.lua cfxZones.lua

[cfrag]

1 hour ago, mimamema said:

how you can get a fat cow

Ah, I see. Yes, that's a clever hack that moves an existing FARP with infrastructure to your position, checks that there are no enemies around, and if there's a cow close by 'opens' the FARP for business. It's essentially the 'teleported' FARP, conditional on the presence of a Hook with a special name ("Fat Cow") in proximity. It makes it look as if you can refuel from the cow.

I'm hesitant to try this (very, hacky), but if I have time, sure  

[Sinclair_76]

On 7/1/2024 at 7:42 PM, cfrag said:

Let's try this again

 

dcsCommon.lua 112.29 kB · 1 download cfxZones.lua 121.56 kB · 1 download

Close! But useHeading as well as useOffset have the clones facing the original direction. With the offset I would've expected that. With the useHeading I would have hope it would align it's direction with the lead vehicle. 

[cfrag]

1 hour ago, Sinclair_76 said:

Close!

Wow, that double indirection really put me through the wringer. How's this? 

dcsCommon.lua cfxZones.lua

[vgilsoler]

Hi @cfrag

I'm trying to use airframe limited, slotty and ssbclient with singleUse attribute to force players to one life mission. I'm using DML 2.2.6b.

If I run the mission on single-player, it works as I intended. I can't respawn from the slot I've crashed. But If I launch it in multiplayer, I can respawn after crashing the airplane.

Does slotty require some type of config for single use in multiplayer like SSB script?

[cfrag]

19 minutes ago, vgilsoler said:

Does slotty require some type of config for single use in multiplayer like SSB script?

AFAIK, slotty simply works and requires no configuration - so any issue is hopefully somewhere else. Can you give me a slightly more detailed example of what is happening (order of events like 'I slot into the A-10, crash it, ...' explain what you expected to see and then why what you are seeing is not what you would expect. This would allow me to better understand the issue at hand. If possible, please also PM or attach the miz so I can try and inspect it at leisure.

I'm sure that we can sort this out quickly.

[vgilsoler]

4 minutes ago, cfrag said:

AFAIK, slotty simply works and requires no configuration - so any issue is hopefully somewhere else. Can you give me a slightly more detailed example of what is happening (order of events like 'I slot into the A-10, crash it, ...' explain what you expected to see and then why what you are seeing is not what you would expect. This would allow me to better understand the issue at hand. If possible, please also PM or attach the miz so I can try and inspect it at leisure.

I'm sure that we can sort this out quickly.

I took slot one, crashed the plane, moved to slot two, respawned in slot two, moved to slot one, respawned in slot one. -> multiplayer (Wrong behaviour)

I took slot one, crashed the plane, moved to slot two, respawned in slot two, moved to slot one, not able to respawn in slot one. -> single-player (Correct behaviour*)

cfxSSBClientConfig zone attributes -> verbose: true, singleUse: true, ssbAutoenable: true

limitedAiframesConfig -> verbose: true, userCanToggle: false, maxBlue: 8, announcer: false.

airbase zone atributes -> ssbClient, openOnStart: true, pilotsafe blue

 

Order of DML modules to be loaded:

DCSCommon, cfxZones, cfxGroups, slotty, limitedAirframes, ssbClient

* In fact, I would like to restrict crashed pilot to not be able to spawn in any other slot except spectator, but I can deal with this behaviour.

 

 

[Sinclair_76]

19 hours ago, cfrag said:

Wow, that double indirection really put me through the wringer. How's this? 

dcsCommon.lua 112.43 kB · 0 downloads cfxZones.lua 121.39 kB · 0 downloads

Works like a charm now. Thanks!

 

[cfrag]

58 minutes ago, vgilsoler said:

I took slot one, crashed the plane, moved to slot two, respawned in slot two, moved to slot one, respawned in slot one. -> multiplayer (Wrong behaviour)

Ah, so we are looking at a possible misbehavior of the 'singleUse' feature in multiplayer. The expected behavior is that any client slot can only be used once - correct?

[vgilsoler]

1 minute ago, cfrag said:

Ah, so we are looking at a possible misbehavior of the 'singleUse' feature in multiplayer. The expected behavior is that any client slot can only be used once - correct?

Correct.

[cfrag]

6 minutes ago, vgilsoler said:

Correct.

Silly question: is the SSB script installed and running on the server= If so, for singleUse to work, the 'ssb.kickReset' option must be disabled on the server. If you only run slotty, this is not required.

Edited July 3, 2024 by cfrag

[vgilsoler]

3 minutes ago, cfrag said:

Silly question: is the SSB script installed and running on the server= If so, for singleUse to work, the 'ssb.kickReset' option must be disabled on the server. If you only run slotty, this is not required.

 

Only slotty is used. The idea is to avoid to install anything in possible mission hosts.

[cfrag]

15 minutes ago, vgilsoler said:

Only slotty is used. The idea is to avoid to install anything in possible mission hosts.

Here's minimal miz designed to test singleUse. It works on my computer as designed. Please check with your computer what results you receive, and try and go from there. This is hopefully just a small thing I overlooked in a single script.  

singe use or not.miz

[cfrag]

Version 2.27 - 20240704 - Feature Update: XRef for The Debugger

While working on my current Oeuvre "Expansion" I came across some subtle yet difficult to track down effects. I did what I always do in these cases: I broke out "The Debugger" and tried to get to the bottom of the issue. While in hot pursuit of a particularly stubborn bug, I realized that the debugger itself was missing an important feature that is becoming more important with the complexity of missions that can be created with DML: it won't tell me which DML zone uses which flags, nor can it tell me which flag is used by which zone. And so I added a new powerful cross-indexing ability to DML. 

You now can, from inside the mission, see which flags connect how to your DML zones. It helped me to finally track down the bug I was tracking: I misspelled a flag's name, something that the cross-referenced DML zone's for the flag made blindingly obvious.

Other changes include various updates to modules that were either bug fixes or kind suggestions from you - so thank you all for the great feedback!
Oh, and there's another mystery module that I'm testing: 'Convoy'. It's nowhere near a usable state, so I recommend that outside of curiosity, you should stay well clear of it until it - eventually - becomes part of DML. And yes, it's current design is that it does what it says on the tin

Changes in Detail 
Manual 
    Main 
        - The Debugger updates for cross reference 
        - various small updates 
        
    Quickref
        - various small updates 
        
Demos 
    - BFM Combat Trainer - update 
    - Willie Nillie - update 
    
Modules
    - cfxMX 2.0.2 
        Moved common code from modules to MX 
    
    - cfxZones 4.3.6 
        - updates to linked/moving zone logic 
        - code hardening for DCS Web Editor compatibility 
        
    - convoy 0.0.0 
        - new and mysterious 
        
    - dcsCommon 3.0.9
        - added stronger support for linked zones  

    - objectDestructDetector 2.0.3
        - warning if no output connected 
        
    - spawnZones 2.0.3
        - corrected typo in spawnUnits? attribute 
        
    - stopGaps 1.1.2
        - new allNeutral attribute 
        
    - The Debugger 3.0.0
        - cross reference 
    
    - williePete 2.0.5 
        - added Mirage F1 WP 
  

Enjoy,

-ch

[DD_Friar]

@cfrag Apologies if this is all a pipe dream and not at all possible.

MODULE FEATURE REQUEST

Module: ownedZonesConfig

Feature Requested: Additional field to hold text description for coalition. Possible field syntax name ownedByNeutral, ownedByBlue and ownedByRed

For Red (default value "Red") a designer might use for example (player v AI, player playing Blue)

"Occupied" or "Axis Held" or "Enemy In Control"

For Blue (default value "Blue")

"Liberated" or "Allied Held" or "Friendly Controlled"

For Neutral (default value "Neutral")

"Unoccupied" or "Free"

Module: messenger

Feature Requested: Addition of new Data Access Wildcard called something like <vtxt: flag name>. Used to display information provided by ownedZone field ownedBy#

Request(s) Rationale: When creating a mission like your "Enhanced" example it would be good via the radioMenu module to be able to request a status report for the ownable zones. The names of the zones could be included in a message module to provide a neat status report.

For example

The configuration of an ownedZone placed on Anapa airfield might have ownedBy# being given a value of "anapaOwner". This flag is assigned the value for the current owner (0,1, or 2). For this example lets us say that Red still hold this airfield as it was assigned at mission start, so the flag value will be 1.

The configuration of an ownedZone placed on Batumi airfield might have ownedBy# being given a value of "batumiOwner". This flag is assigned the value for the current owner (0,1, or 2). For this example lets us say that Blue hold this airfield as it was assigned at mission start, so the flag value will be 2.

If either of these zones changes hand during the mission the standard functionality will change the flag value to that of the new owner.

Using your new nesting capability for the Radio Commands (F10 / Other) we could have (for example)

• Zone Status
  • Airfields
  • Towns
    • North
    • South
    • East
    • West

If "Airfields" was selected this can trigger a message zone built by the mission designer that had the following message configuration (for example)

Airfield Status Report as at <t><n>Anapa: <vtxt: anapaOwner><n>Batumi: <vtxt: batumiOwner><n>End of Status Report

When displayed this will present to the players as

Airfield Status Report as at 10:05:00

Ananpa: Enemy in Control

Batumi: Friendly Controlled

End of Status Report

The scripting logic would mean that it would have to take the value of the anapaOwner flag (in this example 1) and do a hard coded referenced lookup to the config file for ownedByRed and get the required text back.

As stated at the start none of this may be achievable and I apologise for going into a level of detail for which is based on dangerous knowledge!

 

I hope in one way you will reply "why don't you just use....." if not I lay it at your worthy feet for due consideration.

Salute and kind regards

Friar

Edited July 4, 2024 by DD_Friar

[cfrag]

28 minutes ago, DD_Friar said:

The scripting logic would mean that it would have to take the value of the anapaOwner flag (in this example 1) and do a hard coded referenced lookup to the config file for ownedByRed and get the required text back.

Thank you for these suggestion!

Perhaps a silly question: why can't the messenger's <rsp: flagName> wildcard look-up do that? Since it will be messenger who outputs all messages, I think it could be easy to set it up as follows;

responses: free, liberated, Axis Held
message: <z: SenakiVillage> is <rsp: svOwner>

With 'SenakiVillage' an owned zone and svOwner a flag that is connected to SenakiVillage's ownedBy# output

 

Edited July 4, 2024 by cfrag

[DD_Friar]

Ha - there you are, I knew I may get "why don't you just use..."!

I had not even noticed that attribute before - hiding in plain sight.

It does exactly what I have just described.

Cheers

Friar

Edited July 4, 2024 by DD_Friar

[vgilsoler]

18 hours ago, cfrag said:

Here's minimal miz designed to test singleUse. It works on my computer as designed. Please check with your computer what results you receive, and try and go from there. This is hopefully just a small thing I overlooked in a single script.  

singe use or not.miz 141.66 kB · 0 downloads

Here it works as intended, but still not working on mine.

I attach the file. By the way the manual says the config zone should be named as cfxSSBClientConfig, but in yours it's called SSBClientConfig. I tested with both names but it didn't work. Maybe airframes limited module is interfering, I can't not see why is not working.

VG_Normandy_1Vida.miz

[cfrag]

1 hour ago, vgilsoler said:

Here it works as intended, but still not working on mine.

Thank you for sharing the mission. 

I believe I found the Issue: you are loading DML 'ONCE' (i.e. once the mission is running), not "MISSION START" (i.e. before it starts running). This means that the initial aircraft that you are occupying isn't known to SSBClient, and it will not block the slot after the first crash. It will block after the second crash, though.

 

[vgilsoler]

49 minutes ago, cfrag said:

Thank you for sharing the mission. 

I believe I found the Issue: you are loading DML 'ONCE' (i.e. once the mission is running), not "MISSION START" (i.e. before it starts running). This means that the initial aircraft that you are occupying isn't known to SSBClient, and it will not block the slot after the first crash. It will block after the second crash, though.

 

Thank you, I am going to tear out my eyes as penance.

[DD_Friar]

@cfrag

ERROR REPORT USING messenger responses

As soon as I try and trigger the message module to get a status report using <rsp  I get the below script error.

I have also attached the mission.

nullRegards

Friar

Syria_Template_V1.0.miz