cfrag

Agreed, and it was a very welcome upgrade to us poor VR using chaps, to whom the old FC textures were (nearly literally) an eye sore. I'm hoping that the Huey comes next. If there was one complaint wrt the FC texture touch-up, mine would be that it was free. It IMHO sends the wrong message to the wrong kind of people, and I would have paid for it (hint: I'm willing to pay for a Huey visual update as well, just like I did for my Tiger. Just a paint job, yeah. Like with my car, I don't expect it to be free, just professional)

Ha! Silly me never thought of that. That's a nice idea!

In DCS, everything is linked with names (unit/object names are supposed to be unique). So, in order to link a trigger zone to a cloned unit, you need to use the 'identical' attribute. Cloning a group that has 'identical' set to true will immediately remove any previous incarnation of that same name to ensure that "there can only be one".

If I understand you correctly you are looking for a way that allows convoys or other spawned ground units to generate CSAR missions. I think that I did explore this some time ago, and observed that as long as there is one enemy unit in the vicinity, that unit moves to kill the evacuee(s), and very quickly there no longer is a CSAR mission to speak of. DCS ground units' AI simply isn't. Therefore I concluded that it would be easier to simply generate a CSAR missions in random locations. That being said, have you tried having a CSAR mission creation zone follow a unit, and when the unit dies trigger the CSAR mission creation? It could work, with the problem of course that the unit that killed the vehicle will quickly proceed to kill the CSAR evacuees. And sure, I'd be happy to explore this further, with any ideas that you may have.

Now, this one almost drove me nuts. Until I realized that there's something funky in Lua's internal grep implementation that I use for text pattern recognition. I re-built the method that scans and replaces the A/B wildcards, and it should now work. The relevant code is in cfxZones, not messenger, so please find an updated version to replace yours and - if you have the time - tell me if it works for you. Because valet, being a dedicated module to look after units always knows which unit just triggered the module and then can derive the player from that. Messenger, being general-purpose, can't and therefore requires help. cfxZones.lua

Ha, finally! Someone to put the messenger through it's paces! It looks as if you are 90% where you want to be, but I think that part of the documentation needs to be more clear. Let's try and analyze the message and see where it runs against what I currently put into messenger to understand Wildcards always need a reference, and although you do supply the keyword <player>, you need to tell messenger which player you mean, because in DCS there is no concept of "I", a script doesn't know on who's client it is running. So to access the player name of someone flying unit x, you will need to provide the unit's name. For example "Hello <player:theHawg>," will replace <player:theHawg> with the name of the player that is currently flying the unit named "theHawg" I'm really happy to see you use this, because it is exactly what I intended it for. Again, usage is tied to a flag or unit that if it set to a value other than zero or the unit exists will return the "true" (right) part of the declaration, the left otherwise. It seems that you are 99.9% there already: It should work when set to <A/B: bp_OK [You did not follow the base procedures for Gudauta base as has been issued for this mission. | You have properly followed the base procedures for Gudauta.]> with bl_OK being a standard DCS flag. If that flag is set to any value other than 0 (zero), the right side of "|" should be returned, the left part otherwise. Instead of "true", use "A/B". So, small changes - does that help?

Thank you for the report. I'm afraid I can't reproduce. Can you get the small demo below to exhibit the issue? convoy this.miz

My apologies, I'm not knowledgeable with regards to mods and their folders. There are forums dedicated to that, and I'm sure those questions will be quickly answered there.

That would entirely depend on how you set up your DCS. The Hooks folder is the standard folder that accepts server mods for any DCS installation, be they dedicated or ad-hoc hosted. That's where the GUI script needs to be placed, and the server needs to be restarted. The "multiplayer script" stopGapGUI.lua fixes a DCS synchronization bug for multiplayer only and must be put into Hooks. The stopGaps.lua script must be put into any mission that wants to take advantage of displaying player aircraft as static objects.

Yes. stopGapGUI.lua should (if you have a standard DCS install) be put into C:\Users\<your user name>\Saved Games\DCS\Scripts\Hooks That's all. You then need to fully restart DCS, as any scripts in /Hooks are only run when DCS starts up. This only applies to multiplayer missions, and it only applies to the one computer that hosts the multiplayer game. The client computers do not require stopGapGUI to be installed. No. Except for the trigger rule that loads the stopGaps.lua main script, of course. That should run AT START, just like the demo shows

It sure is. Then again, if ED develop and add something (anything) to DCS and call that a "save" feature, that is that - it would still be better than nothing. Pretty much like the new multi-object band selection feature that was added to ME. It may have the silliest, goofiest and worst UX that the world has ever seen (a modal band select that needs activation and de-activation tells us everything that we need to know; adding modal move on top of that seems almost logical), and it may not cover the the three most likely use cases that mission creators would want to use multi-object select for (changing the selection's coalition, unit type, or name). It's still leaps and bounds better than having nothing, so it is a step up. I'm hoping for some form of in-game save, and I think that it will only serve to make DCS better. Many of the missions that I have created in the past two years have outgrown single-session resolvability (meaning that in these missions players can't achieve all goals within 2-3 hours, and require multiple sorties often in multiple types), so any form of save can help to make these missions better. Such a feature should really help making server-based missions better because a regular save&restart can help keeping the servers stable (the two servers that I rent regularly die of memory starvation and require a full boot once a day). I have implemented my own persistence for bigger missions, but of course if this was supported out-of-the-box, it would greatly increase the attractiveness of complex missions for everyone.

Not yet - I haven't seen an API for dust, but there is some published for fog.

Indeed. It appears fog is a global setting, for the entire map, and you will have to adjust thickness for your local requirements at your local airfield, which is rather unfortunate and makes it ill suitable for multiplayer missions that have different, far apart areas of operation. So, if you want some 100m fog at Amman, you'd set thickness to 400. This will make the fog 100m thick at Amman (which is at 300 meters MSL) - and that unfortunately also creates fog 400m thick at Incirlik (MSL 0), some 560nm (1000km) away. Real life fog doesn't work that way at all, since it's a local weather phenomenon. But at least we can have a fog visual effect.

I *really* hope it is - and I'm hoping for "save and continue" of a mission rather than "save and create a new mission based on what is saved" - we already have that from third parties, and it is not what I call "save". I'm currently not convinced that it's in the cards, though. All missions in DCS currently run on Lua in DCS. To be able to save&continue, ED first have to be able to save&continue a Lua script. I don't think that the kind folk at ED have the required talent inhouse to do that - IIRC they weren't even able to shoehorn the existing Lua JIT compiler environment into DCS, which isn't as complex technology-wise as implementing Lua save&continue. Once we start seeing major changes to DCS's Lua environment (and I'm hoping JIT, threads, save&continue) we have a good shot at a save&continue mission feature. Here's to hoping.

That helped a lot. It seems that I overlooked that one for a long time (it requires useOffset AND that you linked the units using ME's LINKUNIT instead of the "linkedUnit" to become problematic). Below please find an updated zones module that should correct the issue. cfxZones.lua

It means a failed attempt at humor on my part. Adding the scooter is exceedingly easy.

I did not put any community-mod planes into Marianas (lazy, I know ) That rather depends on how comfortable you are with ME. If you have added aircraft before, I'd say it'll take you about 20 seconds, plus the time required to write the miz back to storage.

20241218 - 2024 Year's end update And so it goes... This update adds fog control to DML. Changes in detail Documentation Manual - Fogger (new) - Foggy bottoms demo (new) - small updates Quickref - Fogger (new) Demos - Foggy Bottoms (new) Modules - cloneZones 2.5.1 - deprecated f? and in? - fogger 1.0.0 - initial release - playerScore 5.0.1 - code hardening Enjoy, -ch

Hmmm. Have you checked the "Air Defenses" folder? There seem to be a couple of NASAM objects in there. The Hercules Module isn't released, AFAIK. I sincerely hope that there will be an API for that. Maybe ED can work something in there so there is a common API/Ux for cargo aircraft like the Hook, Hip, Herc etc. And hopefully something better than that atrocious and silly thing that's currently in the game for the Hook.

Thank you. I believe I caught the error, please try below update. Still needs some regression testing, and I think I can dragoon you into that playerScore.lua

Certainly. F/A/18, F-14, F-4 (is that carrier-capable in DCS?), Su-33

Oh, great - and thank you so much for reporting this issue. I'll try and get to the bottom of this, so if you have a short demo mission for me to re-produce the issue, that would help greatly. That being said, I *believe* that recently there where changes with the new aircrew patch on super carriers where you no longer can place units/objects because reasons. (I did not yet have the time to check this, currently I'm mostly flying rotorwings). If anyone has a link to the new 'allowed parking' zones for SC, I think that would help me.

As (currently) a Rotörhead (as my godson loves to call it after he discovered some of Lemmy's ditties in my audio archive), I took to some low-level flying over Iraq. VR performance in the Huey and Hip was OK (although my rig is getting old, I'm now waiting for the 5-beast from Nvidia to release), the Kiowas acceptable, in the Hook it was problematic (although I attribute that to the Hook). The (probably) sat-imagery derived ground textures take a bit of getting used to; to my eyes, many objects like hangars, buildings etc. stick out like sore thumbs against the ground textures (an effect I first noticed with the SA map). In all, though, I think that the map has potential, and I have to take a closer look at the locations to find some engaging parts where I can set up some fun missions. Sadly, Mosul currently does not have an airfield, not even a heliport. Worse, not a single "H" was evident on the entire map, not even, sadly, for hospitals), so lacking the infrastructure, Iraq seems a bit to be a rotorhead wasteland to me (contrast that with Syria, which added 120 heloports just in the last update). Compared to Afghanistan, I think that Iraq feels a bit more balanced, and the color palette doesn't appear as washed-out ("bleached"), the mountain range textures in Iraq when travelling close to the ground don't appear quite as pixellated, although some of the deep shadows from the sat imagery still translate to dark blotches that simply look bad and unconvincing. In short, I hope that that this map improves - it has potential, and it is good to have it as it hosted some of the most intense conflicts in recent history. Currently, it's not yet a 'chopper map', Syria and Sinai are much better suited right now for that. In a Hog, some ground texture issues also become evident, but not as pronounced as in a rotorwing. Jet jocks don't get themselves dirty, and I'm sure their view is nicer up there where the air is rare. Us low level Angels need a bit more sugar, though. It'll be interesting to see how the Iraq map improves over the next months.

That might work if each server was hosting a mission for only a single player. Even if that was possible, it would also have to mess with player log-in (on return vs initial start) to assign the plane, of which there would have to be two: one to start the entire mission, one for return. That looks incredibly messy, even if it was possible to implement. Having two servers wait on on a single player also looks very wasteful. And how would server A handle a situation if the player was downed on server B? DCS player slot handling is bad enough as it is today, I don't think that making it more complex would make it better.

I think it could be helpful if you showed the "message" attribute (I'm assumung that you are using messenger) in it's raw form, and then perhaps tell us what you expect the output to be