cfrag

It looks as if you are trying to load that guy into a Gazelle. That's not a troop transport by default. Also make sure that its type is among the loadables

I hear that swinging a dead cat thrice around your head at midnight may help. This is, unfortunately, a long-standing disappointment with ED, and their lack of enthusiasm in supporting customers and content creators. The link you are using (mr. skortch) is the best we have, and it's again a privately maintained -- thank you!). You may be lucky finding the Stinger in the "Air Defense" folder: https://github.com/mrSkortch/DCS-miscScripts/blob/master/ObjectDB/Air Defense/Stinger manpad GRG.lua

While I think that I understand that desire from a mission designer's point of view (and since this is a wish list, all wishes are good), I wonder about the practicality. There are many airframes that have different radios, UHF, VHF, and some have redundant radios. Which brings up the question: if you list units 'by frequency', which radio has precedence over others? What do you list by? How do FM and AM figure in? What are the rules that govern such a sort algorithm? ME is already riddled with abysmally bad UX, and I think that I can live without yet another rule that nobody understands except those who implemented them. With DCS' ME we also have the exacerbating problem that those who implement ME are far removed from those who actually use it (else interface as hellishly broken as that for 'band select' or 'line art' would never have seen the light of day).

Well, perhaps not LL dec, but MGRS or other (range, bearing) is already possible and implemented. What is the use case that you are looking for? What are you trying to achieve? Here are the wildcards defined for the "who" and "what" attributes in the jtacGrpUI config zone · <u> : name of the unit · <g> : name of the group · <p> : name of player controlling that unit (only when that unit is commanded by a player using Combined Arms, “AI” otherwise) · <typ> : type of the unit · <c> or <C> : coalition of that unit (lower and UPPER case) · <e> or <E> : enemy coalition for that unit )lower and UPPER case) · <twn> : name of closest town on map to that unit (requires ‘twn’ module) · <twnkm> : name, distance (in km) and direction from nearest town (requires ‘twn’ module) · <twnnm> : name, distance (in nautical miles) and direction from nearest town (requires ‘twn’ module) · <lat> : latitude of unit · <lon> : longitude of unit · <elem> : elevation of unit in meters · <eleft> : elevation of unit in feet · <bea> : bearing of unit to player requesting report · <rng> : range (in km) of unit to player requesting report · <rngnm> : range (in nm) of unit to player requesting report · <code> : laser code used to lase target

That is interesting - perhaps we need to align our expectations. Below please find a miz that puts an orange, blue and green smoke in front of a player-controlled frogfoot (free plane) In my DCS install it's colored smoke from script, and looks very much like the smoke from the colored phosphorous round. What do you get? Perhaps post an image or show the code you are using that results in a haze. haze or smoke.miz

Trigger.action.smoke() is the correct effect, as used in ME. You may want to adjust for terrain elevation by using land.getHeight, else most of your smoke is below the terrain.

“Honi Soit Qui Mal Y Pense”

They'll be in the next release, I'm busy documenting and testing them. Doing this required massive changes to dcsCommon as well, so there's a lot of new stuff to come.

So below is a multiple proof of concept miz for you to play around (and perhaps report bugs) that showcases laser codes per spawner customizable lasing report with wildcard support heloTroops that support individual laser codes and (yes) drivable spawned units. Preserving drivable requires that the units are spawned from a spawner. Have fun, -ch demo - lazie troops.miz

Yeah, that 'drivable' attribute does not carry over via DCS API, and therefore gets lost. Let me see if I can find a fix, but do not get your hopes up.

Screw the Blackhawk, I want "Helicopter 66". I remember nights spent before the TV with my parents, waiting for the "moon capsule" to water-down. Helicopter 66 is what fascinated me most, what an absolutely iconic aircraft.

ED aren't youtubers that put out some shoddy content every day. Production quality of those ED videos is much higher, and I wager that just finalizing the video takes more than two weeks. An educated guess: a video production project like this runs 3 months plus: from the definition of the message, over storyboarding, production of "b" footage, main footage, music composition/selection/licensing, audio recording (ED Nick has a cool voice, yes, but there little chance that he can do that in a single, 1h session), audio mixing, to post/mastering. 3 Months seems tight to me, so yeah, let's hope that they hit the 16th. This video is going to be viewed by millions and impacts their reputation directly. Worse, the footage will be dissected frame-by-frame and analyzed by certified nutcases like me that hang around here, just waiting for a single mis-rendered blend that "obviously" confirms half-life 3. And yeah, I'm looking forward to that video, too.

Well, I can certainly try and add it. Just to be sure - you'd like the lasing team give coordinates of the target, correct? And probably in MGRS, right? I'll see if I can retroactively make the lasing report be made of wildcards similar to messenger so it is designer-customizable. Will probably take some time.

Thank you for following up on this, @Flappie. I just checked (just some spot-checking), an now the menus do seem to be correctly present in dedicated server. Cheers, -ch

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.