Litjan

Hi Nuno, and thanks for the nice words... The PROG page is still pretty much work-in-progress and we plan to finish it in a future update. Enjoy what is there already, but we don´t claim that it is fully functional (or even half ;-)) Cheers, Jan

Hi IronCondor, please give us a little bit more information - what kind of crash do you see? Does X-Plane quit altogether? Do you get a crash to desktop? Is there an error message popping up? Please post your Log.txt that you get (find it in your X-Plane root directory) after the crash, it might give us a clue! Thank you, Jan

Thanks, I will check that out! Cheers, Jan

Make sure that your default X-Plane failures are set to off. Other than that I could only imagine a hydraulic failure (or you forgetting to turn on the pumps) to cause that. We still have to code the engine fire switch also stopping the reverser from deploying, so that can´t be it. Cheers, Jan

Hi Steve, just some quick thoughts - everything that VNAV does can also be done with the basic modes. Instead of clicking "DES NOW" you can select V/S -1000 and experience the exact same thing. VNAV is a bit more comfortable in theory, but in reality you will rarely fly an approach in the real world as programmed in the FMS, and with every shortcut or extension your predetermined VNAV descent path will crumble and you are left to improvise. Don´t change your approach speed around. The autothrottle is certified to compensate for gusts, so you will always only ever set Vref+5 and just leave it there, no matter the wind. Only when flying manually you would set a higher target speed - but it is never changed during the approach, unless the tower reports a radically different wind. I am personally not convinced that the (real) autothrottle is so great at compensating for gusts, so I would maybe add another 5 in really windy conditions just to stay away from that stick-shaker experience... The "sticky" mouse could be due to your system performing some taxing background tasks that saturates the CPU and causes certain mousepresses or releases to not register. Maybe try to run X-Plane as clean as possible to troubleshoot - especially removing all plugins not needed, just to see if it helps. The problem of "reversering" the direction is known and appearantly very hard to solve, I have made it a habit to always "grab again" when I change direction. I agree that the MCP ALT button is too sensitive, I have been pestering Nils to tune it down...to little effect, so far :-) But I haven´t given up hope! There is also the element of "familiarity", I guess if you moved those buttons for 7+ years like me, you adapt... And yeah, I invite you to plan your descents - it is actually quite satisfying when it works out and it is also required when flying VNAV - even the real system is absolutely not failsafe and you need to know when to step in and show the computer who is the pilot ;-) Cheers, Jan

Hi Steve, thanks for the nice words. I skipped (well, skimmed over) your paragraph on VNAV, the green circles, and altitude restrictions because it is not really implemented yet and doesn´t work like it should in the real plane. Please resort to basic airmanship when planning your descents and use basic autopilot modes for now. This is actually the way the 737 is flown in most cases. Improving VNAV is on our agenda. VNAV will not honour the flap placard (maximum) speed during the descent - it will only honour the "lowest maneuvering speed". So if you are in a segment where VNAV wants to fly 250 and you extend your flaps, bad things happen. But if you are in a segment where VNAV wants to fly 160kts and you don´t extend your flaps, you should see the 210/FLAPS and the plane will not slow down below that. Again, this may not always work right now. It works the other way during climb. VNAV will always fly either its desired speed, or current flap setting placard speed -5, this works pretty well, already. The "B" you are talking about is actually a "all segments lit" and signifies a placard speed reversion. The autothrust kicks in and reduces power to stay at 230kts exactly. It will not try to fly a "safe" speed, it is just a pretty crude reversion mode to avoid ripping off the flaps. 230 is the absolute maximum to fly with flaps 1, it is better to extend flaps to 1 when you are well away from this placard speed. I recommend 225 for very heavy weights (>53.000kgs) or 215 when below that. You are right, you need to exit VNAV to exit the speed reversion mode, so just click FL CHG, dial the MCP SPD down by 15kts to get out, then click VNAV again (if you rely on using it during the descent). I am not covering these mechanisms in my tutorials, because they are way over the head of most users and would just confuse people. In 10 years of flying the real 737 I never triggered a speed reversion, that is the goal, here. Wait until speed diminishes and you are safely below the placard speed - and watch for VNAV misbehaving, with the imperfect implementation we have it COULD accelerate again after passing a certain waypoint. On the manipulators sticking: You need to have the manipulator on your screen (iirc) to release it - if you grab it, then look away, you can´t release it. The mouse-view works the same way, if you move the cursor off the screen, it "sticks". I agree this is not ideal, but I think it´s an X-Plane limitation. Hope this helps, Jan

You are right, Tom. X-Plane uses one setting for "maximum braking" - this can be toggled by the default button V, it also doubles as the RTO mode of the autobrake AND the parking brake. From a designer´s standpoint this is cumbersome, but the effect on the brakes is actually the same for all three applications - maximum braking. Your neck would hurt less in the real plane if you used the parking brake, because the wheels would lock (no antiskid) and the braking deceleration is actually less than in RTO...which is just the same as maximum manual braking. Cheers, Jan

Hi admroz, you are right, there should be a small "OVHT" label above the window heat test switch, I will take a look, thanks for pointing that out! Tom is right, to reset the window overheat condition you need to turn each switch OFF then ON. The effect of the switch is kind off the same in both directions. Pushing it UP (ovht) will trigger the overheat condition, illuminating all lights. Pushing it down will apply "full power", which will usually also result in an overheat condition (a real one) with the above effect, at least on the ground. Note that we do not simulate the cooling effect of airflow (yet)... Hmm, gives me an idea... The manual says, however: NOTE: Do not PWR TEST when all amber OFF lights are extinguished. Whatever that means...I have never used that on the real plane, I would think that it is mainly for maintenance use. Cheers, Jan

Not if the autobrake is working in RTO mode, as it will apply maximum braking for you. If you should disengage the autobrake accidentially (it could happen during wild steering with the pedals, or just due to startle) you need to apply full manual braking, of course. Just watch the "AUTOBRAKE DISARM" light during the RTO. Cheers, Jan

Pull thrust leves to idle. Then pull up speedbrake lever and then activate reverse thrust.Thats it. Jan

Yes, it is - I hope we will be able to include it with the next fix. Cheers, Jan

Interesting - and you could potentially save some time and land really early at your destination! I will try to reproduce and then fix it... Thanks for the report, Jan

The scavange pumps will only trigger if you turn the center fuel pumps from ON to OFF. I am not sure if the center pumps need to actually run to trigger the scavange pumps, or if you merely have to move the switch. I am also not home right now, so I can´t look it up, but I doubt that the scavenge pumps are powered through the batteries, so once your generators drop off line (like in the scenario above), they would not run, either. Cheers, Jan

Nice writeup and shots, Tom! I am glad to see that us extending the maximum database range for the plane is paying off! Cheers, Jan

I would put my money on VRAM exhaustion in combination with Orthophotos. Cheers, Jan

If you leveled off at 3000 due to the MCP altitude window commanding so while in a VNAV climb, the N1 limit indicator would change to CRZ and the autothrottle would use up to maximum cruise N1 to accelerate to VNAV climb speed. You would, however, most likely be already at this speed (since you where in the climb before) and therefore the autothrottle would not need to apply "full power" to accelerate. Cheers, Jan

The N1 limit indicator does not show the "phase" at all, it only shows the N1 limit. So whenever the plane is at the altitude you commanded through the MCP (in your case 35400) and in level flight, the limit will go to CRZ - this means that the maximum power that the autothrust can apply is cruise power. Again, this does not mean that you are in your cruise phase. Another example. You take off, and your initial level-off altitude is 3000 feet (so you set 3000 on the MCP), even though your intended cruise flightlevel is 350 (and that is set in the FMS). You will see the N1 limit go to CRZ again when the plane levels off at 3.000, even though you are not at your "cruising altitude". Cheers, Jan

Mistyped that - its BEG (Belgrade) and I was talking real flights... Ortho´s Level 10000 . Cheers, Jan

Thanks for the feedback, have a great flight to Palma (I am looking at BEO-FRA-LHR-FRA today)! Let me know how the rest of your problems pan out! Cheers, Jan

Hi Ian, this is a new one... the problems you encounter engaging the autopilot are related to your yoke being off center for sure. We read the joysticks position straight from X-Plane, so I dont think the problem is with our plane - and since you checked your neutral position, the only idea I have is checking for X-Plane random "failures" (make sure you have them off and all systems working). There are things like trim runaway, iirc. For the start-up state problems I would look to either the settings you select in the X-Plane menu, you can elect to start with "engines off" there, and that would interfere with our settings. The buzz you hear is the IRS warning horn, alerting you that the IRS units are running on battery and IRS R will shut down in 5 minutes or less... If that does not help, maybe check for incompatibilities with other plugins, things like fly-with-lua and other scripts can interfere if set up not correctly. If you can recreate the gizmo-pop up error when changing the speed limit I would love to hear the exact steps to do that so we can fix it! There are still some lingering gizmo crashes related to the FMS and we want to stomp as many as possible. Fixing them is not hard - finding them is! Hope this helps, Jan

Yes, mfor sums it up pretty well. The autobrakes are "really worried" about braking when the pilot actually attempts to accelerate (again) - so it will immediately quit breaking if thrust is applied (even a bit) or the brakes are pumped manually. Even a "spiky" hardware thrust lever (or one that does not go ALL the way to zero) will interfere with it working. Cheers, Jan

Glad you got it to work! Cheers, Jan

Hi, this type of oscillation is normal for our product - it is a byproduct of the route being really just a sequence of points, not an actual curve. So the autopilot is really following a number of straight segments that make up the curve. The algorithm to make the plane follow a complex lateral part in various conditions (speed, wind, etc.) is fairly complex and always a trade-off between accuracy and smoothness. Cheers, Jan

Hi Knight, yes, you are encountering (from what I can tell from the video) the same antivirus I/O live-checking problem that everyone else is. You can read up on the first post of this thread on how to solve it. Cheers, Jan PS: I enjoy your cool livestreams with our plane!

I am sorry, I have no idea. Do you maybe have two monitors connected? Cheers, Jan