Dragon1-1

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.

They are, but there are still blind spots, like JDAM target points in the Hornet. IRL, they would've been loaded via DTC, not punched in by the number while sitting in the cockpit. Also, you have some customization options that currently aren't present anywhere but in config files (which get eaten every update).

Excluding systems like Combat Tree, you don't get a distinct "foe" response, just no response whatsoever. The problem with IFF is that when it responds, it sends out a signal, which can be triangulated back to the source. So, Mode 4 gives no response to an incorrect interrogation. Other modes are for finding a specific aircraft (Mode 2) or a specific mission (Mode 1), and they simply respond "match/no match". Combined with a list of codes for all assets operating in an area, this can potentially factor into a decision to engage (although I wouldn't rely on it), but those two modes would be turned off in Indian Country, as anyone interrogating those modes would get a response. So, if the bandit haven't detected you on radar, but ran an IFF sweep and saw a strange "no match" readout where there shouldn't be anything, he'd know to expect to find something in that direction. Combat Tree did more or less exactly that: interrogate the MiGs' transponders to find out where they were. This system could be said to have a true "foe" IFF response. With later systems, an incorrect Mode 4 response would be highly unusual, since it would suggest the aircraft did have proper codes (since it accepted the interrogation), but somehow managed to mangle the reply.

Actually, the stick on the real F-16 measures displacement via LDVT transducers, not force. However, displacement is coupled to force via a very strong bar spring, so in practice, it's like using an actual force transducer. The real Viper's stick only moves a little, but the transducers are very precise.

Even if so, it seems like it was removed in the C, and only added back much later on, bound to a different button. I would expect that with the introduction of avionics, strafing wasn't anticipated to remain an important mode of attack.

That's exactly what boresighting is. You're trying to get two sensors, in different places on the jet, to point at the same thing.

First of all, MiG-21 does not have toe brakes, but a lever which is actually on the stick in the real aircraft. You also have two bindings for the lever: an axis and a button. They do the same thing, the button is for when you don't have enough axes to assign the lever. Finally, there is an emergency, manual brake handle, which is used if there is a failure in the primary brake system, which has a limited amount of compressed air to work with. Such a failure may be caused by something as simple as leaving the gear handle in up position, so it's good to have the emergency brake handy. Nose gear brake is actually a switch, and what it does is toggle the brake on the nose gear. MiG-21 can only be steered on the ground by differential braking, accomplished by moving the pedals and pulling the lever. As such, the nose gear brake shouldn't be enabled for taxi, because it would prevent the front wheel from rolling and just stop the aircraft instead of turning it. So you have to turn the front brake off for taxi, and turn it back on when you want full brake effectiveness.

MiG-21s were threatening because they would sneak around the Phantom's back and bushwhack any flyboys who didn't watch their six. The F-4 will undoubtedly dominate if it can engage the MiG-21 at long range, but if the MiG is smart and the terrain not flat, it won't come to that. Also, while the actual (older generation) MiGs that Phantoms faced in Vietnam were generally better dogfighters, our bis is no slouch, either, particularly with the special afterburner on. Whether an F-5 is a safer target or not depends on the situation at hand, because it can be pretty nimble, and it'll outturn your MiG-21 quite handily. The soft wing Phantom should be a decent turner, but not on F-5's level. Either way, as it often is with older jets, the pilot's skill ultimately matters the most. There are ways around BVR and besides, the early Sparrow barely qualifies there. When the fight is down to guns and rear aspect heaters, it's all about the pilot.

Su-27S would be great, although note that the aircraft hasn't changed that much since, the early variant is still in service in Russia. It might be possible, but it's much less prolific than MiG-29A. Early F-15C (the A model came earlier) and F-16A would be great for the 80s and 90s Cold War. Incidentally, they've both been very popular in old school flight sims. IMO, those were probably the best years of combat aviation, with a large variety of iconic planes, advanced avionics but not completely a flying computer, and limited Fox 3 combat.