cfrag

No. I added that merely in the hopes to be more clear, to delineate between file name and my ramblings

It appears that you misspelled the file name in the messengers. The correct file name is "beacon beep-beep.ogg", you are referencing "beacon beep_beep.ogg". Note the incorrect underscore "_".

I'm looking at the miz that you kindly provided now, trying to reproduce the issue. Please be advised that (as the warnings at mission start elaborate), the attribute "messageOn?" in zone "01-WP1" is misspelled, the last character is an exclamation point "!" instead of a question mark "?". This will cause the messenger to not activate on "Report", so the "WP1" command does not trigger that messenger in the same zone. I'm still trying to recreate the issue with a message displaying without the sound, please stand by.

There should not be a dependency between modules when it comes to which modules does what, although it can happen in rare cases (and that can create a race condition). Those are difficult to detect, and I hope that you never get into such a situation. Naively (although this does not hold true for multi-threaded DCS), modules execute in the order that you add them to the mission, and I recommend that you do not depend on that.

There are UX/Quality of life limits: it becomes uncomfortable and difficult to keep an overview if you stack too many modules on the same zone. Also, there may be unintentional side effects (which I'm trying to remove) when two modules have attributes that share the same name. That being said, there are no limits to the number of different modules that you can stack on the same zone. It also allows you to use local flags/commands, which keeps the command/flag space clean, and allows you to easily copy/paste stacks.

Wait... "Black_Tyre" is not a ground unit, it's a scenery object. Tires etc. are usually spawned with the objectSpawner. Can you see if vehicles and infantry work with the spawner?

If a Leo is spawned, the type is unknown to DCS and it defaults to a Leo. There's a good likelihood that I screwed up the script. Can you post a screenshot of your spawner zone, and I'll investigate on my side (I did test, and I think the tiny example miz I added did spawn correctly, so I'd love to see an example that trashes the spawner's script)

The reason that the messenger does not fire is because you set the flag "mute" at the very end of MISSION START actions.

Perhaps post an image of both the messenger zone and valet zone, so we can see how you set up the zones. If that doesn't help, PM the miz to me or post hit here, and I'm sure that we can get to the bottom of this quickly.

Unless you enable the 'dropZone only' feature, it merely seems that way. If you turn on auto-drop-off and auto-pick-up, you'll see that the relevant code is invoked, it's DCS's menu caching that hates you. I see if I can rework the code to force menu generation, but it will be crude...

You now can optionally restrict drop-off to designated dropZones (for heloTroops). It has to be turned on, though. It's intended to facilitate some mission times that are now trivial to implement. To enable that, heloTroops' config zone must be set to enforceDropZones = true. Now, it's possible that DCS's menu manager doesn't correctly update the menus after you pick up troops and then land (it apparently caches the old menu). If that happens, go up all the levels, then exit menu, then call it up again, and the disembark option should be there

That decides the issue -- if a helo picks up troops, they 'forget' anything that was ordered with ME. When they disembark from a helicopter, heloTroops hands them off to groundCommander. A Spawner's orders can make the transition, a cloner's can't. So if you want the 'attackZones' order to survive the troops being picked up and then deployed, a spawner is your only option. Have you tried the "WAIT-" prefix?

Unfortunately, no. The reason on simple, and trace back to the way that DCS handles units. Spawners simply create new groups, based on the types that you define. These groups have no relationship with anything you, the mission designer, places in Mission Editor, and thus they have nothing to do after they spawn. Since they have nothing to do, you can tell a spawner how the spawned units should spend time: guard, lase, seek out owned zones. A separate script, GroundCommander, then keeps those units busy. A cloner, on the other hand, takes an existing group (i.e. one that you placed with Mission Editor), creates a copy from that group (uses the original group as a template), and puts that copy (clone) into the world. Since the group was placed with ME, it comes with routes, waypoints, actions and whatnot, they can have a lot to do. So clones aren't handed over to GroundCommander to keep them busy, they already have orders to follow (a copy of whatever you gave the original group in ME). Just don't give them any and leave out the attribute. Cloner will take care of the rest, basing the name on the zone name, ensuring no naming conflict will ever arise. I can do a lot more, but it's usually not required. Use defaults as much as you can. That is entirely possible, it's from the earliest stages of DML, written years ago

With the new cargo system, I have no idea where and how the hook's cargo is detected (when not sling loading). The ME trigger detection is superior, but does not work for cargo that is spawned, meaning that all cargo that a ME trigger rule can handle must be placed with ME. Can you PM me (or post here) a brief demo cargo mission that forces the issue for you so I can investigate?

Here you go. The new attribute for the spawner is named "drivable" and if you set it to true (default is false), any spawned vehicle is drivable if Combined Arms supports it. Below please find the modified scripts that will be part of the next DML release, and a demo miz. Only the vehicle spawned by "my ride" can be commanded spawnZones.lua cfxZones.lua catch a ride.miz

Yes. Except that there is a 1/999 chance that the new value is the same as before (in DCS, that's basically certain to fail in the worst possible moment), and no change registers for that reason. It would be better if you used the 'increment flag" action, which is guaranteed every time to be recognized as a change in value.

Ah, huzzah, the cargo API. It seems to work very different from sling-loading, and I'll (against my better instincts) try and have a look at it. Just out of curiosity, what are your steps to load cargo into (i.e. NOT slinging) the Hook? Rearm/refuel, then the cargo abomination to get get that cargo into the chopper, fly to receiver, and use the abominable interface to push it onto the tarmac into the receiver, correct? When you say 'second time', what do you mean exactly? Do you load two pieces of cargo in a single go, and unload two in one go, or do you load, deliver, return, load, deliver? Maybe I can work something out...

... yet -- it simply never occured to me to use a spawner that way, it's blindly obvious now -- I think that I can come up with reasonable patch within the next couple of days.

Expansion only allows spawning from airfields that are owned by blue. Try a fesh start (delete the data folder) and select a slot from Nalchik (a flight starting with "Nal"). That should work.

Yes, issue still there, NO SLMOD running on dedicated server, using Apache null

Apologies if I sound silly (I'm not native English): Can I paraphrase your question as: do people in (dedicated) server that do not have SLMOD running see the issue of disappearing menus? I'll check anyways Can you be slightly more specific for me? What do you mean by that -- you cannot order support flights while you still have funds, or does the "Admiral AI" does not create flights any more?

Yeah, DCS's API strikes again. Here's a list of the cargo objects: https://github.com/mrSkortch/DCS-miscScripts/tree/master/ObjectDB/Cargos uh1h_cargo is the one that you are looking for, and the type name is "uh1h_cargo" How can you discover that on your own? You can't.

Mission Editor automatically removes any resources that arent referenced by trigger rules during 'file save housekeeping' to keep the files small. This can cause grief to anyone who (like you) attempts to include additional files. In order to include your sound file, and ave it in the correct location, add a new trigger rule (ONCE, any name, I call it 'Load Audio), add a Condition "Time Later Than" and make it a large number, e.g. 999999999 so it will never be executed, and then add actions "Sound to all" with your audio files. This makes sure that the miz references the sound files at least once, never plays them in-mission (realistically) itself, and (most importantly) they are accessible to DML and other scripts that try to play them.

i believe that indeed, your change logs are a testament to your and your colleagues continued hard work on DCS. Few here (at least not I) doubt that you are diligently at work, furthering DCS, shaping the future - and I thank you for that: not just in words, but by purchasing modules, and investing >100 USD a month to host two DCS dedicated servers, and creating missions that I share with others. What can give people pause is not so much the amount of effort that ED invests into bettering DCS, but the focus. It's sometimes difficult to put reason to rhyme when we read that people are working on removable pilot patches and another new map when many of the aircraft I own (yes, I own all of them) are still in EA six years after I purchase them. It's ED's focus of work that becomes an irritant. Shining a light on why (ED is a business) helps to understand; my personal view is that some of your customer's irritation stems from the fact that we don't see what your (ED's) focus is and why. Much of the official communication IMHO doesn't help, and often (for me) exacerbates the issue. There's (for me) too much non-committal, if self-gratulatory talk about features like save-game and dynamic campaigns that, when looked at rationally, would already have arrived a long time ago if it was a focus of ED's aspirations. IMHO, the people at ED are working hard, and like so many people here I show my appreciation by staying a loyal customer. Criticism comes with the territory, and please do not confuse my being critical of your efforts with thinking that you are lazy. I appreciate what you are doing - even if I wish that your efforts were directed more into the direction of fulfilling promises made: I regard each and every EA module that I own as a promise that you made to me to complete, and I intend to hold you to it because I think that you are good for it. Currently, I prefer that you keep your many promises made rather than selling us new, unfulfilled ones. After all, even the greatest of all people can only do so much, and I have many, many products of yours that require ED's fine people's attention. So, thank you for your hard work, and please remember the promises you made.

The fact that DC has been talked up for over a decade now and hasn't seen the light of day pretty much puts that hypothesis to rest. Sad truth: there's next to no money in DC. Put another way: if there was an indication that DC would *significantly* increase module sales (sheer player numbers don't count. Player retention doesn't either. ED needs daily module sales), we'd have it by now. DC is viewed by ED as an edge case for a small, albeit vocal, slice of the pie. There may be the occasional investment into DC, and it is definitely going to be talked about -- in glowing terms. Talk's cheap. Delivery is hard. Businesswise, DC won't swim: Take a napkin, jot down an earnest guess how many additional modules ED would sell if DC became part of the DCS package. That's the marginal business value, before subtracting dev cost. Compare that to the number of sales the next hot module will bring (say, a Tornado or Typhoon or other iconic craft), and assume that both share the same dev cost. Nope, dynamic campaigns don't have a chance in hell to get financed. That sad, perhaps ironic, thing is that ED know their Achilles heel, and they said as much in a 2023 interview: DCS suffers from a lack of gaming content, a lack of player engagement. Missions are sterile, there's really nothing for pilots to do beyond training and getting better. A Dynamic Campaign could be giving players something to do, give them purpose. The immense success of quasi-dynamic missions like "Foothold" and "Pretense", where players have some agency and purpose in the overall engagement spotlights the tremendous potential. Yet, although a seismic shift already, that alone won't move the needle far enough -- ED would need to better engage the community, actively support mission creators, server hosts, provide much, much better creation tools, infrastructure, and push the 'story/purpose' mode of DCS. Given ED's IMHO exceedingly low-skilled communication credentials, though, it for me indeed makes more sense to bet on stamping out new, half-baked modules, tech and maps for as long as possible.