DML - Mission Creation Toolbox [no Lua required]

[Priest]

I can work with "mysterious" knowing I'm not going crazy is helpful thanks guys.

[cfrag]

2 hours ago, vgilsoler said:

Able to reproduce error again without WW2 asset pack

Inconceivable!

(and yeah, I think I know it means what I think it means...)

Let's try and forget this little coding mishap:

 

impostors.lua

Edited October 12, 2024 by cfrag

[vgilsoler]

2 hours ago, cfrag said:

Inconceivable!

(and yeah, I think I know it means what I think it means...)

Let's try and forget this little coding mishap:

 

impostors.lua 19.75 kB · 2 downloads

 

The issue seems to be solved both using and not using WW2 assets pack.

Thanks again.

Edited October 12, 2024 by vgilsoler

[Recluse]

I am trying to track down some errors with NoGap.  I am not sure it is a NOGAP error, or a DCS error...or a missing static model somewhere..

 

Here is what happened to the best of my recollection:  I was playing with the Mig-15bis FC and F-86F FC.   I have a mission with NoGAP, and also with Dynamic Spawns, so I loaded up the mission as a Server Mission and tried to place a Mig-15bis FC.  DCS threw a bunch of popup errors about not finding the Static Model. The error kept popping up and I could not clear it.  I had noGap loaded using DO SCRIPT FILE (with an older version), so before trying again to capture the error, I copied the contents of the latest noGap into DO SCRIPT.  When I tried again, I didn't get the popup error messages, but I did get the following messages on the DCS screen. Same error came up when trying to spawn the F-86F FC.

I then edited the mission and manually placed 2 F-86F FC and 2 Mig-21Bis FC on the tarmac as START FROM GROUND HOT. Starting in Single Player, they spawned fine, and I could see the Static Wingman next to each aircraft. 

I restarted the mission on a server, did a Dynamic Spawn of the Mig-21bis FC, and everything was fine.  Then I did s SELECT ROLE and did a dynamic spawn of an F-86F FC, and the similar messages to the ones below popped up again about the Mig-15bis.

So it seems that sometimes the error occurs, sometimes it doesn't but always seems to happen on a Dynamic Spawn, and usually after doing ONE Dynamic Spawn, then Selecting a new Role as another Dynamic Spawn.  ONLY seems to happen with the F-86F and Mig-15bis FC.  I can spawn other aircraft with no errors.

 

(as described previously, I am using noGap vs. stopGap because I usually manually place pairs of client aircraft for possible multiplayer use, and I like seeing my Wingman next to me even when I am playing in SP. )

 

Edited October 15, 2024 by Recluse

[cfrag]

NoGap hasn’t been updated yet to support dynamic spawning. The error happens when you leave a dynamically spawned aircraft, and noGap looks at the Miz’s defined player aircraft to determine what static aircraft to place, and where.

[Recluse]

7 hours ago, cfrag said:

NoGap hasn’t been updated yet to support dynamic spawning. The error happens when you leave a dynamically spawned aircraft, and noGap looks at the Miz’s defined player aircraft to determine what static aircraft to place, and where.

OK thanks!! It didn't seem to trigger for anything but the Sabre and the Mig, but I didn't extensively test, but I probably had most of the other aircraft types placed in the .miz for the other attempted spawns.

Edited October 15, 2024 by Recluse

[DD_Friar]

Salute Guys,

Advice/suggestions Please

Does anyone have a mechanic I can use to prevent a cloner firing if the airfield is a different allegiance?

My scenario is I have a number of airfields that start red and have for example Mig21's that are cloned in by various triggers. The airfield can be captured in which case the spawns should no longer fire. I feel I am faced with having multiple tests of some kind equivalent to if <airfield=red> then clone else do not clone (that's not code, just me putting it into words)

I have just tried to see what happens if I have a blue airfield and a red helicopter triggered to spawn in, it spawned in with no issue.

I read a bit about master owner but that seems to be for airfields with stock that can change hands when captured. In my scenario the Migs should no longer appear.

 

 

[cfrag]

36 minutes ago, DD_Friar said:

Does anyone have a mechanic I can use to prevent a cloner firing if the airfield is a different allegiance?

Ha! Welcome to advanced trigger transmogrifation!

36 minutes ago, DD_Friar said:

I feel I am faced with having multiple tests of some kind equivalent to if <airfield=red> then clone else do not clone (that's not code, just me putting it into words)

So you already know the answer, just not which DML "bricks" to use. Let me point you into the right direction: 

What you are looking for is (in old-school TTL electronics) a 'gate' - something that lets a signal through when one condition is met, and prevents it from passing through otherwise. 

Have a look at the second use case for the 'changer' module. So when the airfield belongs to red, the gate opens, and otherwise it closes. Connect the triggeing flag to the changers change? input and then changeOut! to the cloner's clone? input. The triggering signal will only propagate if the gate is open.

But how do you tell the gate to open/close? That's a job for the first use case for a changer. Use another changer to create a direct signal to the first changer (the one that functions as a gate) and connect it to the "on/Off?" gate input.

And get the current airfield's owner (perhaps from an airfield's ownedBy# attribute and use the 'bool' conversion to match the "=1" trigger method.

So you will be using two changers to process/gate the incoming cloner signal.

If you can't get it to work, we can hit it over the head until it does.

Edited October 19, 2024 by cfrag

[DD_Friar]

@cfrag - Thanks for the heads up on this module. This is one I had not looked at before.

I understand logic gates boolean etc so ok there.

I have had a quick look at the guide and the demo mission but feel it needs a fresher head in the morning to understand how to use it...

I will report back.....

Salute

Friar

 

 

 

 

 

 

[Slippa]

Well I think those trains look pretty good myself. Good job Waterman.

Come on ED, help sort them out so we can all enjoy em. 

[vgilsoler]

Hi,

Looking for help again.

I'm trying to remove a cloned air formation wih wiper when they reach a zone in the map.

But It seems wiper is not able to detect the formation as unit (cat=1) I tested with B17 (WW2 assets pack) and A20G (non WW2 AP)

nullnullAny advise?

Regards,

 

 

Jueves_Negro_v1_debug.miz

[Chad Vader]

Hey cfrag.

How are you I hope all is well.

I have a question about dml clone zones and ctld jtac function.  Do they operate together? I have created a clone zone in my mission and I have a unit coming in late when a flag is passed into the zone.  However this unit is also referenced as a jtac in a ctld do script action.  The unit isn't recognised by ctld and I get no active jtacs.  Have you tried to do this before? Thanks

Edited October 22, 2024 by Chad Vader

[cfrag]

4 hours ago, vgilsoler said:

It seems wiper is not able to detect the formation as unit (cat=1) I tested with B17 (WW2 assets pack) and A20G (non WW2 AP)

That is most probably because the aircraft are flying too high to be part of the volume that wiper checks (a sphere with the same radius as the zone -- wiper was built to remove debris on the ground. My (severely limited) imagination failed to foresee that use case.

That being said, perhaps you can trigger the spawning cloner's declone? input to remove the group? Or you could perhaps use a groupTracker's destroy? input for that purpose.

 

[cfrag]

1 hour ago, Chad Vader said:

However this unit is also referenced as a jtac in a ctld do script action.  The unit isn't recognised by ctld and I get no active jtacs.

CTLD is outside DML's scope, and I have rarely looked at it, IIRC, it uses a unit's/group's name and that will throw you off if you are using a DML clone - because clones adhere to DCS's requirement that all names must be unique. You can force a cloner to keep the clone's original name and ID by setting the 'identical' attribute to true. If you do that, remember that the 'Highlander directive' is in force - there can only be one. With identical active, any previous clones from that cloner are destroyed when a new clone group with the same name/ID is created. But CTLD should (hopefully) work with that group.

Edited October 22, 2024 by cfrag

[vgilsoler]

1 hour ago, cfrag said:

That is most probably because the aircraft are flying too high to be part of the volume that wiper checks (a sphere with the same radius as the zone -- wiper was built to remove debris on the ground. My (severely limited) imagination failed to foresee that use case.

That being said, perhaps you can trigger the spawning cloner's declone? input to remove the group? Or you could perhaps use a groupTracker's destroy? input for that purpose.

 

Knowing that I’ll retry changing the zone sizing. 
With declone I had weird behaviour, but I didn’t investigate deeply to provide you enough reasonable evidence.
I’ll take a look on group trackers too. 
 

Thank you very much again and again

[Chad Vader]

4 hours ago, cfrag said:

CTLD is outside DML's scope, and I have rarely looked at it, IIRC, it uses a unit's/group's name and that will throw you off if you are using a DML clone - because clones adhere to DCS's requirement that all names must be unique. You can force a cloner to keep the clone's original name and ID by setting the 'identical' attribute to true. If you do that, remember that the 'Highlander directive' is in force - there can only be one. With identical active, any previous clones from that cloner are destroyed when a new clone group with the same name/ID is created. But CTLD should (hopefully) work with that group.

 

Hm, thanks for the advice but this didnt work.  The JTAC works outside of a clone zone but not when it is spawned by one, even with the suggested attribute set.

[Chad Vader]

I have another question, this time about radio menus.

I can see that the module accepts a flag on addMenu and removeMenu to add and remove the menu respectively, but how do i create a menu and have it hidden by default?  I have tried adding a menu, an add flag and a remove flag, but the menu is there all the time.  I only want it to appear at a specific time, so i used the addmenu attribute and pass a flag in, but the menu is already present by default.

[cfrag]

8 hours ago, Chad Vader said:

remove the menu respectively, but how do i create a menu and have it hidden by default?

You may want to try a raiseFlag on the input that hides the menu 1 second after mission start. I'm not sure that that works for all use cases, but it should for menus that are available for all aircraft.

[DD_Friar]

@Chad Vader, Salute

Have you not tried the "menuVisible" attribute and give it a false paramter?

null

[Chad Vader]

1 hour ago, DD_Friar said:

@Chad Vader, Salute

Have you not tried the "menuVisible" attribute and give it a false paramter?

null

THats it! Thanks all.

[vgilsoler]

22 hours ago, cfrag said:

That is most probably because the aircraft are flying too high to be part of the volume that wiper checks (a sphere with the same radius as the zone -- wiper was built to remove debris on the ground. My (severely limited) imagination failed to foresee that use case.

That being said, perhaps you can trigger the spawning cloner's declone? input to remove the group? Or you could perhaps use a groupTracker's destroy? input for that purpose.

 

I think I found the way to solve it with your recommendation. Setting a big size for the wipe zone, and ups at 0.3 (30s if I'm not wrong) to allow the whole formation to be inside the zone and removed.

After checking the documentation, if I understood it correctly, declone and grouptracker can not be used in this case:

- Declone, it deletes the last spawned batch of units. I want to have it several formations flying at same time in the map following the same path. For performance reasons I do not want to integrate in the same big formation. So when the first batch arrives at the "safe" zone, it needs to be removed. But the last one created needs to follow their path to the zone. 

- GroupTracker, If I associate the clone zone to the tracker and I trigger the tracker destroy, then all the clones associated to the tracker will be destroyed. But not only the one has reached the "safe" zone.

 

[Chad Vader]

Me again.

Im getting a strange warning in one of my coundDOwn zones despite the zone working as intended

any ideas?  Can I supress warnings inside this zone?  If so how?

null

Edited October 23, 2024 by Chad Vader

[DD_Friar]

That warning message is not generated by the countdown script from what I can see?

Are you using/referencing the same zone for another module perhaps?

[Chad Vader]

Errrr not as far as I can see...

[DD_Friar]

@cfrag, Salute

Ref my scenario of only cloning based on the owner of an airfield posted earlier.

After many hours of staring into space thinking and scribbling copious notes of flag values on scraps of paper I have decided to ask for help.

Just to remind you the scenario I am after:

Blue player flys into zone, triggers flag; mission checks for ownership of airfield; if red owned, spawns random plane; if blue nothing happens.

For my test I am using a vehicle driving into a zone.

nullThe airfield is set to be owner red at mission start, giving the owner flag a value of 1.

My thinking is that inZone get triggered and incremented.

The changer applies a bool and converts whatever value the value of the flag has reached to 1 and applies to okToSpawn

The rnd should then only trigger if okToSpawn (which should = 1) is equal to the value of ownerGaziantep (1=red). If blue capture the airfield this value will change to 2 and the trigger rule is then invalid okToSpawn will equal 1 and owner will equal 2 so no spawn.

This workflow is ok the first time the car goes into the zone. The second and subsequent times nothing happens as I assume okToSpawn has not changed in value, it will always be 1.

Any thoughts on how I get round this?

Many thanks as always.

Cheers

Friarnull