FishBike

Q: "Did the Huey suffer from vortex ring state?" A: "No, it died very quickly."

At the top right corner of the RSBN control panel, there are two switches. In the manual they're numbered LV21 (RSBN azimuth correction) and LV22 (RSBN distance correction). I have been turning these on when using the RSBN and it seems to work fine. Others I know leave them off, and a tutorial video I saw today also left them off. I can't find any further information about these in the manual, or anywhere else for that matter. What do they do?

I had the same problem in a mission today. The "lock" tone continued after all enemy aircraft had been shot down, and all friendly aircraft had turned off radars. The only radar that was operating was on the ground, which doesn't normally seem to trigger the RWR at all.

I had the same thing happen to me yesterday, in a mission flown at 7,000-7,500m for quite a long time. The gauge read 50 for me as well. When going through the startup for that mission, I accidentally clicked on the wrong lever to lock the canopy and ended up locking it and sealing it in one click. I don't know if that resulted in an unpressurized cockpit (the cabin altimeter read 3,000m like it normally does) but perhaps that is a factor.

I mapped the TDC range axes to one of the rotary controls on my X-52 Pro. Works perfectly.

Here's what it says in the flight manual: "Angle-of-attack indicator YYA-1 shows the current angle of attack to the pilot. The scale of the YYA-1 indicator is calibrated in degrees of local angle of attack (corresponding to the deflection angles of the vane of transmitter UYA-3) with a scale increment of 1 degree; the scale is numbered every 10 degrees." The key words there are "local angle of attack", e.g. the angle of the AoA vane, uncorrected for effects of local airflow around the vane. So it is calibrated in degrees but does not read the actual angle of attack.

The real-world flight manual for the MiG-21bis says this gauge indicates the "local angle of attack" in degrees, e.g. the degrees of deflection of the AoA measuring vane. It also says that stall = 33 degrees.

You may want to check your axis mappings. After doing the upgrade, I found two more axes had been mapped to the brake lever, so it was on all the time pretty much. The takeoff performance is somewhat reduced with the brakes on. ;)

I think this might be improved in the latest patch. Before updating, I did a flight where I climbed to 10km and then stayed at or slightly above that altitude until the oxygen pressure gauge read 40. That took 23 minutes from the start of the takeoff roll. After the patch, I did the same thing, and it took 40 minutes. So allowing for a few minutes at the start of the mission where no oxygen is used, it seems like it lasts about twice as long now in that test. Either that or I messed up the test somehow. Anyone else have any results to share?

I'm not sure what I am missing, but for some reason I'm unable to get the Sabre's cockpit to pressurize properly. I verified I have the canopy closed, the "press/ram" switch in the "press" position (on the left console), and the pressure switch at 2.75 psi (though it's the same at 5 psi). What I see is that cockpit altitude = actual altitude, oxygen gets used up quicker than expected, and toggling the pressure switch between 2.75 and 5 psi doesn't seem to do anything. I must be missing a step somewhere.

You have it right. The mission editor correctly shows the physical location that stores will be loaded on, but the numbers shown there do not match the station numbers selected from the cockpit.

I don't know about the MiG-21 specifically, but it's normal for transonic and supersonic aircraft to need significant nose-up trim as they accelerate up to and past Mach 1. There's even a name for this: Mach tuck.

The bug seems to be that the oxygen is consumed too quickly. So you can fly at high altitude for a little while, but must keep an eye on the oxygen gauge and return to low altitude before it's all gone.

I'm not sure if this is a bug. When shutting down at the end of a flight, if I turn off the battery switch first, and the try to turn off the fuel pumps, they stay on. If I turn the battery switch back on again, then I can turn off the fuel pumps. It seems like the pumps should turn off when the battery is turned off, even if the pump switches are still on.

This happens to me on every flight where I stay at 30,000 feet long enough. I'm sure it's meant to be simulating pitot icing, but it happens even with pitot heat on (unless I am not turning it on correctly). It also causes the vertical speed indicator to read 0, which doesn't seem right--that instrument should work based on the static system only. The altimeter, that also works on the static system, continues to function normally.

That's normal, it becomes quite unstable in roll as you approach Mach 1.

I've done a few flights lately that involved getting the Sabre up to fairly high altitudes (30,000+ feet) and have consistently run into what looks like a problem with the pitot/static system. Symptoms include: the airspeed indicator getting stuck at its current reading, the machmeter reading much higher than it should (Mach 1.2) and the vertical speed indicator getting stuck at zero. The altimeter still works fine, though. These problems go away after returning to lower altitudes for a while. I'd call it pitot icing except for a couple of things. I have pitot heat ON when this happens, and the vertical speed indicator shouldn't be affected by that. Any thoughts what this is? e.g. pilot error combined with a bug? Just pilot error? Just a bug?

I went into the folder with all the F-86 cockpit sounds in it. This sound comes from "TransferPump.wav" so it would seem to be the sound of a fuel transfer pump.

It has been a few years since I played with the Level D 767 add-on for FSX, but the big difference compared to the A-10C is the sophistication of the autopilot and flight management system. With the 767 FMS you can program in a complete flight plan, but then it will interact with the autopilot to fly it for you with almost no manual input. It will figure out where your top-of-descent needs to be for a perfect landing approach. It will figure out the most efficient speed to fly at based on a "cost index" you give it. The 767 autopilot has a ton of different modes as well. Not just holding altitude, heading, and airspeed, but fancy stuff like the "flight level change" button that will make an altitude change as quickly as possible using full throttle (for climb) or idle thrust (for descent) while maintaining your selected airspeed. Oddly I felt quite at home the first few times running through the startup sequency for the A-10C as it has some similarities. It was strange to realize the 767 is faster and climbs better, though!

Myself and two friends flew a mission last night which involved a lot of time flying in icing conditions. The mission uses the template "snowstorm" weather with the winds removed, and we spent all of it within a few hundred feet of the ground. On the way back to our landing field after quite some time in those conditions (close to an hour I think), all three of us lost airspeed indication within a few minutes of each other. The airspeed indicator acted like an altimeter instead, just as you would expect from pitot icing. However, all three of us confirmed we had pitot heat switched on. I had the same thing happen at about the same place when I was testing the mission the day before, too. I'm not sure if this is a bug, pilot error, or something working the way it's supposed to be. Is there some way we can diagnose what happened? Is there a total time limit for how long pitot heat can be on? From testing the mission earlier, I know the same problem will happen pretty quickly if pitot heat is off.

I'm having a very difficult time landing the Mi-8 on unpaved surfaces. What seems to happen is no matter how little sideways motion I have, and how gently I touch down, it will suddenly bounce violently after the wheels touch down. Often one side does this before the other, tipping the helicopter over rather quickly. When landing on a paved surface, it doesn't seem to do that. Is this a problem with pilot technique? A bug? The Mi-8 should not be landed on dirt?

Has anybody noticed anything funky with headings in this latest patch? I have a mission I've been using for a while and now the headings generated by scripting are suddenly off by 180 degrees, and so is the radio compass indicator at startup. The standby magnetic compass is right though. This is in the Huey. Now it could be I broke something in my script trying to fix it for the previous patch. And at the same time there's been a change in the startup procedure where you have to set the RCI to the correct heading now. But it seems odd this all happened right after applying the Aug 2nd patch.

I just finished building something like this for a single smoke colour. I'm not sure I understand exactly what you want to do though. It sounds like there will be something that happens in the mission to make the smoke appear. Will all three colours appear at the same time, or are there three separate events in the mission that will each make one colour appear?

Has anyone been able to get this to work? I figured out that my expression conditions were gone, so triggers that use them fire all the time. I put in a LUA PREDICATE condition instead but am unable to get the trigger to fire at all with it now. Even a predicate condition of true, or return true, doesn't seem to make it fire. Has the syntax changed as well compared to what EXPRESSION wanted? Edit: so it appears the LUA PREDICATE condition doesn't work at the moment. See http://forums.eagle.ru/showthread.php?t=110430

That is one way I've done it. Another is to use trigger.action.outText to display text on the screen, which makes it easier to tell when in the mission something happened.