SwingKid

I don't think this is true. Do you have a source for it? I'm not an aerodynamicist, but my understanding is that Mach 1 is an inefficient cruising speed, not a "bump" in the way you describe. That is - for a little extra energy, you could be cruising at Mach 1.3 instead of just Mach 1, thus making supersonic flight more cost-effective than transonic flight. But it's still extra energy, not less energy. If it was less draggy at Mach 1.3 than at Mach 1, then aircraft would quickly accelerate past the sound barrier on their own, even while the pilot was reducing the throttle. This doesn't happen, AFAIK. You still need to increase throttle all the way through transonic speed. Of course, missiles don't cruise at transonic speed at all, but rather just accelerate through it to supersonic speeds, where they encounter the levels of drag that affect their range much more.

Do you mean to say that there is less drag at Mach 2, than there is at Mach 1? I think you'll find that's incorrect - it's the drag coefficient that spikes at Mach 1, not the total drag. The energy saving is only if you stay below Mach 1. Which the missile doesn't do.

How useful is it to be talking about supersonic launch speeds for these things anyway? Who fights like that? At launch, you want to minimize your fighter's own closing speed, so to maximize F-pole or A-pole.

One of the problems is that in some official-sounding sources, the AMRAAM speed is given as "Mach 4 above the speed of the launching aircraft," or "Mach 4+". If we assume the mass of missile and propellant is known and the impulse is the same as HTPB (about 250 s IIRC), then even if drag is zero, the missile cannot reach Mach 4 (when fired from rest) by simple F=m*a, and the statement is provably wrong. At that point, you begin to wonder whom you can trust. Another problem is the whole boost-sustain story. You would expect that with this type of flight profile optimized for longer range, the AIM-120 conserves fuel by cruising at a lower speed, so that it doesn't waste energy fighting against higher-than-necessary supersonic drag, and is thus able to fly longer and farther. But the same sources that describe the AIM-120 flying farther than the AIM-7M also invariably claim it flies faster, by far - the AIM-7M speed is only claimed to peak at Mach 3.5, versus the AIM-120's erstwhile "cruise" speed of Mach 4. The claimed ability of the AIM-120 to fly both farther and faster than the AIM-7M, by such huge margins, cannot seem to be explained by known advances in propellant technology. In fact, the AIM-120 propellant impulse seems to have been reduced with respect to AIM-7M, twice, in order to give it (a) a "smokeless" motor and (b) a slower-burning sustain thrust.

How can I move an airbase (like you did for the Merzifon mod)? At this time, relocating a Lock On airbase from one map location to another requires binary-file computer programming ability. Generally speaking, data for a Lock On airbase is stored in three files: (a) the ".scn" scene file, (b) the ".rn" runway file, and © the "Onlay_vpp.sup" file. The ".scn" file is by far the largest, and contains the positions of all map objects, including airbase buildings, trees, etc. The objects in this file are organized into a complex data tree structure of "visibility cubes" to help the Lock On graphics engine display them more efficiently. That is - when your view is looking in a certain direction, some regions of terrain will be visible, and others will not. Instead of checking each of the 800,000 objects in the scene file to see if it needs to be drawn or not, the objects are organized by their location so that the graphics engine can quickly skip through large numbers of them at a time. I call it a "data tree" because the "visibility cubes" contain smaller sub-cubes, which contain smaller sub-sub-cubes and so on, more than a dozen layers deep. When you move an object from one location to another, then, it's more than a matter of simply changing its coordinates - you need to update the structure of the entire data tree of visibility cubes - possibly adding new cubes and/or removing old ones. Doing this by hand is a nightmare of mathematics, keeping track of dozens, hundreds or more memory addresses that need to change consistently and accurately. Fortunately, a computer program now exists to automate most of this difficult work, and this is how many non-programmers have been able to add trees and other new map objects to the scene files. The program itself is not the easiest thing to use - the instructions are complex and it's easy to permanently over-write your 90 megabyte scenes files. It may also take eight hours or so for the file to be created, due to the huge data processing that must be done - and the output scene file is usually about 2x larger than it needs to be, since it uses a less efficient algorithm than whatever ED uses to make the original scene files. The ".rn" runway file contains the location of the airbase icon on the map. It also contains all the taxi routes used by AI aircraft at the base. It also contains a duplicate copy of all the airbase building object coordinates, because this file also controls things like opening shelter doors and runway lights when aircraft approach. The co-ordinates in the ".rn" file are not organized into very complex data structures, making this file the easiest of the three to hack. With a hex editor, you just find all the floating-point values that represent coordinates, and replace them with whatever you want. Note that there are hundreds, maybe thousands of them - all the airbase building coordinates, plus all the waypoints for AI taxi routes. So, you will really want a computer program to move all these coordinates together for you in one pass, and do it hundreds of times at all the right points in the file. Although this is a much easier programming task than trying to modify the scenes file, the difference is that I have NOT made a program to do it for you - and have no plans to do so at this time. I created one custom program to move Razdolnoe to Merzifon, and that's it. Any other airbase you want to move will require a new computer program to be created. The ".sup" onlay file is a bit more of a headache - and is actually the one you should probably work on first, if you're still serious about moving an airbase. This file contains data for the actual runway and taxiway "textures" that you see on the map and in the game, that allows your landed plane to touch down without sinking into the dirt and getting stuck. It also contains other airbase textures like grass, perimeter fences, etc. Like the .scn file described earlier, the .sup file organizes its data into complex structures, so that you can't just change a coordinate from one value to another to move an airbase. At least, the data structures in this file are a little less complex than in the .scn file: the Lock On map is simply divided into a checkerboard pattern, with squares about 20 km per side. Runway shapes are individually drawn within each square. To move a runway, you don't actually rewrite coordinates, so much as move the desired runway surface from one checkerboard "square" to another. Because of this, airbases can only be relocated efficiently in distance multiples of 20 km. This is one reason why it's really only practical to move airbases into the flat undetailed portions of the map where there is no relief terrain - when you can only move the airbase by 20 km increments, you don't have the precision necessary to be able to fit a relocated airbase into a sweet spot between some mountains. Since there aren't thousands of numbers to change, this is one file you could hack manually with a hex editor - there are only a few dozen pointers you need to move around and keep track of changes. That's what I did. Again, I have made no computer program to help others do this, and have no plans to do so at this time. Good luck!

Is Israel still planned for inclusion?

What is the "Som" add-on? Do you have a link? Maybe your mission has a different "Scenes" level (Low, Medium or High) in the Options menu?

Hmm.. this happened when the maintenance area popped into view, or when you actually taxiied your player-controlled aircraft there? i.e. what if you just moved the camera there with F12 view? I wonder if this is reproduceable.

We don't actually know that the old WCS has this limitation. It just depends which sources of data we choose to trust, and which we consider as "fairy tales." Apparently, we can't agree about that. The WCS limitation, as far as I understand, doesn't distinguish "one type of short range missile." Rather, there is just one physical two-position switch in the cockpit for AAM selection, labeled "inboard/outboard." So, if the middle station missile is different from the outer station, the pilot has no way to select it. (Whether this makes such a loadout actually illegal, rather than simply inconvenient, is IMHO an open question.) There exists for many years already Easy Tartar's description of the 9.13S WCS at http://www.sci.fi: http://www.sci.fi/~fta/MiG-29-3b.htm According to him, this version has only one additional "SNP-1/SNP-2" switch in the WCS. Therefore, this version is also incapable of distinguishing between outer and middle pylons. ED does not seem to often reply themselves in this forum about the "RVV-AE on the outboard pylon" issue. Their reason for believing in such a restriction seems to be based on a poor understanding of ARH missiles - i.e. the misconception that an ARH missile can only be carried at a station that can also carry a SARH missile, since they are both radar missiles, and require waveguide to be installed in the station to "synchronize" the AAM with the fighter radar. (i.e. ED thinks that allowing the RVV-AE on the outer pylon would open the door to allowing the R-27R there also - which is undesired.) This is (a) not having anything to do with the reasons of weight etc. that are proposed by other posters in this forum discussion, and (b) unlikely to be correct. An ARH missile likely does not need to be phase-synchronized to the fighter radar in the same way as a SARH missile. The AIM-120, for example, is carried on every station capable of carrying an AIM-9, and by aircraft, like the F-16, which can't carry SARH missiles at all. The most interesting thing about this entire debate (for me) is that people have reached their strong conclusions about whether or not the RVV-AE can be carried on the outer pylon, without ever discussing SARH missiles at all - and from what I can see, ED has said nothing to bring it up. It's as if this whole years-long topic doesn't actually interest anyone, really - and yet, it continues anyway.

What do you mean, "in some pictures?" To have R-73 on outer pylons with R-77 on the middle pylons is a standard Lock On loadout. That should be illegal.

What does this mean for RVV-AE on the outer pylons?

My data says the R-73 has 7700 kgfs total impulse, with "4.1-6.8 s" burn time.

On a strategic level it was a fantastic radar. It practically wiped out the entire US fleet of F-111 and A-6 and made the B-1B and Tornado IDS obsolete overnight, without ever firing a shot. By contrast, the F-15 and its radar killed what - 100 planes?

Yeah, there's only one quick little blurb about him, and then the magic fairy technicians "descended upon the base" in their UFOs or whatever and made the radar sabotage problem go away overnight. What a convenient explanation for the lack of evidence. They also make it sound like nobody in the USSR listened to anything on the radio but CIA Radio Free Liberty. They even attribute Zuyev's whole defection plan as being inspired by one of their news reports. You be the judge.

Oh, you mean the CIA believed Tolkachev sabotaged the radar? Because the book's version of the events (about which you seemed to write, "the description seems fine") attributes this belief to the Soviet military. My reason for suspecting a CIA author is because such description seems hard to believe.

"Nonsense." :) Such a stupid excuse deserves all the contempt it gets and more. Any system that passes a "broken design" through acceptance testing need not waste its time looking for spies. Intelligently directed sabotage is easy to find and fix - if your system can't filter that, then honest bugs are going to give you ten times as many problems. With quality control so incompetent as to allow a "sabotaged" product through state acceptance trials, no sabotage would ever be necessary. Normal bugs would get through such system naturally, that a smart spy or intelligence agency would simply take credit for, in order to get paid for doing nothing. If Tolkachev had anything to do with it, we would probably know by now what it was he actually did. Instead, we have only the same vague rumours and fairy-tales we got from the CIA when the Iron Curtain was still up. A more likely story is that the CIA got him killed by giving him unrealistic instructions that were sure to get him caught, and now, after he was caught and killed, they're trying to paper it over it as a success. Tolkachev was no dout a real spy and able to steal a few documents, and perhaps made a convenient scapegoat for everything under the sun. That's a lot easier to imagine than that he managed to get a non-functional engineering design past testing and into production. I sure wouldn't be able to do that to any of my antennas and get away with it - and the products I work on surely involve fewer people working above and alongside me than something as complex as a fighter radar.

in other words, "it's not a bug it's a feature?" :) I've heard that one before.

digital vs. analog

I don't have the text in front of me - it could be that he was using his radar in Medium PRF "Pursuit" or "Auto" mode. In that case he could have been seeing sidelobe clutter, esp. when flying low over water.

The writing style in this book is such perfect english, and the narrative so "Tom Clancy"-like, I'm halfway convinced that many of the thoughts expressed within it are those of his American CIA handlers and "co-authors," and not Zuyev's own. That bit about Tolkachev's sabotage, for example, seems to appear out of thin air without any eyewitness testimony or explanation - as if the CIA injected that part of the story just to help corroborate their own claim of operational success. Not long ago, other readers have also discovered minor errors in the description of some of the electronics. That said, it's still a classic MiG-29 description - probably the best available at the time.

What does that have to do with the title of the photo? ;)

So what, it carries less maximum weight than 9-13S? http://airwar.ru/enc/fighter/mig29s.html Weight doesn't seem to be a problem.

http://www.ecf.utoronto.ca/~pavacic/lomac/proof_that_ed_hates_us.jpg ;)

UH-1 Hero among pretenders.

http://maps.google.com/?ie=UTF8&ll=44.537801,38.101616&spn=0.003449,0.009978&t=h&z=17