cfrag

That is very kind of you - I'm using a source version control system (Git) that keys on file names, and changing file names to contain the release number works against the very way that this VCS is set up. I'm afraid I won't be using a file name scheme that contains the version.

This is now added (experimentally) in the updated version below. It also supports the twn module for some local color. jtacGrpUI.lua

Actually, that is not a bug. The range and bearing of the lazed target are given relative to you, the pilot of the unit that requests the list

Now, that's a really cool, unforeseen use of heloTroops with CombinedArms. Since CA interaction with MSE is nowhere mentioned nor documented, it never occurred to me to support it (now would I know how). It seems that spawning into a ground vehicle also generates a 'birth' event that allows heloTroops to install its menu. The do not get updated when you move, though, so there will be some jankiness to them, as there are no take-off nor land events for ground vehicles that trigger some heloTroops options. More precisely, it only works for player aircraft that are placed with ME (i.e. it currently won't work with dynamically spawned player aircraft). Since I never imagined that it would be used from CA, the jtacGUI menu isn't installed when you enter a CA unit. Let me see if I can add support for that as well, but it will be experimental, and probably require non-trivial amounts of work. Yeah, that does look like a bug to me. I'll investigate.

Yupp, I goofed up when writing the guards for the damaged! output. Please try this new version of cloneZones: cloneZone.lua

To simply avoid confusion, please use below miz and report back which laser codes are being used in your DCS install with that mission. It should be 1588, as defined in the config zone. lazie troops.miz

I have looked at the code. To the API, they both are ground units. Using some of the DCS-supplied attributes is shaky at best (the DCS-inbuilt attribute system is buggy), but if I have the time, I could try and add a system to exclude Infantry as lase targets. Seeing that I'm inside the module anyway ( ), I'll see what I can do.

That is patently untrue. I've seen literally dozens of them, clustered inside these Spanish, Italian, Greek and Lebanese restaurants in Hamburg. Even - nay especially - in winter....

In that case I'll be off to look at groundTroops again. Just to be sure: you are using spawners to spawn troops with "lase" orders, and there are no units of type "JTAC" inside your spawned groups, right? (I'm only asking because I seem to remember that you would like to include those types as legal troops to carry, so there may be room for confusion) If you carry those spawned troops (using heloTroops) off to some place and drop them to lase enemy units, they should use the laser code that you specified in the groundTroopsConfig zone. You are seeing different results, right? Dang. We'll into the code I shall dive

Hmmmm. That's strange - the group that you put on the ground should lase with the code that you put into the configZone. That's a module-wide setting. Please don't confuse the lase code that you entered into the config zone with the lase code that a true (DCS-controlled) JTAC unit may use. There is a reason why I separate those in DML - DML can't set the lase code JTAC units use, so DML simulates JTAC using it's own laser pointer and code and avoids that type of units. Use the M4 soldier type to avoid confusion.

I believe that the important thing here that ED may want us to notice is the stylized way of the representation, something that may depict a front line between red and blue, like in some RTS games. This may be intended to call our attention to some older (years ago) communication about automatic front line generation that the kind folk at ED narrated when they mentioned their internal 'dynamic campaign'. So perhaps the video will showcase some red/blue front line visualization. We'll see. We know that in those "xxx and beyond" videos, the beyond part usually does the heavy lifting, so let's be both positive and cautions when it comes to our expectations.

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