cfrag

That rather depends what your goals are. You can configure heloTroops so that it can pick up some vehicles (simply include it into the allowed types), and heloTroops does not care if the vehicle is/was player-controlled. It's a vehicle, though, not cargo (DCS seems to differentiate strongly between those two), and the vehicle will be 'loaded' virtually, not sling-loaded. Cargo in DCS currently has no real API, and support from ED for this mission aspect is IMHO abysmal.

Yes - with persistence. If you have the time to RTFM, you may also find this: Indeed. The new 'drivable' attribute makes vehicles spawned with spawners player-controllable.

Hey all -- I'm a fan of ED's products, and a DCS nut. I love flying, I love creating missions, I host two public dedicated servers (at >100 USD/month), I adore most of the modules for DCS - and own them all (yeah, that includes the Hawk). As the year is drawing to an end I looked at my hangar, and thought "well, there now sure seem to be a *lot* of unfinished 'Early Access' titles in here". A full 18 of them are slowly leaking an ever-increasing bit of frustration onto the well-lit floor. To me, each and every Early Access title that ED sell to me comes with a promise: that they will work diligently to finish as quickly as possible. Why do I think that? [source: Eagle Dynamics Home Page] Being an Engineer by trade (even though I'm a management goon for the past 30 years) I took stock of my EA module stable, fired up Excel (don't judge) -- and these are the cold hard numbers: Top Sheet Results: I currently own 18 EA modules that have accumulated 49 Years of EA Time. That is a lot, and my tiny mind immediately spat out another number: Assuming (educated guess) that the EA models on average require an effort of 18 person months to complete, ED's total Early Access Debt (to complete all modules) are 27 person years. So please hear my plea: Dear ED, please remember the promises you made to me and all your customers. I understand that you must sell modules to survive. And please understand that I also measure your efforts on how well you keep your promises. In that regard I think you can and should improve; the numbers currently are not in your favor, I know that you can do better. Please strive to be better in 2025 and the years that follow. I think it would befit a company of your status and reputation to reduce the Early Access Debt at the end of 2025 by 10 years, to 17, and I think it realistic that you can get under 10 years by the end of 2026. Here are the numbers, lest you want to check them yourself Module Released EA Time (Years) Remarks F-16 2019 5 F4E 2024 0.5 F-15E 2023 1 Assumed discontinued Mirage F-1 2022 2 Mosquito 2021 3 JF-17 2019 5 F-14 2019 5 YAK-52 2018 6 AJS Viggen 2017 7 CH-47 Chinook 2024 0.5 AH-64 Apache 2022 2 Mi-24 HIND 2021 3 Afghanistan 2024 0.5 Kola 2024 0.5 Sinai 2023 1 Normandy 2 2023 1 South Atlantic 2022 2 Assumed discontinued Super Carrier 2020 4 Total EA Modules 18 Products Total EA Time 49 Years Est'd Backlog 27 FTE (1 FTE ~ 1 Person Year) Data Source: Eagle Dynamics Web Site, as of November 2024 Yes, it's a simplistic world view (I am a manager after all). I hold ED accountable for everything that they sold me. I do not care if some subcontractor acted up. IMHO, ED are run by adults, and they know what accountability means: no excuses, no finger-pointing. They took my money, they made the promises, and I think they are good for the trust that I placed in them to keep them. And occasionally, they may need a soft push to remember that we believe in them and have not forgotten their promises.

Update 1.65 - 20241116 Version 1.65 Changes removed 'wait 10 secs' message when slotting in service updates to convoy debugger upgrade cfxZones upgrade income requires players to be present Enjoy, -ch

And for the love of god, please allow someone with API skills to work on that API while you are at it! If it was me, whoever greenlit splitting the command tree to trigger and mission commands with different semantics and functions (and who I suspect may also be the one guilty of the atrocious split for getUserFlag/setUserFlag in the API) would be fired on the spot. For cause. Please, please, please put some more effort into the MSE API.

Not with messenger. Ha. Nice idea! Yes - instead of messenger, you could spawn vehicles that are built to transmit the message on specific frequencies, and activate the cloner instead of messenger.

If it ain't broke, don't fix it. The change is only required for those mission where you decide to update countDown. SInce it currently does not provide new features, no update required. In new missions, you will be remembered that the input name has changed to "clock?"

That will take care of it. I also recommend that you use the input "clock?" instead, as I'm now deconflicting the 'count?' attribute and make it exclusive for counter in the next DML update.

Oooooh! I have a suspicion: do you by chance also include the "counter" module into your miz? I just realized that they have a conflicting "count?" attribute, and this can lead to the warning.

Thank you - unfortunately, I can't recreate the issue from the screenshot alone. It seems that there's also a trigger zone "missionDropCountDown-1" that also generates the warning, probably a direct copy. may I have a peek at that zone's attributes? This is really strange. The warning simply means that there is a flag that has defaulted to <none>, and DML thinks that this is not a good idea, but will of course comply. I see no potentially bad defaults, so I'm wondering who can be responsible, and only countDown and messenger are stacked on those zones, and they seem to all be well-defined.

It's a QoL thing that I put in to trace some strange behaviors. Can you do me a favor and post a screenshot of all attributes for zone missionDropCountDown and I can then see where the little overeager archiver attribute spams the warning (I assume 'verbose' is off for the zone).

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?