Litjan

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

No sweat and I am happy you got it to work...by the way, isn´t the new Cardiff airport looking great? Thanks to Anthony for making it... so your "bug report" did serve a purpose after all, I got to check that airport out . Cheers, Jan

Hi Mikey, for what it´s worth I just did the same flight you describe (EGFF runway 30, BCN1A SID, ...) and there was no problem with the takeoff configuration warning. I would suggest rechecking your controller setup and key-binding... I have had reports where suddently keys or buttons were bound to stuff that the user never assigned. In your case it could be a button or lever getting assigned to trim, or some autopilot or artificial stability control. Take a look at what the trim is doing and we should be able to narrow the problem down. Cheers, Jan

The autobrake will disarm if thrust is advanced, this may be due to spike signals from thrust lever hardware. It will also disarm if the brakes are tapped, so if you have brake pedals, that is also something to check. The autobrake system we use if mostly default X-Plane, so there is not much we can do to alleviate that. Unfortunately XP does not allow to set "null zones" for thrust levers and brake pedals. Cheers, Jan

I think (and you can read Philipp´s post on it to confirm it http://developer.x-plane.com/?article=navdata-in-x-plane-11) that the earth_nav.dat that holds the localizer and glideslope data is residing in the following folder: X-Plane 11/Custom Scenery/Global airports/earth nav data In this folder you can find the file earth_nav.dat that is relevant and will be read for LOC antennas and GS antennas. The remaining info is read from the other earth_nav.dat files. You can copy and change the earth_nav.dat in your "Custom Data" folder all you want, it will not have any effect on the ILS approaches in X-Plane 11. Try it. This is the "curated navaids" approach they are now doing. Only Robin Peel will change those navaids according to user feedback. Of course you can copy Navigraph´s earth_nav.dat over this file and that will replace all the "curated navaids" with Navigraph´s. I have done it and it works great. Of course some ILS´s will not line up perfectly with the (wrongly placed) runways anymore. Jan

...and an important lesson in cockpit risk and error management was learnt! Cheers, Jan

Hi hohum, mmerelles has the answers. The only thing I could add is for 3) please make sure that you have dialed in the correct localizer inbound course - ie. for EDDF runway 25R it would be 248. If you could also post a screenshot of when it happens, we can see if the plane tracks the localizer (and that is offset from the runway) or if the plane does not track the localizer well. Unfortunately your updated AIRAC does NOT replace the landing aids (localizer, glideslope) in X-Plane. This was a deliberate desciscion by the devs to mask the fact that many runways are a bit "misplaced". If people suddently get very accurate ILS placement, this will become more noticeable. Therefore updating your nav data does NOT update any LOC or GS transmitters. But if other planes work well, then I suspect it is the missing inbound course being set (which makes the plane try to fly a wrong inbound course when intercepting the LOC). Jan

Yes, lighting in general in the cockpit is a whole new ballgame now - and not every change has been for the better, I feel. The background light will never be on "full bright" in the real cockpit - unless you fly through a thunderstorm, have a total electrical AC failure or have lost your cars keys somewhere. So no matter how many times someone rode on the jumpseat, chances are slim that he would know how that looks in the real plane. I have seen it a few times on my simulator checkrides when we simulated electrical failures. The general instrument lights are turned up as much as they can go in XP11. Cheers, Jan

I certainly see your point! We will continue to pursue making IXEG more smooth. Cheers, Jan

Hi Mike, the seat-belts switch is actually controlling the cabin lights - and unfortunately they "bleed" through the cockpit rear wall and the cockpit door. We have been in contact with Laminar Research, but it seems to be the way it is for now. So we have made the seat-belt switch control this: In OFF you will always have cabin lights at 100%... with the (unfortunate) effect of them lighting up the cockpit as well. In ON you will always have cabin lights off - so you can really enjoy the completely dark cockpit. In AUTO they will follow a certain schedule...first bright during boarding, then going dim for takeoff, then bright at altitude (service phase), then dim again for landing and tax-in. We will likely have a fix for the bleed-through in the next patch, so for now control them with the SeatBelts switch, please. Cheers, Jan