DML - Mission Creation Toolbox [no Lua required]

[DD_Friar]

Many thanks, absolutely no problem. Sorry to have nudged.

[cfrag]

On 9/1/2024 at 11:00 AM, DD_Friar said:

What am I doing wrong please with the zones and parameters?

I've only taken a cursory look at the miz, and not yet found the time to test. Just out of curiosity: what are you trying to achieve by both SSB closing an airfield and using an airfield zone? If red caps an airfield, blue won't be able to use it, why do you also close it? I'm sure that there is some deeper idea behind this (prevent dynamic player spawns from that airfield?). The issue here may be that synchronizing the events can become difficult and lead to a race condition (blue capture before opening blue leaves that planes on the ground locked), and I'm not sure that the modules trigger correctly on all capture events, which may requires some sequencing (events that happen one second after each other using the sequencer module or similar).

Also, I think that having that owned zone that triggers the events inside the airfields own capture radius is asking for trouble - we now have multiple sources for cature contest with each other. Can you move the triggering owned zone outside of the airfield's 2km capture radius?

So before I go into deeper analysis: what are you trying to achieve with this construct?

Edited September 4, 2024 by cfrag

[DD_Friar]

@cfrag Thank you for finding the time to take a look. Much appreciated.

My aim is to have an airfield with locked blue slots at the start. As the mission plays out, the airfield will be hopefully captured and thus enable then enable the slots.

Red forces (AI) may launch a counter offensive and take the airfield back, thus preventing the slots from being used until the airfield is re-captured.

I added the owned zone as I was struggling with the order of the logic.

So to sum up I am trying to achieve

1. An airfield that is red at the start of mission (I am also on planning to introduce persistence so its state may be different after a save/load, so would like to take that into account)
2. The airfield should be able to have blue slots which are blocked until the airfield is captured by blue player ground forces (I would imaging deploying troops via air transport to achieve this, meaning blue player air force must take out all of the red ground units to make the area safe beforehand)
3. If Red loose the airfield they may launch a counter attack to get red ground units to take back the airfield and thus block the blue slots again.

The airfield "zone" is quite large, so is it possible to use an owned zone (which could be more focused on the centre of the airfield) as the control point for the ownership of the airfield?

From your comments I assume not?

I used SSB and slotty as I thought that was what is required?

I set the airfield to close at the start as that is what I thought I had to do to prevent blue from using the planes at that airfield?

Again many thanks for your patience and advice.

Regards

Friar

[Mistermann]

First off, I am not a scripter.  I am familiar with coding concepts, but nowhere near competent enough to write complex code.

With that in mind, I would like to establish persistence into some of my MP missions.  This would be in the spirit of DZ's Pretense and Cfrag's new Expansion mission.  In the perfect world, I'd leverage DML to manage the state of all units (air/ground/sea) on the map.  When looking at the documentation for Unit Persistence, it appears as though it doesn't support "late activated" units.  At least that's how I interpret the statement about not supporting "dynamically spawned" units.  Also, the persistence module only seems to support ground units.

Cfrag - are there any plans to broaden DML's features to support the type of persistence you have for Expansion?

[cfrag]

6 hours ago, DD_Friar said:

So to sum up I am trying to achieve

1. An airfield that is red at the start of mission (I am also on planning to introduce persistence so its state may be different after a save/load, so would like to take that into account)
2. The airfield should be able to have blue slots which are blocked until the airfield is captured by blue player ground forces (I would imaging deploying troops via air transport to achieve this, meaning blue player air force must take out all of the red ground units to make the area safe beforehand)
3. If Red loose the airfield they may launch a counter attack to get red ground units to take back the airfield and thus block the blue slots again.

I believe that your current approach may be slightly over-engineered.

To accomplish 2. and 3. you'd use ssbClient in its default state. It automatically blocks aircraft from being started from airfields that do not belong to the slotting pilot. If the airfield is captured by another faction, all slot stati are automatically re-calculated upon capture. 

Since old-school SSB requires multiplayer, you'd also add 'slotty' to enforce this for single-player. Slotty and server-based SSB cooperate nicely,

To accomplish 1 you'd probably want to use persistence and unitpersistence. You may want to allow 10 seconds to pass in mission time when the mission starts up from a save to make sure all slot blocks are in place and are enforced. 

[cfrag]

1 hour ago, Mistermann said:

When looking at the documentation for Unit Persistence, it appears as though it doesn't support "late activated" units.

There is a big difference between "late activated" units and "dynamically spawned" units. Late activated units are units that are placed with ME and therefore the mission knows about when the mission starts up, and are contained within the 'miz' file. Dynamically spawned units are units that are spawned by scripts. Persisting late activated units isn't required because they will be allocated when the mission starts up. The unitPersistence module will then proceed to remove those units that it knows were destroyed when the mission was persisted. That's quite easy. What may cause your mission headache is the fact that late activated units need to be activated, and DML does not know if a late activated group ever was activated. So a persisted late activated group may end up 'present, but inactive/invisible'. To take care of that, ensure that  you also save the state of the flags that you used to activate units. 

1 hour ago, Mistermann said:

Also, the persistence module only seems to support ground units.

It would seem that I completely failed you to properly convey what persistence and unitPersistence do, my apologies. Can you point to the relevant parts of the docs so I can revisit them and be clearer about that? Thank you so much.

1 hour ago, Mistermann said:

Cfrag - are there any plans to broaden DML's features to support the type of persistence you have for Expansion?

I'm lazy. Expansion uses 100% DML persistence, nothing else.

 

Edited September 5, 2024 by cfrag

[DD_Friar]

@cfrag I have been trying different options around what you suggested but am still unable to get this working on a mission I run as multiplayer but without server-side SSB scripts.

I have also looked at your demo mission and can see by the radio menu that sending a signal to a flag can change the ownership of SSBClient, but how do you do that in a mission?

In another test I am doing the airfield starts red as I have a red car in the zone. When I drive the car out of the zone, the airfield goes blue (because of the now unblocked slot I assume?) however I can not select that slot.

Regars

Friar

[cfrag]

31 minutes ago, DD_Friar said:

I have also looked at your demo mission and can see by the radio menu that sending a signal to a flag can change the ownership of SSBClient, but how do you do that in a mission?

Why would you want to do that? If the airfield is taken by the other faction, ssbClient handles it transparently, without having to be told. If an airfield has blue slots and red takes the field, the blue slots get blocked. That's the module's main job. There is no need to tell ssbClient anything. It just works (well, DCS tells ssbClient that the airfield was captured with an event, but I like to keep some mysique in my modules )

 

33 minutes ago, DD_Friar said:

In another test I am doing the airfield starts red as I have a red car in the zone. When I drive the car out of the zone, the airfield goes blue

Whoa. That will only happen if there are also blue ground units inside the zone. So, the miz starts up, with red owning the airfield as set by ME. All blue slots are blocked by ssbClient. By what I understand you narrate, there are red and blue units inside the airfields capture zone (2km radius). The ownership stays with what it was set to in ME (red), and although it is contested (red and blue units inside cap radius), it remains with red.

Now that you move the last red unit outside the cap radius, DCS (not DML) gives the airfield to blue, and ssbClient module notices: red slots get blocked, blue slots are opened. 

41 minutes ago, DD_Friar said:

the airfield goes blue (because of the now unblocked slot I assume?) however I can not select that slot.

Now that would be a bug. Can you send me a short miz so I can re-produce that and remove the bug.

[DD_Friar]

@cfrag Salute Sir,

After removing the airfield zone and just having the SSBClient zone at the airfield the issue I described above of the zone turning blue when the red vehicle left went away. When the red vehicle left the zone, it went neutral.

In my original question I did not have any other units in the zone. It was just the zone, a blue aircraft and a red and a blue car outside the zone.

The question about a flag was that how do I communicate to the players that the airfield has been captured. That is what I meant about being able to bang a flag. Just having the SSBClient at the airfield does not allow me to either change the colour of the zone (like airfield does) or be able to trigger messenger?

Regards

Friar

 

[DD_Friar]

Salute - OK looks like I have resolved my issue.

All it took was two modules SSBClient and baseCaptured at each location.

baseCaptured module can handle the messaging control and SSBClient blocks and releases the slots as it changes hands.

Very happy with the solution.

Thanks again @cfrag for your assistance and guidance.

[Recluse]

@cfrag  Based on @DD_Friar's comment above on having an SSBClient zone. can you comment on/confirm the use of SSBClient for general slot blocking (without using OPEN or CLOSE flags and the like). Is it sufficient to just have it loaded and running without any zones created (unless other than default config options are needed)?

 

Quote

Automatic Slot-Blocking /-Enabling on Capture Slot blocking and enabling is fully automatic. ssbClient manages all airfields and FARPs by their owning faction. If an aircraft originates from an airfield/FARP, the slot is

I have been following the advice to load slotty for SP slot blocking and have SSB running whenever I host, and advise other hosts to run it as well when a DML slot blocking mission is in use.  Maybe in this case SSBClient isn't even necessary, but doesn't hurt to run?

Quote

Note that ssbClient works best with SSB but does not require SSB. Since SSB is a server module, it needs the mission to be run in multiplayer mode on the SSB-enabled server. If you add the ‘slotty’ module to your mission, you can ensure that slot-blocking also works for single player and when SSB is not available on the server.

 

Edited September 6, 2024 by Recluse

[DD_Friar]

@Recluse This is all I have and it seems to be working (I do not have any server based scripts running, just using SSBClient, I have also added slotty.)

My testing went as follows

1. Airfield set to neutral in ME with red units in zone
2. Airfield ownership is Red. Blue slots at airfield are blocked from being taken
3. Blue units arrive at airfield - Airfield goes to contested state
4. Blue slots still blocked
5. All red units removed from airfield zone
6. Blue forces takes control
7. Blue slots become available
8. Blue units leave the zone
9. Airfield becomes neutral
10. Blue slots become blocked.
11. Red units arrive at airfield to take control.
12. Airfield goes back to red
13. Blue slots blocked.

null

Edited September 6, 2024 by DD_Friar

[cfrag]

46 minutes ago, Recluse said:

can you comment on/confirm the use of SSBClient for general slot blocking (without using OPEN or CLOSE flags and the like). Is it sufficient to just have it loaded and running without any zones created

Thank you for asking - it looks like I really have to rework some passages of the manual. Here's the excerpt from the relevant chapter in the manual:

 

5.4.10.1 Description
ssbClient provides automatic slot blocking for aircraft that

• have their starting location on an airfield/FARP that currently belongs to the enemy (optionally neutral as well). This is a dynamic feature, and when an airfield is captured, the aircrafts based there change availability (free or blocked)
• are on an airfield that is “closed”. ssbClient provides DML watchflags/Zones (and a script API) to open/close airfields
• (optionally) aircraft that have crashed (a ‘single-use’ feature to prevent crashed aircraft to be re-used). This option provides a “re-use after” feature to allow access to the crashed aircraft slot after some time (to simulate replacement). Note that the module ssbSingleUse provides a better, more flexible support for this.

Note that a mission that enables the “single use” feature requires that the host first disables SSB’s automatic “kickReset” option.

Any player group that you wish to be blocked from spawning until the airfield belongs to the correct side must have the group's first player unit placed on the ground (i.e. "Take off" with one the following: "From Runway",  "From Parking Area", "From Parking Area Hot", "From Ground Area", "From Ground Area Hot") within 3000m of the airfield's/FARP's center. For this reason, I recommend that you only use single-unit groups with player (client) planes.

Automatic Slot-Blocking /-Enabling on Capture
Slot blocking and enabling is fully automatic. ssbClient manages all airfields and FARPs by their owning faction. If an aircraft originates from an airfield/FARP, the slot is

• blocked if the airfield does not belong to the same faction
• enabled if the airfield belongs to the same faction
• you can allow neutral fields to count as allied to both sides (using the allowNeutralFields attribute in the config zone). In that case all aircraft on neutral airfields are enabled. If a neutral airfield is captured by either side, the other side loses access to that airfield

If a slot is blocked, a player can no longer use that slot from the change role dialog.

 

I'll see if I can phrase that better in the next release. 

 

[DD_Friar]

Just posting this answer has made me realize that the logic in mission will now need to be updated. I had the random red aircraft selector based on blue units flying into zones, but if Aleppo gets captured I now need to re-configure those zones to remove Aleppo from the available list as I assume(?) that the clone will want to work if triggered even if red do not own the airfield?

[cfrag]

57 minutes ago, Recluse said:

I have been following the advice to load slotty for SP slot blocking and have SSB running whenever I host, and advise other hosts to run it as well when a DML slot blocking mission is in use.  Maybe in this case SSBClient isn't even necessary, but doesn't hurt to run?

That is correct: SSB on the server implements the slot blocking, but only for multiplayer because it is server-bound. Slotty implements it (by kicking you an instant after sitting down in the cockpit) even in single-player, and also multiplayer if SSB isn't present on the server. Slotty and SSB (server) like each other and compliment each other. ssbClient provides the required logic that tells ssb and slotty whom and whom not to block.

12 minutes ago, DD_Friar said:

• Blue units leave the zone
• Airfield becomes neutral

This only happens if you have another module added to the mix. By DCS standard rules, an airfield stays with the last faction even if all units leave and no other faction units are near.

[Recluse]

@cfrag  Thanks.. I did quote the manual in my post    It was clear to me as is, but I was confused when @DD_Friar mentioned SSBClient Zones, and then I read further in the manual and saw they were available for use.  I was keying on the part that said SSBClient did basic slot blocking AUTOMATICALLY.

[DD_Friar]

Salute wise people of DML Land - let us put our heads together..

My scenario, pilots in my mission can take-off from one of 3 locations. Their flights will take them through a trigger unitZone (Zone 1, Zone 2, Zone 3).

That unitZone triggers a rndFlag module to pick from a list of airfields. Different rndflag modules have a different selection of airfields. Once an airfield is picked another rndFlag is triggered at the selected airfield to pick a flight from that airfield (random departure points for enemy AI and random flights from that airfield).

My issue is now I am planning this mission to be on going and have "persistence".

How can I configure my random airfield selector if one or more of the airfields now belongs to blue and is no longer a valid red departure point?

Hmm.......

Perhaps zones being turned on and off based on airfield status'...

17 minutes ago, cfrag said:

This only happens if you have another module added to the mix. By DCS standard rules, an airfield stays with the last faction even if all units leave and no other faction units are near.

I feel reasonably confident that my testing sequence provided the results I described. (willing to wager at least 50 cents/pence). There were no other modules at the airfield.

[Recluse]

1 minute ago, DD_Friar said:

Salute wise people of DML Land - let us put our heads together..

My scenario, pilots in my mission can take-off from one of 3 locations. Their flights will take them through a trigger unitZone (Zone 1, Zone 2, Zone 3).

That unitZone triggers a rndFlag module to pick from a list of airfields. Different rndflag modules have a different selection of airfields. Once an airfield is picked another rndFlag is triggered at the selected airfield to pick a flight from that airfield (random departure points for enemy AI and random flights from that airfield).

My issue is now I am planning this mission to be on going and have "persistence".

How can I configure my random airfield selector if one or more of the airfields now belongs to blue and is no longer a valid red departure point?

Hmm.......

Perhaps zones being turned on and off based on airfield status'...

Have to think about it, but off the top of my head, i think there is always an ownedBy or similar flag that has a value based on the Ownership?  (RED, BLUE, NEUTRAL) some combination of the ownedby flag value and a list of the "random" selections might work. Could be a lot of work to account for every possiblity... but maybe there is a way to do the randomization more elegantly only when only those bases with an ownedBy with an instantaneous certain value are considered.

 

One example from the manual picked at ....errrrr....RANDOM 

Quote

“senakiOwner” is controlled by the airfield output ownedBy#, a ‘live output’ that always copies the current owning faction number (0 = neutral, 1 = red, 2 = blue) to the attached flag. The trick here is that since the cloner triggers on change, the live output is ignored when it’s the same value as before, but whenever the value changes to a different calue, the cloner triggers a clone cycle.

 

[AKA_Clutter]

On 9/5/2024 at 7:58 AM, cfrag said:

... ...

I'm lazy. Expansion uses 100% DML persistence, nothing else.

 

 

ROFLMAO  - everyone knows better.

[cfrag]

18 minutes ago, DD_Friar said:

My scenario, pilots in my mission can take-off from one of 3 locations. Their flights will take them through a trigger unitZone (Zone 1, Zone 2, Zone 3).

That unitZone triggers a rndFlag module to pick from a list of airfields.

This is awfully complex, I believe you are overthinking this. Is there perhaps a simpler way to describe what you are trying to achieve? It sounds as if what you are trying to do is pick a random flight based on from where a player unit originates. Using a Valet zone can probably take care of that, right when the player slots in, triggering an RND to choose from a list of enemy flights.

23 minutes ago, DD_Friar said:

Different rndflag modules have a different selection of airfields. Once an airfield is picked another rndFlag is triggered at the selected airfield to pick a flight from that airfield (random departure points for enemy AI and random flights from that airfield)

Methinks that can be simplified to a single RND per airfield, activated by the valet.

25 minutes ago, DD_Friar said:

My issue is now I am planning this mission to be on going and have "persistence".

What do you want persisted? To me it feels as if I do not fully understand what you try to achieve with this mission. What is the central thread or essence of the mission? What defines it, allows you to tell at a glance where it has progressed to? I think things will become much easier once that we have worked that out. 

 

[Mistermann]

Thanks for taking the time to respond, Cfrag!  Really appreciate it.

On 9/5/2024 at 10:58 AM, cfrag said:

There is a big difference between "late activated" units and "dynamically spawned" units. Late activated units are units that are placed with ME and therefore the mission knows about when the mission starts up, and are contained within the 'miz' file. Dynamically spawned units are units that are spawned by scripts. Persisting late activated units isn't required because they will be allocated when the mission starts up. The unitPersistence module will then proceed to remove those units that it knows were destroyed when the mission was persisted. That's quite easy. What may cause your mission headache is the fact that late activated units need to be activated, and DML does not know if a late activated group ever was activated. So a persisted late activated group may end up 'present, but inactive/invisible'. To take care of that, ensure that  you also save the state of the flags that you used to activate units. 

Makes sense.  

On 9/5/2024 at 10:58 AM, cfrag said:

It would seem that I completely failed you to properly convey what persistence and unitPersistence do, my apologies. Can you point to the relevant parts of the docs so I can revisit them and be clearer about that? Thank you so much.

No worries.  I had a long flight earlier last week and spent time going through your DML quick reference guide.  Thanks for all the time/energy you spent making these resources.  I'll quote the section that confused me below:

I figured you specifically used the term "ground units" instead of just saying "units".  I also looked at the demo mission and I believe it only used ground units which further led me to believe there was something specific about your choice of words.  

On 9/5/2024 at 10:58 AM, cfrag said:

I'm lazy. Expansion uses 100% DML persistence, nothing else.

That is REALLY great to hear (not the lazy part ... ).  I have a Vietnam (Marianas) mission I host for my buddies that has random spawns in it (late activation).  It probably takes 10 hours to clear the mission so we've never actually left it running that long to "finish" it.  Having persistence allows us to start/stop whenever we want and pick things back up.  I'll experiment with DML to see how I can introduce persistence to that mission - THANKS!!

Lastly... will the warehouse data persist across saves?  As logistics starts to play a larger role in DCS, I'd like to introduce some level of ordinance replenishment using the CH-47 and later on other platforms that support this gameplay.  I suspect you'll need to update DML to account for logistics warehouses.  What are your thoughts on this?

Thanks again, Cfrag.

Edited September 6, 2024 by Mistermann

[DD_Friar]

1 hour ago, cfrag said:

Methinks that can be simplified to a single RND per airfield, activated by the valet.

You have got me thinking about a single list of possible flights (from all applicable departure airfields) as an option. At the moment the rndFlag at the airfield uses remove true and reshuffle true and a pollSize of 1. I did not want the possibility of the same flight getting selected twice and it clone whilst the previous clone had not had a chance to move out from its taxi point.

By having a single long list of flights it would mean that EVERY flight would have to be selected before resetting the list, not the worst scenario.

By having the triggers based on zones entered on route rather than on spawn (I did originally have the trigger zone at the airfield at a pinch point on the taxi-way) helped with flight times of the ai to the "combat zone / area of operations".

If I go with zones I can use the ability to turn check zones on and off. The order in which we capture the red airfields could be planned ahead so I can manage which airfields are available as valid red departure airfields (for example the battle plan is to capture airfield A followed by B then C etc as we work our way down the Syria map. So when A is taken I turn off the first check zone that said pick from a, b and c. the capture of a as well as turning off check zone 1 can enable check zone 2 which has b,c and d as valid red departure points / flights.

This post has perhaps strayed into me thinking out loud but I hope it can be useful to other mission builders to give them ideas of scenario building.

Cheers

Friar

[cfrag]

12 hours ago, Mistermann said:

I figured you specifically used the term "ground units" instead of just saying "units". 

Ha! I knew there was something off in the docs. Thanks, I will try and make that passage more clear

 

12 hours ago, Mistermann said:

Having persistence allows us to start/stop whenever we want and pick things back up. 

In theory, yes. In DCS, however, persistence is a far cry from that, and you need to design the entire mission around that 'sorta-like persistence' concept that DML is struggling to offer: Ground vehicles reset to the spot that they were persisted, but immediately ruin into issues if they have more than 2 waypoints - because the are heading to the second waypoint (that's the way DCS works, no way around it). Late activated units - well, you must make sure that you preserve the flags that trigger them, or use cloners instead. Aircraft - well, let's just say that there are reasons why I used such a peculiar phrasing in the docs: if you persist ME-placed aircraft, after loading a persisted unit, remember that time is reset to zero (no way for scripts to change that), and that aircraft start at their initial point, so DML persistence isn't helping much here - it's a crutch that may help a liiiitle bit to tide us over. That being said, I have very little faith in ED's ability in bringing us "true" persistence where you can save a mission at one point, and continue it later like in other games. If they do (and I sincerely hope that they do), I find it highly unlikely that these missions will be backward compatible with what we have now. But I digress. Unfortunately, you need to design your mission with DML's persistence limitations in mind, and if you do that, you can enjoy a modicum of continuity after you save and restart the mission. Those missions still can be fun because - DCS  

[DD_Friar]

25 minutes ago, cfrag said:

Ground vehicles reset to the spot that they were persisted, but immediately ruin into issues if they have more than 2 waypoints - because the are heading to the second waypoint

As previously stated I am just building up my squads main server mission to eventually have persistence running meaning that we should be able to save the evenings achievements at the end of one session and then pick-up in the next session.

ref ground units and way points.  Are you able to clarify "2nd Way point" Is the starting point the first way point? 

Is it actually like you say and WP 2 is the end point or is WP 1 the "2nd" WP? effectively meaning ground units, if I am to use Persistence satisfactorily must only have a start and and end (as per my second example below)

nullnull

[cfrag]

45 minutes ago, DD_Friar said:

Are you able to clarify "2nd Way point" Is the starting point the first way point? 

Unfortunately, DCS is very inconsistent with this, so I'll try to be more clear about this:

When you place units on the ground, that defines their first waypoint. It is also sometimes called "Initial Point", waypoint 0, or (since Lua starts counting with "1") waypoint 1. This will cause confusion. I call the initial waypoint "Waypoint 1" because I look at groups from a scripting perspective, and it is always designated Waypoint One in the miz itself (for the simple reason that Lua starts counting indices at 1, not 0). So, the Initial Point, the point where a group poofs into existence is "Waypoint 1" to me. In ME, it will be called "0", which is really, really unfortunate as we'll see.

If you then add a waypoint to tell the group to go somewhere, you add a point to the Initial Waypoint. Unfortunately, in ME this new point, being the last in the route, is unhelpfully called "Waypoint 1 of 2". On the Map they are numbered "0" and "1". Witness a masterclass in bad UX:

Normal people start counting with 1, not 0 -- starting with 0 is a typical coder thing, especially C coders; forcing your customers to adopt your way of seeing the world is a classic Ux blunder that was common in the mid-70s to early 90s of the last century. More baffling is that Lua (which starts counting with 1) also internally numbers waypoints starting with 1. Here is the route of two waypoints as it is written inside the miz:

["points"] = {
	[1] = {
		["y"] = 644480.31803998,
		["x"] = -282677.0446673,
		...
		}, -- end of [1]
	[2] = {
		["y"] = 645178.98325343,
		["x"] = -282234.55669878,
		...
  		}, -- end of [2]
}, -- end of ["points"]

So, it's a complete mess, and I'm not helping. When I say "Waypoint 2" I mean the second point in the list, which is the first point that you added after putting down the group, and that is called "waypoint 1 of 2" if there are only two waypoints in the list. The point after the initial point. The point called "2" in the Miz.

 

Edited September 7, 2024 by cfrag