Dragon1-1

Yes, it says that we have a society with a functioning legal system, which says that if you bought, for money, a program that's infested with malware, you're free to sue the provider of said program into oblivion, recouping any monetary damages their software might have caused (disclaimers in EULA be damned, they're not worth the disk space it takes to store them). For me, trusted program=I know who to sue if it causes any damage. Generally, not getting sued is high on the companies' list of priorities, so you can reasonably expect a commercial product to be free of things that would give you a reason to sue. Seeing as I like to buy things on sales, I'd likely know about any legal scandals involving the program before buying it. Sure, commercial software can be compromised, but that typically happens to stuff meant to be installed on servers with access to really important data, or at least workstations, not normal computers. Standards for professional computers are, of course, higher (but then, nobody installs games on them, and hopefully not any 20 years old software, either).

In case of admin, there's a very specific reason why you might need to run a program with admin rights: in pre-UAC days, shoddily written or hacky software (including many games) would often demand unconstrained access to all of the computer's resources, and would barf if such access was not provided. Games in particular would sometimes exploit outright bugs in the OS in order to squeeze a bit more performance out of the system. And of course, a programmer working on a machine with admin access could simply not conceive that anyone could be trying to run the program without it. That's why the introduction of UAC resulted in much wailing and gnashing of teeth from such programmers and from the users of their programs (and contributed to Vista's bad reputation). Turning off your virus scanner is typically suggested by people who don't know exceptions exist, for the exact purpose of letting a trusted program do its thing without compromising your protection. DCS does occasionally require doing just that.

Well, a firewall is handy if you want to be able to show the middle finger to various trackers, you can have it cut off any program that you don't want phoning home.

For a gaming PC, you don't really need anything but Windows Defender. I use Comodo, but that's more of a firewall with an AV attached, and I suspect I don't really need it at this point (I got it installed a long time ago).

It still has regional prices in my country (with exceptions, unfortunately), so I'm sticking with it, but it entirely depends on whether Steam gives you a good deal or not. If ED introduced regional pricing, I could switch, but not if they want me to pay as if I was earning EUR.

I'd expect there'd be plenty of data for Germany of that era, including maps and such. The border that they showed looks more 80s than modern, though I haven't actually been to the place. Due to huge US presence and general NATO interest in the area, it's quite well documented.

Sadly, without analog brakes the warbirds are going to be very difficult to work with, due to physics of their landing gear. IRL, in a taildragger you almost never give it full brake unless you're at standstill and want to hold it down. With proper toe brakes, the 109 is hard enough to taxi, but it's doable (and it's actually easier than Spitfire). In your situation, the Spit is probably going to be a better choice because it has a hand-operated brake lever on the stick.

In the future, there will be a full world map, which will allow flying to Afghanistan from CONUS, if you were so inclined (and had the time for it).

Probably same place where Afghanistan is - it'll be there when they can provide a date.

They actually answered that when they made that policy change (although that mostly concerned 3rd parties). The reason is to let developers know what's in the works. It would suck very much for a prospective 3rd party dev to spend hours coming up with something they can show ED as part of their proposal, only to be told "sorry, we're working on that already". In the end, it works much better if they announce a project early. The bottom line is, long term plans are long term. I'm fine with that approach, especially as an SP player, I generally don't buy (unless there's a good preorder deal) until there's a campaign available, anyway.

Are you in the US? I wonder if it has anything to do with US using a lower voltage. It shouldn't, given that it's all converted to DC, anyway, but weirder things have happened.

That's the reality of flying trainers. If you firewall the throttle, it'll take it as a suggestion that you want to go faster. It'll even give it a try, if conditions are right.

I don't need to. It's you who are grasping at straws to claim that non-detailed areas are cheaper than they actually are. All evidence we have points to that not being the case, from statements by ED to how the maps we do have are designed and how they perform relative to one another. As I said, the solution we have is more clever than my simplified outline (however, the old terrain engine did work very much like I said). It's also quite clear that this cleverness has limits. SA map has inferior performance even if you're flying over water, and while sheer size is no doubt not the only way to bog down a map, you really don't want a global performance penalty on something like Afghanistan. The only assumptions I've made was that the ED's solution works in a way that makes sense, that it does not do anything revolutionary that was never attempted in any other engine, and that both ED and 3rd party development updates (which give us glimpses of how it works) are reliable. If you're going to dispute those, you're going to need to show some evidence.

...which is why it performs the way it does (badly). When it started out, the terrain wasn't particularly detailed, because Falklands are pretty flat. Worth noting, terrain elevation in DCS (and in most other non-voxel games, in fact) is not stored as a mesh, like for example a building - it is stored as a texture. A single pixel on the texture corresponds to an area on the ground with uniform characteristics, and its value (a classic elevation map uses a grayscale texture) corresponds to elevation of that area. How big that area will be is one of the major decisions that you must make when first setting out to design a map. So, how do you expand the map after its elevation mesh resolution has been decided on? You make the texture bigger. Which means that the GPU now has a gigantic elevation map sitting in VRAM, with all the problems that this implies. Yes, this can be done, especially if the original map is on the conservative side. That doesn't necessarily make it a good idea. Now, the above corresponds to how a map like Caucasus works, using the old map tech. The new map tech is smarter, which is why something like SA map is possible at all. However, that doesn't mean it's without limitations whatsoever. In case of SA, it sacrifices detail to produce performance that is just barely on this side of usable. Try flying on the South Atlantic map, then, and then imagine it all had a level of detail suitable for helo ops. This is simply a function of how DCS engine does textures. This is also why (what most people don't seem to understand) water and low detail terrain are not free. They're easy for the developers to make, sure, but they do cost performance, which is why aside from one map noted for its bad performance, we don't have many terrains with countless miles of open ocean around them.

Yes, exactly. Obviously you never programmed anything more complex than an Arduino. In a larger program, you can't just arbitrarily change your entire design philosophy because some tradeoff you made early on (and which seemed like a good idea for whatever reason) came back to bite you once the program is up and running. Programming simply doesn't work like that, especially not when you're writing to optimize for performance, as opposed to ease of maintenance. The limits I'm talking about is not some variable they set in the code, it's a consequence of how the code does what it does. If, as in case of HB's Phantom, you hit an issue that turns out to be a showstopper, you scrap the whole system and start again. I doubt, however, that it's worth it for ED in this case. You especially don't change the fundamental philosophy of the terrain engine once the artists have already started work. South Atlantic was made with the intention of being much larger from the start. Hence, things like texel density of various textures that define it would have been picked to account for that. I don't have that particular map, but from what I saw of the comments about it, it offers poor performance and the detail level is more Caucasus than Syria, despite being a fairly empty map. ED is making Afghanistan for small scale helo and vehicle ops, so they understandably decided that's not what they want.

Anybody with basic knowledge of game engines knows that it's not. The technology to render something like a terrain is typically based on some assumptions about size and shape of detailed area, which can mean that you can't have a flat, untextured area on the map, or that it provides little in terms of performance benefit. Remember, an 8K texture with half of it filled with white is still an 8K texture, even if a large part of it is filled in with one color. While this example applies mostly to the old terrain system, it doesn't mean the new one is free of such limitations, though it does seem to be more modular, at least.

It is working correctly, from what I gather, this is just a display bug. FYI, the BA you set on the MFD does not actually affect the bomb, the setting is a physical switch on the casing that has to be set on the ground (something we can't do in DCS yet), and you later set it on the MFD to match, so that the jet provides you a proper solution cue. Since you can't have it at anything other than 1500ft, the setting on the MFD doesn't actually matter AFAIK. New fuzing will introduce both a way to change the actual BA, and necessitate the proper data entry for it to work.

That would make it a little under a half of the war (yeah, it was way too damn long, why do you ask?). It's a little strange that they ran ops from the water instead of moving their aircraft to some friendly place on land, but I've never accused the military of making efficient use of the taxpayers' dollars. Then again, you could say the same about this whole sordid affair.

I'd ask to be put in touch with the original owner, might be worth a try. Alternatively, WinWing might indeed be able to sell the part.

First thing, ask the person who sold it to you, they might have it. It's a tiny thing, so shipping should not be much, they could probably send it in an envelope. In fact, there should be two detents like this (although the other is not as useful). I never saw them available for 3D printing, maybe because normally there's no need. It's not a complex part, but you'd need one to base it on.

It should have come in the box. It's a separate piece that screws onto the track.

Isn't that just for the early OEF, though? Specifically, the high intensity phase when they were just bombing the crap out of the country. For most of the war in Afghanistan, I think it was mostly USMC Hornets out of Kandahar. Remember how the war in question went. The US rolled in and basically took over in one year, and then played whack-a-mole with the Taliban for twenty. The latter part was where the problems started and the war became something more than JDAM/LGB practice.

Just because a squadron is part of the USN doesn't mean it flies from the boat all the time. FYI, carrier-based missions could take in excess of ten hours during the initial phase of OEF, with multiple AARs in country. IIRC they moved to Kandahar (which we will conveniently have on the map) as soon as they could, because flying such long legs did a number on both the aircrews and their aircraft.

Worth noting, AFAIK most Hornet sorties in Afghan flew from land bases. It's a landlocked country with enough US-friendly territory on its borders that flying directly from a carrier would've been a waste of fuel.

DCS, until recently, only utilized a single core, and even now, it only utilizes a single logic thread, muticore being for graphics only. That's what makes CPU the bottleneck in most situations. And yes, this does result in a multicore CPU being "bored" in many situations, with one core running at 100% and the rest at much less.