cfrag

Not yet. I don't think that it will be hard to add, though, so if you are interested, I think I can come up with something in the next few days. Watch this space

Version 2.3.7 -- 20241121 - maintenance update The past few weeks have gone by in a blur. Accordingly, this updates contains some QoL additions, and the "shock block" received some linguistic polish. All Changes in Detail Documentation Main - Worked on many small unclear passages in the hopes that they become more clear - some module updates Quickref - Updates in line with module updates Demos (no changes) Modules - cfxZones 4.4.4 - Support for "drivable" spawns - countDown 2.0.1 - deconflict "count?" attribute: removed - messenger 3.2.1 - removed typo in verbose mode - smokeZones 2.0.1 - deprecated attribute "f?" - spawnZones 2.2.0 - new "drivable" attribute Enjoy, -ch

Hmmmm. Methinks the standard cloner clone? and declone? stuff applies. At least I did not encounter any difficulties: carrier eye candy.miz

Certainly. That's where the xFlags module comes in.

Yes. You may find out the hard way if/when the kind people at ED change the logic without notice again, so why assume if it works? The second test won’t constitute much performance. Change the offset? It’s not guaranteed though. You could use the airfield’s runway info, build a quad from it, and then test if the guy is inside the quad. Not difficult, but a lot of ugly code for an edge case.

It is Please ensure that you are not re-loading an older version of cfxMX with another action. If isDynamicPlayer is nil, that method in cfxMX was overwritten, maybe by an older version. That can happen if, for example, you mix the standalone version of theDebugger into a DML-based mission.

Please also update cfxMX to its newest version.

Please try this bare-bones script: stats = {} stats.verbose = true function stats.update() timer.scheduleFunction(stats.update, {}, timer.getTime() + 120) local coas = {0, 1, 2} local gCount, uCount = 0, 0 for idx, coa in pairs (coas) do local all = coalition.getGroups(coa) for idy, aGroup in pairs (all) do gCount = gCount + 1 uCount = uCount + aGroup:getSize() end end trigger.action.outText("::: stats: <" .. gCount .. "> groups, <" .. uCount .. "> units in mission.", 30) end if stats.verbose then timer.scheduleFunction(stats.update, {}, timer.getTime() + 5) end It only counts cloned clones that are still alive, and not the templates for cloners (those are deallocated at miz start). It may count late activation groups/units, though, how DCS handles those groups is regrettably under-documented. Methinks that is a clever and wise choice. A while back I think I saw a miz where a similar approach was used with the 'impostor' module.

I agree: there are some 150 units at mission start, plus Mist, plus Moose, plus a number of other scripts. 80 owned zones will add to this toll, and is likely to decrease the experience as the mission progresses.

Unfortunately, the miz requires MODs (UH-60) and I can't open it. There is no limit, Just remember that for each capturable zone, the mission must regularly check against all units if the unit is inside the zone. If you jack up zones and units, you can quickly overwhelm the processor (especially since the entirety of Lua scripts run on a single processor). So, if you 100 units and 2 owned zones, there are 200 checks required per second. If you have 100 units and 10 zones, there are 1000 check per second. 400 units and 10 zones ring up 4000 checks per second, etc. A circular owned zone also requires slightly less performance than a quad based. So, not being able to look into your miz, what is the expected average (ground) unit count, and how many owned zones does the miz contain?

Yes, but only with DML and some naming shenanigans (use 'identical' when cloning the unit, and the zone will re-attach)

That's a good idea -- and I you use heloTroops to transport the controllable vehicle, it *should* also spawn as controllable because heloTroops saves what goes into the helo, and spawn whatever went into it (I'll have to verify this, though). It *should*. I'll need to verify, though.

Hey everyone, I'm about to embark on my first try at creating a cold war era mission (multitype/multiplayer), and I just realized that even though I know roughly white time frame the mission would be, it spans some 45 years, and I have no idea what a good mix for fun missions in DCS are, what time period to choose. So I'd like to solicit your opinions and expertise: What player controlled aircraft make a good "cold war" mix (I don't want to mix planes that have to great a difference in abilities) Once I picked the player planes, what are a good fit for AI planes How about AAA and SAM that also fit well for this? I'm aware that there are multiple sets that fit the bill, and I have little interest in historical accuracy - I want to create fun PvE missions (not PvP, that may come later). So there may be the sabre/mig 15 set (with fitting AA and SAM?) and there may be the late 80's set. You are the judge what's fun, I'd merely like to know what you think when you hear "fun cold war mission". Thank you for any insight!

Version 1.81 -- small fix for Nico Hot Hook -- 20241117 Changes: Moved the Hot Hook in Nicosia so that its rotors won't collide with trees Enjoy, -ch

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).