cfrag

Perhaps. Then again, we see the same terrible UX blunders in the sim (look at the 'join faction' mess, and the clownishly bad CH47 cargo dialog), so I'm not sure what to think - except that the result is the same: terrible, terrible UX and a bad customer impression. I wholeheartedly agree. Frankly, there is so much basic functionality missing from ME: try and change the faction of multiple groups or objects, something so basic that I would have thought that it would be the first thing to be implemented in a mission editor, yet two decades down the line, ME can't do it. Look at the tool palette at the left edge. EVERY UI designer knows how important the upper left corner and left edge is, and that they are the exclusive area for only the most important, most used tools for editing. In ME they are squandered for silly, third-tier functions like 'new mission', 'open' or 'save' that can easily be relegated to menus. From this I assert that no-one with even a hint of UX knowledge has looked at ME in decades, and I lament that it appears that this stain is now leaking into the main app (simulator) as can be evidenced by amateurish interface blunders like the 'join coalition' blunder and cargo clown show.

Unfortunately, I think that UX talent is exceedingly thin at ED. If you look at the UX/Implementation of the new band selection or last year's line art function, you start wondering if they have any UX expertise at ED at all, and counting yourself lucky that tabbing in dialogs works somehow, sometimes, in some places. Yes UX matters a lot, it's how customers experience your product. This realization seems not to have reached the relevant people at ED yet. So let us hope that the abysmal UX releases of the past 18 month become a thing of the past some fine day.

Agreed. This *might* be an option for some warbirds. In the jet age, this is as unrealistic as a 120 second repair job. What I would like is the option to taxi to a tarmac location on airfields to 'officially' turn in your aircraft. Upon arrival there you can get instant refuel, rearm and repair, just like with a full respawn. It's unrealistic, yes, but it may give a sense of accomplishment and satisfaction to players.

Indeed. Plus the Su-25T. It does not apply to many (all?) FF modules. So, for example, you must shut down the A-10A to rearm, but not the C. I *thought* that the Ka-50 was also affected, but, alas, I seem to misremember.

I'm not conversant with DCE, but DCS level 2.5.6 seems a bit out of date. May that be an issue? We are currently at 2.9.11.x

It's abysmally bad interface design that prevents usage rather than enhances it. Unfortunately, it seems to me that one of the most urgent acquisitions for ED is some UX talent. The 'multiplayer join side' dialog already was really bad (and shows how a team can completely screw up UX with a dialog that has just three buttons and some text); the Hook's cargo dialog(s) are worse. This band selection thing UX looks like someone intentionally violated all UX best practices to see what prank they can get away with. To me, it's a really bad trend, and since an application's UI is also its calling card, it badly tarnishes DCS's look as amateurish. We know that ED can do better, and I'm hoping that they do improve in the the near future.

Yes! And optionally also allow mission designers to get rid of the requirement to shut down the engines for rearming.

Agreed. I think that it is why it would be a good idea if Mission Editor allowed more options under control of the mission designer. The repair time wait interval may be something to allow a mission designer control over. There are others, but OP chose this as their request, so I am focusing on that. Indeed. Then again, nobody outside of ED knows what DC really means in the context of DCS, so I'm waiting to see if and what materializes in the years to come. I agree that whatever ED delivers, there will be many discussions and more friction between people and their ideas of what a "proper" mission may be.

There is one way, but it is currently limited to reading and setting flags. Network's doString_in() is set up generally to execute in other environments, but at this point in time, it only executes the methods that read and write mission flags,

Aplologies for being unclear. What I meant to say is that a 3 minute wait before repairs commence appears arbitrary to me and IMHO serves no discernible purpose. For that reason I (as a mission designer) would like some control over this to eliminate it altogether. I see no added gaming value in those three minutes over any other, arbitrary, value. To me, a game is what you, the player, make of it. DCS's online segment is (IIRC) around 10-12% of the entire user base, and there are many disparate gaming styles in that community. To me, there is exactly one way to play DCS correctly: when you have fun. Some people like one play style, others prefer another. And IMHO all are valid - as long as you don't have fun at the expense of others, e.g. as a Griefer (who should eternally rot in a deep, dank dungeon). When I create a mission, I strive to make it fun so that as many people as possible enjoy it. I don't control what other people like, and when people tell me that they like to try a certain aspect in a new mission, I'll try to accommodate. Over time, successful patterns emerge - for example the "Foothold/Pretense" style of content seems a good, successful formula. So if people enjoy what you call "air quake", let them have fun. If you don't like that style, simply look for a different server that serves up a mission that better suits your playstyle. Neither is better, you merely prefer one.

Perhaps. Fact is that in my experience it has been shown that trying to force people to do something (e.g. enforcing no runway take-off etc.) leads to smaller groups and a less popular mission/server. Trying to impose one's will on other people seldom works in favorable ways. Agreed. Given the alternative instant respawn through re-slotting, I don't think it's going to make a big difference. With instant repair people may take the effort and try to RTB and land. In many of my missions I try to incentivize the latter by awarding points for kills etc. only after landing back at base. People then still re-spawn to skip repair, rearm and refuel time. Most people that I know are on the clock when they play DCS: they have kids, partners, elderly relatives, and a job. They feel that they can't be bothered to waste 5 minutes of their quality time on waiting for an arbitrary silly time. DCS is UT with an optional 5-10 minute break after downing the potion, there is nothing realistic in DCS in this regard either. If your plane gets dinged up, it's in for a couple of months in the shop. Even if not, after you land, you are in for a multi-hour debrief, some more debrief with the intelligence dudes, some sleep, and at least a day of prep for the next sortie. There is no way that you'd take off 10 minutes after landing a smoking husk of a plane, that's pure arcade gaming, so we may as well concede that.

What makes you believe that there isn't any in DCS? Can you put a number on that? I believe that you mean to request 'occluded object culling', i.e. that objects (geometry) that are behind other objects or terrains should be culled (removed) from the rendering pipeline before they are submitted to rendering. I believe that DCS already uses object culling for the viewing frustum. Adding a visibility pass to determine which objects occlude others doesn't add much, and may even be more expensive - this is especially true for large objects like carriers or buildings that may be partly occluded and require tests to determine if all their geometry is occluded. So simply rendering all geometry inside the view frustum can be a much more cost-efficient approach compared to trying to cull objects/geometry by determining if they are obscured (occluded) by other objects/terrain. I believe that since around 2005 most render pipelines support a 'bounding box' check for early culling, and it's usually applied for initial view testing/culling during the render process. Applying it after view (frustum) culling on the remaining geometry, to determine mutual occlusion requires that the (massively parallel) GPU first waits for all view culling processes be complete before it can start on mutual occlusion culling. This forces a global synch of all parallel operations in the pipeline. That breaks the rendering pipeline into discrete steps and I believe that it will induce a heavy performance penalty. I do not fully understand what you are recommending here, and why that would improve performance. But it's been a couple of years since I last worked on render processes, so maybe things have changed drastically. (Note: I think it best to disregard 'client-side' from the title, because I think that all rendering in DCS is done on all clients exclusively, no rendering is done on the host.)

Ah. Make sure that you try this in the "mission" environment in the console first. It is well possible that GetDevice() is only avialable for the "export" environment

Indeed. At that time, it made sense since The Hog was DCS's premier attraction, and it was rather well known that NTTR was where the hottest Hog action was taking place (in the form of training of course). It may also have been a nice way for ED to monetize work that ED did for their military customers that used the Hog sim, and quite likely also wanted/used the NTTR map.

What is that GetDevice() method? Can you perhaps link to its description? Is it perhaps part of a framework? I can't recall that method being part of the Mission Scripting Environment (MSE) - which may be the root cause of your issue

Agreed. I would love to have this become a setting in Mission Editor: Instant Repair checkbox. It's completely unrealistic anyway (3 minutes or 3 seconds or instant), so let the mission designer decide if they want this arbitrary element of annoyance.

Not in current DCS.

Set up a trigger rule to activate when you deem the mission done, use the "Picture to all" action and you are done.

Version 20250111 - Initial Release Download: (here - ED User Files) Save evacuees at sea! A fire has broken out on "GeOil Empress II", a gas platform some 10 nautical miles off the coast west of Batumi. There is personnel requesting emergency evacuation, so you and your crew are ordered to take your helicopter (Huey, Hip, Hind or Hook, others can be added easily), land on the burning platform, and rescue as many groups of Evacuees as you can. Return them to the reception and triage point at Batumi's airfield near the green smoke. Note: If you find this mission to be too easy, try turning on fog. If you manage 'Pea Soup', you are ready for some of my other helicopter rescue missions. This mission is entirely non-violent and features live civilian helicopter traffic, optional fog, and a mission log (persistent if enabled) that logs your time in the various airframes. Comms: There is an emergency locator beacon active on "GeOil Empress II" (at 121.5 MHz). Batumi TCN is 16X, Batumi TWR 131.0 MHz Weather: Winds: 0kts Clouds: CAVOK (player-option: fog with variable visibilities) Mission Tinkerers: Although I created this mission for Hueys, Hinds, Hips and Hooks, it is pre-configured to automatically work with other helicopters, including mods like a Blackhawk or Loach. Simply add them with Mission Editor. Enjoy, -ch

The Yak-52 has gone 7 years without becoming final, and with no damage model to speak of... And what is the intended timeline for finalizing the Viggen? It's also 7 years since I purchased it in EA.

Let's just say that should I ever sit in a real fighter plane, something really, really wrong has happened already. That being said, although I own all maps, I detect a distinct pattern: most played maps for me are Caucasus (performance), Syria and Sinaï (simply great maps, but performance is killing my rig until that dang 5090 finds its way into my home). And, strangely, I really like South America - something with the light, I suppose. Kola leaves me cold. "Halfghanistan" and "Iraq" are simply more "dust map" to me, with nothing (no personal attachment) to keep me. NTTR bores me to tears, and after I landed my Hind at the alien inn, I got nothing good to do there. Paris and London kill my VR performance, but Normy 2 will come to my "twilight zone helicopter missions" once my new rig is ready. And I hate the primitive SOH "Persia" map ever since I laid eyes on Syria, that "new lighting model" be damned. I'm old, I fly daylight.

When I say "promise" I'm not talking about a legally binding, enforceable contract. I'm talking about a loose understanding made in mutual trust and respect. For example, when ED state on their home page that, with regards to how long EA would last they tell me I fully accept 'as short as possible' to have a loose meaning and I contend that it includes goodwill on both sides. They already have mine: I purchased. It's like a friend telling me "if you ever need help, call me at any time, and I'll be there for you". It's a non-binding understanding of mutual trust and respect: I won't call for silly things, and my friend reliably has my back in times of need. Now, some friends are good to their word, others... After more than 5 years of waiting for some EA modules that I purchased to improve, with ED it feels like I've called them, and they weren't there for me. It's not the end of the world, but disappointing. I lose trust in them, perhaps some respect too. We are still friendly. And I wish that we could return to the time when I felt that their word had some worth. I'm hoping that the implied (and unenforceable) promise of "as short as possible" may become something meaningful. To me, ED's "as short has possible" now is an empty phrase, just marketing speak - devoid of meaning. I'm hopeful that ED can fill this void and I'm hopeful that they start now, in 2025.

TBH, I think that they are compatible, just not very intuitive. I can visit Rome and the Colosseum today and be reminded of its history and the many tragedies and fights that happened in the past there, and the historical importance it played. Now, if you wanted to accurately re-enact some historical event concerning the Colosseum of antiquity, I agree that modern-day Rome wouldn't be as well suited as, say, a replica of Rome from AD 50. And I believe that is wat you mean - that it would have been preferable to have the SinaÏ map based on the 1970-1980 era if we wanted to re-enact the many important conflicts of that time. I agree. IMHO, what ORT said was not contradictory; it merely is marketing to sugarcoat a drawback. Most maps in DCS are similar in that regard - usually because it's a) very difficult to accurately depict maps from an era where no or too little accurate data exists, and b) if the map was too era-specific that would lock out other uses (accurate helicopter missions in Normy 2? Unfortunately no). If there is going to be a Fulda-Gap (late 50s- early 80s) map, or a Vietnam Map (mid-50 to mid 70), the map creators face the same conundrum, especially since some of DCS most popular modules (Viper, Bug, Flanker) are 80s and younger (with cold warriors finally (!) becoming more popular, and younger aircraft like Typhoon emerging). So they compromise on an in-between map and use more easily accessible (low-cost) grid and model data. Since I'm primarily interested in fun over historical accuracy, I don't mind too much, yet I do see the missed opportunities.

Which reminds me of a German proverb: "Lord, give me patience - NOW!"

Probably. I’m used to groups being on freq A on com 1 to talk to each other in the group, and use a common freq B to talk between groups. So yeah, I can see that for some mission designs being on the same main freq can make things easier. I’m using common names for that (e.g. all groups of strike package 1 start with ‚alpha‘), and using frequencies to sort them simply did not occur to me. So yeah, we could have the freq box (that is loosely tied to the player‘s coms) as one way to sort. Just because I don’t use it doesn’t mean it does not have merit. Looking at the myriad of coms that player planes can have, I simply wasn’t sure of this function‘s usefulness, and I’m still afraid of how the kind folk at ED may implement this.