Litjan

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

Hi Hakan, your PC is certainly powerful enough, and getting over 30fps is good. I see your heartbeat spikes, and they are pretty much what everyone else expects. I think there is nothing else you can do to make it better. So please bear with us as we try to improve this - but I can not promise anything. We could move the code to "every" frame, but then the plane would run slow the whole time, instead of only every few seconds. I am not sure what is more desirable. You have NOT checked the correct box - you must check the "automatically update my license at sim start" as well. You can uncheck the lowest box ("notify me...") if you don´t care to get notified when it happens. Oh, and be careful not to turn on "airshow smoke" by accident (I think key "X" is default) - it looks like you have that running. Cheers, Jan

There is some "heartbeat like" variation in the framerate - it is due to certain systems doing calculations only every few seconds instead of every frame (to help with general performance). There is also some background work done by gizmo, and Ben has greatly reduced that effect with one of the last gizmo updates. Here is what I see on my system when sitting on the ramp at a big airport. My base framerate is ca. 24 fps and it dips down to ca. 20 fps every 3 seconds (a 18% drop). Here is a picture of the graph: While the whole team continues to strive for better (and smoother!) performance, this is something I barely notice, but of course your personal sensitivity to these variations may be very different. If you run at a higher framerate, the relative effect is stronger - sitting at Bermuda Islands Intl I get 60fps, and it dips down to 40 fps. So the drop is 33%, but of course the "lower" framerate is much better (40) than in the first example. What kind of drop do you see? Thanks, Jan

I just did some tests, and I came to the conclusion that everything works fine (both coordination in turns, and yaw damper). Look at this first picture. It was taken when initiating the turn. The yaw-onset is to the left (in the direction of the turn) and you can see the yaw-damper COUNTER it (as designed) by applying opposite (to the right input): Next picture shows the sustained turn at 220 kts - no rudder input. You can see that the ball is "almost" perfectly centered, the slip is about 0.4 degrees (its a bit hard to read): And just to complete the test, here is another sustained turn at final approach configuration, slip is 0.6 degres: These values are absolutely within what I would expect to see in the real plane. Cheers, Jan

Hi Mike, in the real plane the roll spoilers help to overcome the adverse yaw you get when initiating the turn, and the general aerodynamic shape of the airplane and wing keep the turns coordinated (don´t ask me how, but I think the big size of the vertical stabilizer needed for engine-failures helps)... there is no rudder input needed when making turns in airliners. The yaw damper is actually working against making a coordinated turn - it is a rate gyro that fights sudden "yaw onset". So when you initiate the turn, it will actually deflect the rudder opposite to stop the yaw. Once the turn is established (constant rate) the yaw damper input is washed out to zero. We are already looking at turn coordination in our current model and XP11 - there are bound to be some more flight-model changes (as Austin hinted at) - and we are wary of tuning, retuning and then again tuning the model until he seems satisfied. For now the plane flies ok and according to real performance and unless that changes we are inclined to let Austin do his thing and then revisit when the dust settles... Cheers, Jan

Hi Paul, (1) fly with V/S set to -1000 until you intercept your desired flight path, then use FL CHG descent. You need to do the calculations to meet your restrictions yourself (until we fix VNAV patch computations), but the green arc will help you (it shows where you reach the dialed-in altitude given your current V/S and GS). (2) not yet (3) no - I find it working pretty smoothly, and when following it precisely I stay on LOC and GS very accurately. Not sure what is going on on your side, there. Cheers, Jan

Hi Hakan, The "stutters" that people experience are very dependent on your hardware setup. I get subjectively very smooth gameplay. Most people seem content, but a few experience what they consider unacceptable pauses. I am not sure what the cause is, so my advice is just in general to make sure you have enough computing power (CPU, GPU) for the rendering settings you set up, and also to stop as much as possible any other programs running in the background on your system. To activate your license you just need to enter your customer email and the password you set up. Then it should do it. There is also different ways to set up the Gatekeeper DRM (look in the pop-out panel on the right side of your screen) to automatically do this, so it won´t ask you every two weeks. I hope this helps, Jan