Litjan

It is optional, and we don´t model it.

Hi Makaros, I think you are doing everything correctly - when entering a new SID, the old SID should be cleared away. Of course it is very unusual to put in a random SID, usually the pilot knows very well which SID he will fly. It is a different story with the STAR, that is changed regularly during the flight. If you have started flying your SID (or STAR) and then subsequently change it, the FMS will retain certain points of it, because you are "already using it". Cheers, Jan

This is perfect, thank you very much for doing the video! Cheers, Jan

Just to follow up - I entered the same routing you did and did not get a crash... there may be some additional info we need. The best way for us to recreate the problem is to get a video where you tape entering the routing (everything from the moment the simulator stops loading until you get the error-log window)... Cheers, Jan

Thanks for the report, I think we can track it down with your data provided... Cheers, Jan

If you have gizmo and a X-Aviation payware aircraft installed, you need to updated your license to use it every two weeks. This will either happen automatically (with or without notification) or with a click of a button. You can set all the preferences for this in the gizmo gatekeeper menu (pop out sidebar on right side of monitor). Cheers, Jan

It is, the volume is just really quiet and there is no way to turn it up . Cheers, Jan

I just tried again on my end: At idle power (21%N1) with standard conditions (sea level, 15C, 100.000lbs gross weight) the plane starts moving and reaches a speed of 9 kts after 30 seconds. Nominal. There must be going on on your end... Cheers, Jan

Hi John, I just tried again on my laptop, just to make sure nothing has cropped up in the latest X-Plane betas: At idle power (21%N1) with standard conditions (sea level, 15C, 100.000lbs gross weight) the plane starts moving and reaches a speed of 9 kts after 30 seconds. Nominal. The frame rate sitting at KEWR is 20-21 on my setting, the default 737-800 gets 22. So again, Nothing particularly bad. I am sure it is something on your end, if you could post your LOG.TXT from the default folder of X-Plane (after shutting down the session) we can take a look. I suspect a plugin incompatibility or some interaction with another 3rd party aircraft. Cheers, Jan

Hmm, I have not noticed something like this - reminds me of the older days in X-Plane when the plane flies across a tile edge and the "normal" (vector to earth core) changes by one degree (since the tiles are all just flat facets on the earth spanning 360 degrees)... Otherwise, no idea... Jan

No, usually the fly-by code works correctly, the plane will start the turn timely to smoothly intercept the new bearing. The plane will only revert to fly-over reintercept if the bearing change is too large (and the turn would need to start way too far ahead of the intercept point). I could imagine that above behaviour is due to the FMS calculating with a very low speed (and calculating tight turns) and then the plane flies the routing with a much higher speed (causing it to overshoot the precalculated turns)? Cheers, Jan

No, this is not happening on the real aircraft, and I haven´t seen it on my system, either. If you could catch a video of that, that would be very helpful! Cheers, Jan

Sometimes the LNAV code still faults when there are very complex routings - with big track changes and closely spaced waypoints. I see that you flew to Italy - their SIDs and STARs are notorious for not playing well with modern airliners´ FMS. The real FMS has a limitation called "triple bypass bug" - when the plane can´t make three consecutive waypoints (because it can´t make tight enough turns), the code folds up. We didn´t model this, but I just mention this to show you that the real LNAV code isn´t foolproof, either. You did the right thing - when the plane doesn´t fly the way you want it to, take action. Thats why there are still pilots in the cockpit, these days. Cheers, Jan

Hi Jens, I really have no idea - haven´t heard that one before. Just a wild guess - some people install X-Plane or add-ons on "weird" drives, like USB sticks, external HDD, etc. This can work in some instances, but seriously bottleneck in others. Another idea is some sort of background process hogging your system, or an antivirus program doing some "live" IO operation checking... Jan

Yes, there may be different regulations for different airlines. The FO disconnected both autopilot and autothrust with the disconnect switches - like I said before, this robs him of the autothrottles automatic speed reversion (low-speed protection) and go-around N1 mode. I think Boeing made a reversal in their recommendation for autothrottle use while flying FD a few years ago - they now say that it is ok to completely disconnect the autothrottle during manual FD flight (like the guy did in the movie), because the "automatic" mode changes of the autothrottle during FD pitch mode changes (i.e. going into MCP SPD mode when going to ALT ACQ) actually confuses pilots. I guess training people thoroughly is becoming too expensive, these days. The captain twice interferes with the first-officers flight controls (adding thrust), this is debateable. The preferred method is to make a call-out. Just my opinion, other airlines and cultures may see this differently, and of course its better to interfere than to have an accident. Sometimes (especially in the landing phase) there is no time to invoke a reaction timely. Cheers, Jan

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