Dragon1-1

In fact, they should essentially be special threat steerpoints, that's what they are internally in the real jet. Hopefully when we get the DTC, this functionality will come with it.

The latest versions do have it, but early models (the ones we're the least unlikely to get in DCS) didn't. They just had ACL system for Case III, not unlike the Hornet. Why do you think my favorites are the Tomcat and the Phantom, with MiG-19 also up there? That said, I do have a soft spot for the Viper, despite it holding your hand plenty in a fight. That said, I'd like the Jaguar and the F-111 more than another 4th+ gen jet. Physical interfaces will always be there, for the simple fact that gestures and thoughts are messy. With a stick and throttle, or at least the thumbstick on the latter, there's no doubt what you're telling the jet to do. That said, they might switch to fiddling with the tablet full time.

I think the suggestion is "don't announce release dates", but they're already announced on a short notice, and not doing that at all would be annoying, too, particularly for people who don't have a fast internet connection that can download a 100GB patch in a few minutes (which is a lot of people around the world, particularly outside major cities).

Another reason not to want the F-35 in DCS. Where's skill in that? Put the FPM on the 3-wire marker, flip the PLM switch, watch as the aircraft lands itself. When you do an SHB in a Tomcat, dead on the numbers (because otherwise you won't make it down), that's legitimately impressive. The Hornet takes plenty of skill, too. It sounds like the F-35 largely trivializes even the SHB, nevermind a regular trap.

That only shows that the problem goes really deep. There's no reason for the operating environment to change on a regular (not daily) basis. That we were only doing computing for just 80 years is not the problem (in fact, most of modern engineering is not that much older). The problem is that for most part of those 80 years, we were doing it wrong, and we still are. Consider two things: 1. Much of modern computing world is based on what started out as an ad-hoc OS to play games on a spare computer one guy had laying around, and had since been modified and expanded by everyone and their mother. 2. Fans of said OS will tell you that this is a very good thing. Have you considered that it's extremely expensive, and not usually done, because our software development culture had made it unusual, as opposed to mandatory? "Move fast and break things" is has been established as the way to be "innovative", but all it does is build technical debt. Consider this: had Windows been created, on the architecture level, to be secure against intrusion, it wouldn't have needed a security patch every month, because most of those exploits would not be possible in first place. There was actually an OS that did just that (Multics), but it didn't ship with IBM PC. It could also run for years without being restarted and hot-swap everything including CPUs (not its last one, of course, as a mainframe OS it usually had several). That you can't just pull a GPU or an SSD out of a running PC and insert another, and that you have to reboot it every so often, is not a law of nature, but a deeply embedded design flaw. And don't even get me started on a crock that is the internet.

It's not. They have until 01/01/2025 to notice the time bomb (because if it's anything that specific, it won't be an accident) and remove it. Hence, it does not meet the definition of showstopper. Generally, outside the circumstances such as the infamous millennium bug, or the upcoming Unix time rollover, computer programs act the same no matter on which date they're run, unless they have been programmed to check the timestamp. So, while it's difficult to "prove", it's a pretty unlikely issue in any case. A showstopper is generally something that breaks the game for a lot of people, so it's reasonable to expect QA to spot it. Computer programs are not magic, though it might seem that way to uninitiated. They are, in essence, very complex mathematical expressions, written by humans, and are perfectly deterministic. In civil engineering, for example, a bug would be called "human error" and the originator likely persecuted after, say, the bridge he built collapsed. And just like it is possible to design a bridge that doesn't spontaneously collapse (how would you prove it won't collapse after 01/01/2025? Well, there are entire companies making tools for that), it is, theoretically, possible to design a program, even a complex one, without any bugs in it. It's just harder and more expensive, and not helped by the thinking that permeates the consumer programming community, that treats the presence of unintended behavior as a law of nature. Go into embedded programming, especially serious stuff like trains or spacecraft engineering (outside a certain well known company, that is), and you'll see that's exactly what they do. If cars were designed like computer programs are, well, see Tesla, especially early on.

I do remember it being this bad once or twice in recent years. Usually that got patched quickly, and it didn't completely block the game for everyone, but they broke features a few times that basically made it not worth playing until the hotfix. This is what we call a "non sequitur". No bugs=/=no showstopping bugs. The latter is quite possible to prove, and tends to be quickly found out by community. A rivet being two centimeters off to the side, with AO for the corresponding hole visible nearby, is a bug. Game crashing when a certain module's wheels leave the ground is a showstopping bug.

Except sometimes, a bug sneaks in that basically breaks the whole thing. Every time such a howler makes it into the patch, the community cries out (rightly) "How did it make it past QA!?". Well, now it didn't, they caught the potential howler in time. Myself, I'm glad that they caught it before it made it out.

The responsive handling is what many people like about the Huey. The Hind is a chonker of a helo, and so is the Blackhawk. There are several conditions at which a fully loaded Hind needs a runway to take off. Huey? There's a reason they never bothered to give it wheels. It's just a matter of practice.

What I was saying was that it's possible not to lose tally during a typical merge and a turning engagement that follows, without any additional tricks. We need to separate two issues: spotting distance and seeing through the canopy walls. Yes, MiG-21 should have worse SA, but that's beside the point. This discussion is about seeing the bandit from a long distance, where it's just a silhouette, and that silhouette would sometimes disappear. That I have not experienced, in that when I have tally, I can usually keep it. At least in my headset, even during a two circle fight, you don't go out as far as for the bandit to become too difficult to see.

It was actually called that in development, you can still see it in some of the internal names. Someone in marketing likely thought it'd sell better under the current name, but it is very much a Hormuz map. As for why modern, they presumably didn't think a Gulf War version would be popular. In fact, I suspect they simply looked at Google Maps for references, and modeled it more or less as it looked when they started development. It's one of the older maps, back then it probably didn't seem to matter, and we had much fewer vintage aircraft, anyway.

TBH, the word "tarmac" does serve an useful purpose: it means any paved part of the airport that's accessible to aircraft. So you know the passengers were stuck near where the aircraft are, and not, say, in the parking lot, which tends to also be paved with asphalt or concrete. In fact, I wouldn't be surprised if some people didn't even realize it originally referred to a road surfacing material, as opposed to any kind of airport pavement. Seeing as the use of actual tarmac has pretty much passed into history, we might as well reuse the word. Real Tomcat jocks use "Turkey" or "Tomcat", and that's flair enough. Not that it stopped Bug drivers from coming up with other names... This is actually a common myth. NASA did not invent the second meaning of "nominal", it existed before, though it was quite more specific than simply "normal": it meant (and still does), roughly, "related to the value the property is supposed or expected to have". You can have a battery with nominal voltage (in other words, the one written on it) of 1.5V, and the actual voltage (as measured by the multimeter) of 1.45V. The NASA usage is exactly this - if the measured voltage and the value on the label match, you say that the voltage is nominal (and if a spacecraft battery shows 1.45V when the nominal value is 1.5+-0.1V, this is a cause for concern). It's not a huge leap to generalize it to "normal", particularly when dealing with such a numbers-bound discipline as spaceflight. Outside it, I guess an off-nominal value could be normal, but it usually does indicate something has degraded.

No, which is why we can't fly around the globe in DCS. Yet. DCS works in a specific way, it's not the only way to accomplish what it does, but it's the only way DCS can do it. How it works has been explained on the forums in the past. The system, as it was written, has certain limitations. To get around those limitations, a new system needs to be written. This is not a trivial task, but the idea that you'll one day be able to fly to Afghanistan from mainland US is being worked on. Every complex issue has an answer that is short, simple, and wrong. In this case, this would be that answer. ED would have added the coastline if it was worth the effort and (considerable) resources to do so, especially since a big selling point of many modules is carrier operations. If they are not included, there is probably a good reason, and that reason is, is the coastline is not feasible.

No, cold hard facts about how computer graphics work. The more pixels per meter you have, and the more meters you have, the more pixels there are to be processed (illuminated, rendered and displayed) by the GPU. That number is what's important for GPU performance. Look, it's going to be taxing no matter how hard you wish it won't be so. Big map, lots of details, complex terrain. Yes, your 3060 will cry. ED will hopefully make an effort not to make it cry too loudly, part of which is not adding pointless low detail extensions.

They likely will. Do not expect Afghanistan to be light on computer resources. Unless they have some spiffy new way to optimize it, expect it to be heavy even as it is. It really doesn't need to get any bigger for a marginal benefit. Performance doesn't care about flight time, BTW. Performance cares about number of pixels per meter. At the pixel density that this map uses, that'd be a lot of pixels. On a map that's already going to be pushing it. Do the friggin' maths already, it adds up, all right. Stop thinking in real world terms and start thinking in computer graphics terms, because the latter is what determines performance.

Maybe, but a real fix would be to correct the AI. I think that, especially in light of ground unit spotting and accuracy being looked at, this is where the effort should be focused. AI should be able to get jumped from a blindspot, lose tally, and maneuver to regain it in a realistic way (and extend if it can't do it for a while). LOS and scanning simulation is already in for George and Jester, this should be extended to aircraft AI. That said, I haven't experienced this mattering much in a real dogfight. If both you and the bandit do your jobs, then the game comes down to kinematics. The opponent will generally be close enough to see without much difficulty. The period when it transitions from the dot to the model tends to, at least with my LOD settings, to happen outside the typical WVR range. It's plenty visible when you get to the point you can start thinking about shooting a heater.

Yes it is. That's the point. Read my post again. The "beside the point" part referred to map objects that, in a detailed area, would have to populate it. However, we're not talking objects, we're talking extending the map area itself. Even a perfectly flat plane going to the coast line would possibly have a big performance impact. In fact, it would have the same impact as if this area was fully detailed, but missing objects such as buildings and trees. That's how textures work (DDS ones, at least, which is what matters), the memory footprint only cares for how big a texture is, not what's on it.

TBH, the black dot shows up at a point when you probably shouldn't be able to see the aircraft in first place. Spotting is hard. In fact, it was a quite well known effect with the F-5, when it'd turn to pure pursuit, thus stopping its motion across the sky and presenting you with its razor-thin frontal profile. Many a pilot lost tally at that point, they said the F-5 "hit the disappear switch". In DCS it's not perfect, but I wonder if people aren't expecting too much.

Except that isn't true. PG is not a large map, relatively speaking, and the flat areas are ugly, but they could have been more detailed, without much performance loss, had the map not been declared completed. What I said remains true, the map is simply not exhausting its potential under the old system, and the only thing the "blank" areas on the texture save is developer effort. It's quite possible the highly detailed Dubai is bumping into some other limits regarding map objects, too, but that's beside the point.

I'm running a Reverb G2 at the native resolution, and for some reason have huge black dots that make spotting trivial at way beyond visual range. They turn into white spots at a certain distance, which is better (admittedly, that was a very shiny MiG-15, so maybe that was supposed to be a sun glint), but still meh. I can see a bogey from 30km away, even if I don't know it's there. Same with vehicles. So I don't know what's the problem with spotting, perhaps it's something in my settings, but I really hate the black dots.

Yes, which is why it's not really a problem, but people should not be expecting miracles, or the performance of a much more advanced radar from our F-16 (or the Hornet, for that matter), which compensates for the small antenna by having fancy electronics. Neither Viper nor Hornet were particularly renowned for their radars at the time of introduction, so to speak. MiG-29 wasn't, either. At the same time, they shouldn't be expecting a primitive piece of crap. This is still a modern PD radar, not unlike on Mirage 2000, just not as new as some other sets we have.

In DCS module terms that's not long ago.

Compared to the F-15 and F-14, which were the benchmarks of fighter radar tech at the time.

Hardly, the Apache was not so long ago, and it had a working preorder on Steam. I bought it there. The Viper debacle was back when I was still flying the other sim.

I got it literally on the last day it was on sale (having been out at sea for most of it), I think it was corrected by then. Besides, it's the principle of the thing. They made every effort to make it right for Steam users, to avoid them feeling like second class customers. I respect that. What I don't respect is devs going "no preorder for you, lol, go pay dollars in our shop if you want it", like ED is doing now. HB's way of handling the issue was right, even if someone had fat fingers in the end. ED's is wrong.