cfrag

That should not have created any issues, since you never give orders, merely ask the module to collate all active ground troops that are lasing targtes. Remember that the module has no knowledge of, and does not interface with, DCS' JTAC abilities (for the simple reason that DCS does not provide an API for that). The fix merely patches the error that appeared to you. That being said, is there a bug that you have seen relating to that and that I failed to remember?

Agreed. For me, "the core" would represent the stuff we get with DCS, and that is shared between all missions (meaning: third party work like Kola, Phantom etc) is not part of the core. Fog is, and - even though it remains far behind our hopes, and makes a mockery of the term "realism" - it has added a lot for me in terms of immersion (shooting a successful precision approach in IMC with ground fog now has become so much more gratifying). I truly hope that the core (shared infrastructure) improves this year, to prevent DCS becoming a hollowed-out shell that merely feeds off its former reputation. There's a lot of technical debt piling up, and the fine folk at ED are hopefully up for the challenge and can resist the temptation to merely milk the crowds through ever-new unfinished modules. I don't know about you, I own some 20 Early Access modules (yeah, slow learner), and i would love to see some of them receiving updates to make them true, quality releases - and the core to receive enough updates to raise overall quality of DCS to a 2020 level app (to me, it currently feels like an early 2000 level app). Here's to ED mastering that challenge and hopefully many, many more years of excitement.

Here's an update that I wasn't able to fully regression test yet, but it should work. jtacGrpUI.lua

Thank you so much. That indeed puzzles me because I thought that I caught that one. I'll have a look.

Where you using the JTAC's nine line, or direct lasing abilities from the jtac module? The nine line standard JTAC interface is controlled by DCS, not the module. I think (will need to check back) that the jtacGUIL and GroundTroops tell you what they are lasing. I'll see if I can find a way to simply cycle the their targeting on request from jtacGUI. Please always be sure to use the most current version before reporting a bug.

Which version? I believe 3.1.0 is current.

I slightly modified your script to call more attention to possible issues and print them out: local verbose = true local function dx(name) if verbose then trigger.action.outText("---start dx on <" .. name .. ">", 30) end local ob = StaticObject.getByName(name) if ob then Object.destroy(ob) if verbose then trigger.action.outText("---dx: OK", 30) end else trigger.action.outText("---dx: <" .. name .. "> does not exist", 30) end end dx('Static S-3B Tanker-1-1') dx('Static E-2D-1-1') dx('Static C-2A Greyhound-1-1') dx('Static F/A-18C Lot 20-5-1') dx('Static F/A-18C Lot 20-4-1') dx('Static F/A-18C Lot 20-3-1') dx('Static F/A-18C Lot 20-14-1') dx('Static F/A-18C Lot 20-2-1') dx('Static F/A-18C Lot 20-1-1') dx('Static Carrier Technician-1-1') dx('Static Carrier Seaman-1-1') dx('Static Carrier Seaman-2-1') dx('Static M117 bombs-5-1') dx('Static M117 bombs-4-1') dx('Static M117 bombs-3-1') dx('Static M117 bombs-2-1') dx('Static M117 bombs-1-1') dx('Static AS32-P25-1-1') dx('Static AS32-32A-1-1') Maybe that can help?

Why don't we try this: use the new band selection tool to select the entire carrier and all objects, then paste it into a new mission (you need to activate band selection prior to pasting. Yeah, ED is *really* bad at UX design). Add the script and see if it runs in SP and MP, and if it fails send it to me (if it doesn't the root cause might be outside of the script) In the meantime, I'll look at the script.

It took me a while to figure this one out, and I think that I've come up with a workable solution. But first, Just to make sure - you are using dropZone's autoDespawn attribute for this, right? If so, you are compatible with the new solution for heloTroops, which uses a dropZone's "autoDespawn" attribute to determine if it should show units inside a drop zone as being loadable. If autoDespawn is active (i.e., > 0) in this zone, any transportable units inside the drop zone are ineligible to be picked up: autoDespawn Time interval in seconds after which disembarked troops despawn. Used primarily to clear the drop zone in extraction-based missions that would overcrowd otherwise. Set to a value less than 1 to turn off Note: If autoDespawn is 0 (zero) or greater, any otherwise embarkable troops inside that trigger zone will not appear on the ‘load’ menu and can’t be loaded. Defaults to -1 (no auto-despawn) So, all you need to do to make any troops not being able to pick up inside a drop zone is to set the autoDespawn attribute to a value greater than zero. I also updated demo "Inferno at sea" to reflect the changes (in the demo you need to fly over to the oil rig a mile off Batumi, pick up the guys and bring them home). heloTroops.lua demo - Inferno at Sea.miz

Well this is an edge case, and it conflicts with a scenario where you accidentally deployed troops and want to reload them - so it will be extra code for little return. Then again, let me see first how much effort I'm looking at.

While I find this interesting from a technical standpoint, isn’t what we see at those long ranges a bit silly? Since dcs’s world isn’t curved, those images may be a flat-earthers wet dream, yes. Shouldn’t objects and terrain (better: the lower part of mountains) start to disappear? In other words: are those visuals in any way realistic? I have not researched this, just curious.

Interesting. I had a quick look at the second script and the one thing that immediately jumped out is that StaticObject.getByName('Static Carrier Seaman-2-1'):destroy() is in there twice (along with some others). I assume that when executed the second time on a deleted object, getByName() returns nil, and trying to invoke nil:destroy will (correctly) terminate the script, with some very explicit messages in the log. I have no idea why it works on singleplayer, except that maybe script execution is immediate on the server, while collated on single-player? It may be due to the fact that server isn't yet multi-threaded and the game waits for a response before proceesing, halting execution -- but bustling through on a multi-threaded invocation (it should not, however, mysterious)

Perhaps it might help if you showed the script or a simplified miz that reproduces the issue. In cases like this, I usually go either trigger.action.outText() or env.info() for each script with an "I'm here" to make sure that the various branches and methods are really invoked. Safest bet: some of your code isn't invoked.

Version 2.4.0 - 20250101 -- new feature smoke trails module "smoking" To all my friends, present and otherwise: I'll drink a cup of kindness dear, for the sake of auld lang syne. Happy new year, dad - I miss you. As we enter the fourth year of DML, I won't spend too much time reflecting. DML has progessed nicely, while I feel that DCS itself has perceptibly struggled. There have been a bewildering amount of missed opportunities, and I'm hoping that 2025 allows DCS to return to former brightness, that the sun was merely hiding behind some clouds - and isn't setting. DML starts 2025 with a new feature: smoke trails for any player plane. That feature is unfortunately (nearly terminally) marred by a long-standing (2 years) bug inside DCS, and I hope (but have no reason to believe) that it may be fixed by ED someday. Other than that, I spent some time between the years on DML code polishing, and a lot of time with my friends - sharing their love, and remembering those who have passed. Take care, all of you -- and let's make a great 2025! All Changes Documentation Main - Smoking (new module) - The Smoke is ON (demo) - Updated Bool attribute (new percentage option) - various corrections Quick Ref - various corrections - Smoking (new) Demos - The Smoke is ON (new) Modules - cfxZones 4.5.0 - corrected getBool edge case bug - better handling of linked objects in startMovingZones - improved random handling for getBool, new percentage option - new getSmokeColorNumberFromZoneProperty - dcsCommon 3.1.5 - some improved verbosity for edge case detection - fogger 1.1.0 - new "local" thickness option - smoking 1.0.0 - initial release

Thank you so much - and happy new year!

Dear @Flappie, it seems that more than a year down the line, this issue still is present. Do you have any idea if this is still being looked at? Please see below mission that can re-produce the issue at will: go to communications and turn smoke on. As soon as you descend below the altitude that you turned it on, smoke turns off; when you ascend above the altitude, it turns on again. The smoke is ON.miz

Version 2.20 -- 20241231 (user-controlled smoke trails) Sliding in on the final day of 2024, here's Mariana's Proving Grounds with a fun little addition: user controlled smoke trails. Now any pilot can try their hand at writing in the sky in any plane that they like (and own). Have a "nice slide into 2025" as we say in German: "Guten Rutsch!" Cheers and enjoy, -ch

I can't open your mission because it contains mods. That being said, from the screenshots that you kindly included you seem to be ignoring the warnings at the beginning of the mission where radioMenu and scribe both complain that they cannot connect (attach) to a radioMainMenu zone called "Mission Main Menu" Please verify that the Trigger Zone "Mission Main Menu" has an attribute "radioMainMenu"

I believe the opposite to be true: those with a deeper understanding of the current state of AI know the futility of asking a vector-based, large data basin based algorithm to even understand the question. Currently, our best AI efforts cannot understand the question, so their answers are deterministic linear results -- all they can do is look for troughs in the first derivative of the landscape defined by the question set applied to the learned data model. It works, but it can't generate new insights, it can't yet infer knowledge. Yes, people with little knowledge in the field don't know that, and they may even believe that newer AI algorithms like LLM-based chat bots do understand their questions. That's merely an unfortunate combination of good marketing, and a hefty dose of Dunning-Kruger. They don't. At some point in the future, AI surely can make that leap. It hasn't yet.

As always, thank you for chiming in, BN! I (and likely many who frequent this forum) do not really know if "it" is in progress. We do not know what progress, if any, was made in the past 5 years on "it". What many may recall is that you and your kind colleagues have - on occasion - asserted (without elaboration) that you are working on something that you at ED call "dynamic campaign". We have no way of knowing nor guessing what that comprises of: scope, maturity, preconditions, timeline, goals. Absent any guidance I (and probably others) that have, I assume "it" to be something similar to something that exists in a different title that focuses on an iconic fighter aircraft that shall not be named here. Agreed. How could we if we don't know what the scope of "this project" is? Come to think of it, it seems that neither have you (ED) correctly appreciated the complexity, or we wouldn't have NL be on the record that it "wouldn't take 5 years" (meaning: NL thought it would take LESS than 5 years to initial release) - more than 5 years ago. This is not to badmouth you, NL or any of your colleagues. This kind of misjudgments happen all the time in project management (I headed a project that was 3 years late on an initial 1 year timeline). I merely think it highly inopportune to remark how little we, your trusting customers, know -- when all that we can go on is your (ED's) communication on this subject, which, I think, has had a lot of room for improvement. May I suggest that ED improve on that? I'm not looking for particulars, but a roadmap that identifies the major milestones along the way would help a lot. For example, it seems prudent for me to guess that some milestones along the way to a DC are: 1) better ATC, 2) (unless ED is going the "Liberation Campaign" way of merely saving mission results) save/reload mission, 3) better unit AI (ground, naval, air), 4) improved cargo/supplies handling, 5) 'theater-commanding AI'. Some of these milestones could even arrive separately, and if we know how these pieces fit together, we could not only have a better way to gauge progress, we could cheer you on your way to completion. Right now, just like you stated, we don't know, and we do not know how complex the project is. Because nobody who is in the know has ever told us. Understood. Wilco. After some 10 years I hope that you understand and appreciate just how patient some of already are. And (like I) still support ED in their endeavor to bring something vaguely resembling what people dream of when I hear the words "dynamic campaign". I often wish that we had something more concrete to go by. Saying "be patient" is fine, and after a decade, be advised that it also corrodes trust. So, here's to hoping that you (ED) can share some eagerly awaited details and help restore faith in the upcoming dynamic campaign - whatever that may be.

Version 1.80 - 20241230 New player option: fog on demand All Changes Code hardening against DCS bugs (dec 2024) Fog on demand via communications Title card on map Enjoy, -ch

Not to worry. DML comes with some brief documentation and tutorials. All that pulser, rnd and cloner stuff is basic DML

Thank you for reporting back. I've now added an optional 'local' attribute to the fog zone that automatically adds the ground elevation at the zone's center to thickness to make the fog zone more easy to use. It'll be part of the next update.

I don’t have access to my computer for the rest of today, so I didn’t download the miz and neither have I taken a look at it. I have the suspicion, though, that the fog‘s thickness attribute is tripping you up. Thickness defines the upper limit altitude (in meters) that the fog reaches — in MSL!!! IIRC, most of the airfields in NTTR are much higher than the thickness given in the demo, so perhaps you can look up the altitude of the airfield you want covered in fog in meters, and add 500, and enter that value to all the thickness attributes. Does that resolve the issue?

personally, I believe that the risk is very small, provided that you only download missions from ED's user files. DCS is a small target as vector for malware authors, but you should not become complacent, so be sure to only get your missions from reputable places. I use copy/paste on the original, so I have a backup and revert by delete/renaming.