cfrag

Make sure that the Binding Layer is COMMON, not Author as it is right now. "Author" means that only the mission designer can see it in ME view. COMMON means that anyone in the game can see it.

I believe this to be universally true: more players, more business for ED, better for ED. Whether that's better for the current user base will likely be an eternal point of debate, as a broader user base usually comes with some tangible changes, and people hate change. Well, adding a super-tiny sliver of specialty flying to DCS's current niche IMHO will not broaden it perceptibly. Please be advised that in conflicted zones, airspace is closed to civil aviation, for obvious reasons - no one wants a repeat of IA Flight 655. Driving heavies for mil purposes is fine, and hopefully the Herc and perhaps some other cargo planes will make it to DCS. Seeing flying heavy tin is already possible in other FS I do not fully understand how this could much broaden DCS's pull, especially looking at DCS's currently lamentable state of APR/TWR/GND procedures. Better not to put a lantern on that. Until then, what would those new arrivals do in a mil sim with no procedural support nor weapons? Start and shut down their A300? Fly racetrack over Elbrus? Be target practice for SAM and/or other players? That might get old fast. Say, what is the color of the sky in your world? DCS is the big dog in study-level, military, non-certified, multiplayer capable, 1940-2020 era flight gaming that excludes most radio procedures, and encompasses less than 50 airframes. It's a highly specific niche, and other (more gaming-oriented) aerial combat sims' daily on-line slice can eat DCS's entire player base for lunch (the game that rhymes with "War Blunder" has some 160'00-250'000 concurrent online players. DCS has somewhere around 500-1000 players concurrently online (remember to subtract 1 player per server to get at the real number of players). DCS isn't an online-primary game, but the number differential is still staggering. So yes, DCS has a lot of room for improvement, and I would love for DCS to become more competitive in the online arena. So please, please, please make DCS a better online experience. What does that even mean? Some YT like DCS because if outputs cool imagery that drivers their income. So some kid watches a YouTube or tiktok or whatever, marvels at the cool graphics, and then...? Ten minutes and a download later, they sit in the free Su-25T at Batumi. Twelve minutes later, the engines still not running, the game gets wiped, and kiddo goes to look for an air combat game that rhymes with "Plunder". DCS has a long road to become more accessible ahead of it. It's King Of the Hill in VR -- but that, too, is unfortunately very niche (man, how much do I wish VR would become more mainstream. DCS helicopters absolutely kill in VR). Perhaps you could take another, closer look at the gaming world. Combat games outnumber civil by 100 to 1 and more, including air. DCS is niche because of it's focus on avionics and (to a limited amount) procedures and mixes in a decent flight model [please don't anybody fall into the 'DCS is a sim, not game' fallacy. We are all too mature for that, right?] So yes, DCS is niche, and I hope that ED manage to broaden its appeal. There's a lot of uncovered ground there, so here's hoping. I'm not convinced that civil aviation could be the ticket right now, but it could serve to deepen the experience for some players. Once DCS better supports cargo and infrastructure to give those flights some meaning.

I feel that you should never assume that ED invests any talent, knowledge, nor engineering when they create something related to MSE API or in-game UX. To me it looks as if the cheapest, spur-of-moment idea is enough to make it into production. Look at the trigger singleton and marvel at how getUserFlag and setUserFlag are in different branches. Try to wrap your head around why its action branch mirrors some, but not all methods from missionCommands, and in an incompatible way that does not integrate. Too much of the API looks like un-skilled amateur work, and it is inconceivable to me that anyone with even the barest minimum of engineering knowledge green-lit something this unprofessional. I feel that DCS's MSE API is in a really, really bad state. I hope that it will improve someday. The cruel joke that's our current warehouse API doesn't make me optimistic, though. So don't complain too vociferously (you are likely to be awarded warnings for your trouble), and try to make the best of it, try and create fun missions despite the obstacles thrown in your way by the API and/or ME.

That rather depends on how the rendering engine works and its built-in optimization. If we assume DCS's rendering engine and in your hypothetical case a city is user-built (in ME) by adding one object (building, street, lamp, car, fence, whatever) after the other, then the result will be orders of magnitude worse than if that same conglomeration of objects was created in a 3D app (like 3ds Max or Maya), processed, optimized (!!!) and added as a single object (that's how it's usually done). The reason for this is that the latter requires only a single call to GPU draw: fully scale the draw call over all available GPU cores (with many single smaller objects this doesn't scale well), with all vertices having to be camera-transformed just once (especially those that are shared: if two buildings touch walls there are a number of vertices that can be eliminated during optimization - in cities that happens a lot), all textures loaded once, all LOD texture calculations being done once, and the entire thing is then z-transformed and drawn once. For thousands of little objects, there'd be next to no scale effect on transformations, millions if not billions of pixel double-processing (the same pixel being dawn over and over by different objects), same for texture buffering and LOD, making the result greatly less efficient and a much greater drain on performance. Note that this is only true for scenes rendered with painter's algorithm (almost all are, ray-tracing as main algorithm as in RTX isn't standard yet because of its highly inefficient method). IIRC, DCS uses the painter's algorithm. So, I expect that a city built from individually placed objects in ME would have an exponentially worse (by number of objects) performance curve compared to exactly the same set of source objects, pre-optimized and professionally pre-processed into a single object.

Indeed. They have not made it into the API yet. As soon as they do, I'll try and get them into DML as well.

Yes. At least you still have the source, though. Anything from 3rd party vendors like Razbam, and you are SOL when they leave.

Ummm. You are trawling Lua's _G - the environment's global table. And yes, DCS's countries are a mess. Have been since Flanker days. To add fun to this, you'll notice that there is no country with ID=14 when you look at the country enum. Doubtfully. ED aren't exactly known for their code engineering prowess, at least not when it comes to MSE's API.

1. select object outside of line drawing mode (ME's UX is abysmal, I know) 2. press 'del' key (note: NOT backspace, repeat above's snide comment on ME's UX)

I believe that if I learned anything in the past years, I recommend that people only focus on the first part: if people are happy with what is released, that's good. I now tend to disregard anything else -- be it announced, promised, alluded to, inferred, suggested, mentioned or otherwise indicated that might be delivered by the kind people at ED as irrelevant until the point in time that they actually deliver. Case in point: I'm still waiting (after 7 years) for the delivery of a damage model for the YAK. It wasn't promised, I know. It was acknowledged that it's missing. Agreed. And as a customer expect that whatever you get will be the near-final state if sales numbers don't allow for a clear progress path after EA release. So, buy what is available now, not what has potential to come later. Unless you are an perennial optimist like me.

After more than 3 decades of suffering through management fads, let's hope that ED are kind enough to spare us and their hard-working employees this one. Truth is: there is exactly one Minimum Requirement that makes a product qualify as WVP: find someone who purchases it. Everything else is marketing talk from some consulting know-it-all who want to sell their particular brand of methodology. How do I know? I was one of them. RUP, Agile, SevenSigma, Lean, Prometh, CPM, Prince, Kanban, Xtreme - you name it, I sold it. I'm certified (and literally certifiable ) in all of them. A good project manager can do waterfall in any methodology. MVP is merely marketing gobbledygook, designed to shield incompetent managers from accountability. So, realistically, what's an MVP to ED? Whatever they can sell. Looking at the past decade, EA is what ED sell (with a single one of them limping across the finish line) - a minimalistic approach to both quality and completeness. I think that ED know what 'viable' means to their customers because their EA products sell well enough. The "minimal" term may be debatable, and I do not want to find out how much less quality us customers would be willing to accept. Let's hope and see if ED's approach of min-maxing products keeps them and us alive for the coming years. And I'm still hoping for a damage model to arrive for my EA YAK that I purchased 7 years ago.

IIRC the upgrade to from FC3 to FC24 was the inclusion of the Sabre and Mig 15 as lo-complexity versions of the FF planes. The visual update to the existing FC3 planes happened some time before that. Perhaps you mixed up those two events?

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.