DML - Mission Creation Toolbox [no Lua required]

[DD_Friar]

Solution found - I just use a convoy with a condition on the hold. This way if the town is captured the convoy must have been killed to complete the capture condition. If the town is still red the convoy will still be intact so can run.

[mimamema]

Hello! I´m back here with another WilliePete bug to give you more work , probably introduced with the latest update from ED. Here I have attached the log and a screenshot of the error window.  Let me know if I need to test anything as I actually was not present playing when it happened. 

null

dcs.log

[cfrag]

9 hours ago, mimamema said:

probably introduced with the latest update from ED.

Indeed, it seems as if the 7-11 update did introduce a veritable smorgasbord of 'features' that I'm now trying to iron out. Thanks for alerting me to this one. I'm on it.

Edited July 14, 2024 by cfrag

[cfrag]

ANNOUNCEMENT: DML DEVELOPMENT ON HOLD

Dear all, 

the last DCS release from July 11 brought a host of changes. Some of them wanted, some not so much. Since there is very little information for script authors available, it is difficult to know which change was intended, which changes are coming, and which changes are plain bugs. The sheer amount of issues, coupled with no information about whether I'm dealing with a new feature or a bug, has led me to take a defensive approach: Wait and See. Instead of trying to maintain some 100 modules to be bug-compatible and chase mirages, I'll wait a bit until the dust settles. And there is a lot of dust in the air, a good third of all DML modules would need updates if the situation stays as it is -- a rather big task. If it turns out that these were merely bugs that went unnoticed during QA, so much the better.

There's likely not going to be an update to DML this week, and many of the missions that use DML and now are broken (Expansion, Ceasar, all Angels, Dustblower, Hover Damn, any mission that uses HeloTroops, csarManager, or autoCSAR) may miraculously start working again with the next patch, so there is little sense for me to try and fix things that are going to be straightened out by the kind people at ED. 

This may give me time to ponder new, exciting modules. In the meantime, I thank you for your kind understanding, encouragement and support.

Cheers,

-ch

[Chess96]

On 7/15/2024 at 12:34 PM, cfrag said:

ANNOUNCEMENT: DML DEVELOPMENT ON HOLD

Dear all, 

the last DCS release from July 11 brought a host of changes. Some of them wanted, some not so much. Since there is very little information for script authors available, it is difficult to know which change was intended, which changes are coming, and which changes are plain bugs. The sheer amount of issues, coupled with no information about whether I'm dealing with a new feature or a bug, has led me to take a defensive approach: Wait and See. Instead of trying to maintain some 100 modules to be bug-compatible and chase mirages, I'll wait a bit until the dust settles. And there is a lot of dust in the air, a good third of all DML modules would need updates if the situation stays as it is -- a rather big task. If it turns out that these were merely bugs that went unnoticed during QA, so much the better.

There's likely not going to be an update to DML this week, and many of the missions that use DML and now are broken (Expansion, Ceasar, all Angels, Dustblower, Hover Damn, any mission that uses HeloTroops, csarManager, or autoCSAR) may miraculously start working again with the next patch, so there is little sense for me to try and fix things that are going to be straightened out by the kind people at ED. 

This may give me time to ponder new, exciting modules. In the meantime, I thank you for your kind understanding, encouragement and support.

Cheers,

-ch

Hi cfrag !

This is completely understandable and the best way to deal with this new DCS update indeed. 

I guess this is just really bad timing on my part then, but I had a question regarding IADS, I was wondering if you were working or even planing on developing an IADS module to add to DML ? 

I know that right now everything is most likely on hold but this was just something I was wondering about already before the ED update. 

Cheers,

[Karlos]

Hi cfrag, what do you think of the new interface with the coalitions to choose from?

Since Lock On we have seen both coalitions, why change?

For me you put the users, the mission developers, and the administrators of the various servers in difficulty.

Not having the possibility to see both the red and blue coalition at the same time is catastrophic for me, having a PVP server.

[cfrag]

On 7/16/2024 at 5:53 PM, Karlos said:

what do you think of the new interface with the coalitions to choose from?

I’m not sure that I know what you are talking about. Do you mean the new interface in multiplayer that now comes up to choose which coalition before it proceeds to the slot selection? I find it clumsy and convoluted, but that’s just my personal impression 

On 7/16/2024 at 5:53 PM, Karlos said:

you put the users, the mission developers, and the administrators of the various servers in difficulty.

I hope that there was something lost in translation here. How did I do that? It certainly wasn’t intentional. 

[Karlos]

42 minuti fa, cfrag ha scritto:

I’m not sure that I know what you are talking about. Do you mean the new interface in multiplayer that now comes up to choose which coalition before it proceeds to the slot selection? I find it clumsy and convoluted, but that’s just my personal impression 

I meant that

42 minuti fa, cfrag ha scritto:

I hope that there was something lost in translation here. How did I do that? It certainly wasn’t intentional. 

I apologize, it wasn't aimed at you obviously.

 

The fact of not being able to see the two coalitions, the red one and the blue one, at the same time, brings confusion to users, server administrators, especially PVP servers.

Edited July 17, 2024 by Karlos

[CidTheViking]

Hello CFRAG,

Again Id like to thank you for you effort in this. While I was working with your Spawner/Factory modules I was thinking about the MOOSE Framework and I think they found a way to include a better path finding algorithm. ( https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Astar.html ). Do you think something like this could be included somehow to make these zones make better decisions on how to make their way to capture zones. Or maybe the commander module? I do understand that you are on hold until the next patch due to the current state of DCS but just wanted to ask questions and maybe bring some ideas to you.
 

Thank you again.

[cfrag]

41 minutes ago, CidTheViking said:

I think they found a way to include a better path finding algorithm.

Thank you for the interesting link. I have no experience with how this works in Moose, and I hope that it works well. But from my own experiences with pathing algorithms, they require a navigation mesh, an underlying graph of sorts that the algorithm uses to determine how it get from one point ("node") to another. In other works, in order to be able to use this new pathing, you must first create a graph (for example with trigger zones) that tell units how they can move from node to node. You can't automatically generate this graph from the mission map, you, the mission designer must provide it by hand, a ton of work just to create. So, mission designers must provide this individually for each mission, and once provided, units can only move between points (nodes) of the graph that you defined.

While that initially sounds not that bad, unit movement between nodes in the graph is still done by DCS's quite underwhelming pathing. A* pathing is awesome, fun and state of the art -- and I have done some of my own implementations (back when I was playing Elite Dangerous and needed a way to plot good routes between star systems). In this case, the foundation is rotten. It can at best (and after expending great effort) put some lipstick on a pig. I feel that ED should solve the issue at the root. Just by looking at how DCS handles airport ground traffic (which would be a poster child for A* path finding, as there are only a few nodes per airfield) we can tell that DCS urgently needs better pathing, and no matter how great a solution we build on the existing foundation, it will suck until the foundation improves. Or, to put it less negatively: I can't imagine a workable, good pathfinding helper that is easy to use (in DML context), performs well (paths have to be re-calculated dynamically) based on current DCS pathfinding. Remember that for any such module, it is dependent on the quality of the node graph that you, the mission designer, puts down for the mission. Meaning that you will first have to put down some trigger zones as nodes (lets say 50-100 trigger zones), and then connect each zone using attributes to other nodes (creating a graph or a few thousand connections between the nodes) that the units than can traverse node-to-node with DCS's pathing. A nightmare to imagine, far worse to debug and service. I'm not at all eager to try this.

Edited July 18, 2024 by cfrag

[CidTheViking]

I see, thank you for the insight.

Im still learning all this stuff. DML is quite step forward for mission creators IMHO. We can only hope that ED will one day fix some of the underlying issues we all face. The more I try to make mission the more I see needs updating or fixing.

Thank you again.

Edited July 18, 2024 by CidTheViking

[DD_Friar]

@cfrag If there is some way I could contribute back with path finding on maps that would help you I would be happy to discuss this further.

[cfrag]

1 hour ago, DD_Friar said:

If there is some way I could contribute back with path finding on maps that would help you I would be happy to discuss this further.

That is very kind of you, @DD_Friar, thank you so much. A few moons ago, I contemplated a 'busyBee' module to provide some randomized ground traffic for airfields. Unit movement was to be made on a nav mesh graph made from nodes, with connectors between the nodes, all with trigger zones. For Senaki Kolkhi, a super-simple nav mesh covering only the taxiways would require 22 Nodes, and some 70 connectors between the nodes. Just to provide some ground traffic on that small, one-runway airfield. This node mesh can't be transported to another airfield, you'd have to craft one for each airfield, for each map. This also means that such a nav mesh can't be imported to an existing miz, it has to be created on the map, and once done, can't be updated.

Looking outwards, to provide some eye-candy traffic on all 21 airfields in Caucasus, we'd be looking at 500 nodes (trigger zones) and some 2000 connectors (trigger zone attributes). This number will skyrocket exponentially if we wanted to provide a simple, basic nav mesh that connects the 1700 named locations (nodes) in Caucasus (requires some 4000-12000 connections). Setting this up is a nightmare that should be done much simpler automatically by the map vendor. Traversing the grid, even when using A* in Lua is going to kill performance outright. That is why until they are provided by the map vendor, custom nav meshes only make sense on a mission-individual basis where you know where the action is going to be, and by laying out the nav mesh you also dictate where units can, and cannot go. Gain/Effort seems to be very close to zero.

Edited July 18, 2024 by cfrag

[DD_Friar]

DML TOP TIP (well I think so  )

Module: Messenger

When using the messenger module to display complex messages using the format wildcards I have found that you can build the message text in notepad and then paste it in to the field rather than using things like <n> for new lines.

See screen shots as examples

[Recluse]

@cfrag  You have bigger issues with the landing stuff, but just reporting a minor thing which may be "correct as is":

 

I used the bombRange module in a recent mission, and it WORKED, but I noticed that unlike the other modules, there is no report on startup that it loaded.

That was the minor thing.

 

I did get an error that I think was related to destruction of a target within the Bomb Range Zone (which overlapped with a cloneZone) but I will make a detailed report if/when it occurs again.

But it brings up a question:  The scenario I have is a cloneZone with some targets that are set to repopulate when empty.  I have a bombRange overlaying it (circular) to report impact from center as well as any hits on targets.  I was thinking that maybe only a single zone could serve both purposes but wasn't sure if  could  mix a cloner and bombRange descriptor on a single zone.

 

On another issue entirely:  Does slotty work with noGap (or is there an equivalent that can run in the mission), or is the noGapGui required for MP?

Edited July 23, 2024 by Recluse

[cfrag]

17 hours ago, Recluse said:

there is no report on startup that it loaded.

huh. Indeed. Fixed  -- thank you. 

17 hours ago, Recluse said:

I will make a detailed report if/when it occurs again.

Please do that, and I'll try and get to the bottom of that.

17 hours ago, Recluse said:

wasn't sure if  could  mix a cloner and bombRange descriptor on a single zone.

They work well together. Maybe you'll find it helpful to also look at "Marianas Proving Grounds" that uses cloners with  bomb ranges on the same trigger zone.

17 hours ago, Recluse said:

Does slotty work with noGap (or is there an equivalent that can run in the mission), or is the noGapGui required for MP?

The two are not related. slotty will prevent aircraft from spawning. noGap puts static aircraft in player slots. noGapGUI works around a DCS synchronization bug in multiplayer. So if you use noGap, I strongly recommend that you use noGapGUI on the server, independent of slot any blocking. I also recommend that you use stopGap instead of noGap, as stopGap receives more support than noGap (the squeaky wheel gets the oil, and stopGap is far more popular than noGap)

 

[Recluse]

Thank you for your detailed and informative responses (as always!)

I will check out Marianas Proving Grounds (I have it, just never looked at it in the Mission Editor!!).

For my stopGap vs. noGap question: It is in the context of a very simple mission I want to fly with a friend to test out various airframes, with eye candy for the unused aircraft showing on the Tarmac.  All airframes are 2-ships, so  in the event that we fly different aircraft, I wanted our respective AI wingmen to be visible for atmosphere.  No Slot Blocking needed, or any other complexity that StopGap provides over noGAP.  Will use noGapGui.  Point taken that StopGap will be better for any more complex MP interaction.

 

[DD_Friar]

@Recluse

Apologies if you already know this...

TIP: When building a mission using stopgap you have to place the planes as single units for it to work.

For example do not add a plane and make it 1 of 4 for example. You need to place each of the 4 units as separate planes (1 of 1)

[cfrag]

1 hour ago, DD_Friar said:

You need to place each of the 4 units as separate planes (1 of 1)

I believe that the the reason why @Recluse has decided to use noGap instead of stopGap. noGap is specialized to support multi-ship player groups. Not well, but it does support that.

[Recluse]

2 hours ago, cfrag said:

I believe that the the reason why @Recluse has decided to use noGap instead of stopGap. noGap is specialized to support multi-ship player groups. Not well, but it does support that.

100% CORRECT!!  I initially used STOPGAP but couldn't see the static representation of my wingman when I entered an aircraft. Since it was all about the EYE CANDY I went with noGap.

Made this mission for me and a friend to practice with some of the FC aircraft. Mainly Flankers (SU-27 and SU-33),  but I threw in F-15C and F-5E as well. Since we will PROBABLY fly in two ships of the same aircraft, it wasn't a big deal, and I probably could have just as easily made each aircraft 1/1 in this particular case with no downside but maybe we would try dissimilar aircraft and then the Eye Candy wingman would be visible.

 

  I tend to like to make Groups for Multiplayer because it confers some advantages  e.g. for F/A-18 Hornet datalinks, it is easier to have everyone in the same group to automatically enable it though it can be established via onboard systems for aircraft outside the group.

Edited July 23, 2024 by Recluse

[Recluse]

7 hours ago, cfrag said:

 

The two are not related. slotty will prevent aircraft from spawning. noGap puts static aircraft in player slots. noGapGUI works around a DCS synchronization bug in multiplayer. So if you use noGap, I strongly recommend that you use noGapGUI on the server, independent of slot any blocking. I also recommend that you use stopGap instead of noGap, as stopGap receives more support than noGap (the squeaky wheel gets the oil, and stopGap is far more popular than noGap)

 

OK, I guess I misunderstood this:

Quote

Instead of installing stopGapGUI on the server, you can choose to add the ‘slotty’ module to your mission. This removes the requirement to install stopGapGUI on the server, and still allows server admins to install stopGapGUI – slotty and stopGapGUI cooperate nice

I thought slotty was performing some of the actions of stopGapGui

[cfrag]

10 hours ago, Recluse said:

OK, I guess I misunderstood this:

Uh, I guess that happens when you ask your friend for an Americano, and she mixes you a Negroni instead because she thinks you're a bit dull today  

That should have (and now does) read:
 

Quote

Instead of installing SSB on the server, you can choose to add the ‘slotty’ module to your mission. This removes the requirement to install SSB on the server, yet still allows server admins to install SSB – slotty and SSB cooperate nicely.

Thanks!

[Recluse]

On 7/23/2024 at 8:22 AM, cfrag said:

On 7/22/2024 at 2:38 PM, Recluse said:

I will make a detailed report if/when it occurs again.

Please do that, and I'll try and get to the bottom of that.

As promised here is the error.  I can reproduce it by killing a target within the BombRange zone. It registers hits fine, but if the target is actually destroyed, it throws this error. The error popped up twice, once when I destroyed a target and once when a badly damaged target cooked off.. so I am pretty sure it doesn't like it when I target it registers disappears.  It is also a clone zone so that when all the targets are destroyed, the empty! flag hits the clone? flag, so that may cause issues too, but there was a similar setup that you pointed me to in your Marianas Sandbox.

I can work around it, but thought you would want to know, and maybe it is "CORRECT AS IS" 

 

 

Edited July 25, 2024 by Recluse

[cfrag]

4 hours ago, Recluse said:

As promised here is the error. 

Thank you so much for tracking this one down. It is caused by one of the (too many) issues introduced into DCS by their July-11 patch, and I am defending against it, but the code is becoming rapidly unwieldly and difficult to maintain - which is the main reason that I've decided to take a wait-and-see approach. The new version of bombRange does (hopefully) defend against this DCS bug, but since we can no longer trust the data that a world event passes back as intact (the weapon object passed back by the event can no longer exist, which leads to this particular error), developing smart scripts for DCS is rapidly becoming untenable. 

Let's hope that the kind people at ED get to the bottom of these many failures and remove the root cause. It could be a simple timing issue (i.e. a race condition between deallocating an exploding weapon and invoking the event)

[ClausHoffmann]

@cfrag Sorry for bothering you on the topic again, but I am slightly confused about the status of the TDZ module. EDs big patch broke the module. But in my understanding the patch of the patch did solve the issue for all planes but helicopters. I am working on a mission that includes this TDZ module and it does not work for me with jets. Is this function now completely broken or only for helicopters and I get something wrong.A clarifcation would be highly apreciated.