Litjan

Well, you know the old saying: "Get in, sit down, shut up, buckle up and hold on!"

Hi guys and greetings auf den Hahn! Thanks for pointing this out and Tom´s excellent-as-always analysis of the problem. I will put this one onto our bug-tracker to fix. Daniel, when you get this console pop-up, the code has faulted and you can´t really use the plane anymore. You can reboot gizmo (flash-symbol on right-hand pop-out menu) and then re-enter your data to continue your flight, though. Cheers, Jan

This may shed some "light" on the issue: http://forums.x-pilot.com/forums/topic/13308-faq-no-cabin-llights/ Furthermore, there is a weird quirk were the effect of the switch takes a few minutes to register! There is some confusion with Laminar on how LIT textures should spill light, cast shadows, etc. Since we are planning to redo the whole cabin for one of the next versions (with 3D lights) we are reluctant to spend much time fixing the issue for the next interim patch. For now I suggest to simply keep the passengers buckled up if you want a realistically dark cockpit - just pretend there is turbulence forcast, and you don´t want to get sued by any US passengers on board... Cheers, Jan

Hi and sorry to hear that you have a problem with that! If all else fails, you can always use the "ground service" menu to set the fuel as well! Cheers, Jan

Hmm, I think if the battery switch breaks, it won´t be dangerous. Either it breaks on the ground, in that case you can´t even power up the aircraft. Or it breaks during flight, in that case you will notice when you try to shut down the aircraft for the night. There could be one good reason for turning it off during the flight on purpose: If both generators fail and the APU does not start, you are down to 30 minutes of flight powered by the battery. If you are 1 hour away from the next airport (and it isn´t CAVOK all the way) you would face the descision to either ditch/force land now, or to switch of the battery. Now you can fly for as long as you want (use dead reckoning and the standby instruments) - then when you are close to your airport, turn everything back on, align IRS in ATT mode, fly an ILS approach. I am fairly certain that switching off the battery will also disconnect the generators - you can´t see the dependency from the regular wiring diagrams, but I think it switches the exciter field of the generator breaker solenoids off. Cheers, Jan

BGSF or BGBW? Map looks like you flew to Narssasuak instead of Sondrestromfjord. BGBW is a bad-ass airport, but I think Icelandair flies 757´s into that? BGSF is quite a big airport and ok unless you have to circle in to land westwards. Very cool tour, and I am happy to hear that everything worked well! Cheers, Jan

Hi, there could be several things causing this, so please check them off one by one: A very hot ambient temperature combined with high field elevation An inadvertantly set high TASS in the FMS Your joystick interfering with the virtual thrust levers during takeoff run - some people try to move their hardware throttle "along" with the advancing thrust levers - this will cause them to snap back to "manual control" when the plane passes 84kts (THR HOLD), and the throttle being now controlled by hardware throttle again. To avoid this, follow the recommended procedure: Click TOGA button, immediately advance joystick throttle to forward mechanical stop (full power!). A spikey joystick throttle that "regains" control of the virtual thrust levers by accident. If all this fails, please post a video of a takeoff where this happens and we will go from there. Cheers, Jan

Hi Andreas, yes, unlike on the Airbus, a lot of stuff hinges on the battery (like the power to the generator breakers), and switching it OFF will leave you with nothing but the hot battery bus (and ground service, if there is a GPU plugged in and the switch is toggled - this is not modeled yet). Onlike Airbus, Boeing relies on their pilots to have a brain and not turn off the battery switch until they have a VERY good reason to do so and understand the consequences ;-) The IRS units have DC backup, but not on the hot-battery bus, so they will die, too. Pressurization should be able to be regained, you need to get the cabin back into parameters first with the Standby or Manual mode, then you can re-engage automatic mode (switch to standy and back). You can re-align the IRS in attitude mode, but the position will be lost - however the GPS will work, so that is not the end of the world. The "huge speed" inthe MCP speed window is definitely a bug, some situation that you guys are getting yourself into that we haven´t tested for... I will try to recreate this myself and then we put some sort of stopgap to the maximum speed. I am a little wary of tinkering with that code too much, Tom and I want to really rip the guts out of VNAV and then sow everything back in neatly in a future update, and this will likely affect many of these quirky speed calculations... Cheers, Jan

We are still investigating this - I don´t see this on my end. Probably some interaction with some other plugin that changes art-control dataref (to achieve different colours of the sky) or such. We have had some reports, so you are not the only one - but still trying to nail down the reason. Could you attach your LOG.TXT so we can see which other plugins you have running (that may cause this)? Thanks, Jan

This is probably correct. We use the knob to "trigger" the trim moving - but not the other way round. Something to consider for an update, thanks for pointing it out! Jan

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