Litjan

Hi Ian, your first issue sounds very much like a pound/kgs conversion problem. Make sure you have set the preferences up correctly for your preferred units and enter those correctly, too. I haven´t observed any problems with the fuel weight getting calculated correctly, but you never know...maybe you can snap a screenshot when it happens? The speed not bleeding at 1000fpm is not what I observe - you need about 1200 for idle at 210kts (minimum drag) or about 1500 at 250kts. Make sure that you have no other plugins interfering. 31% N1 is normal for "flight idle", we overrule the hardware throttle position when at idle to at least have the engines maintain that (while in the air). When using the weather radar with ANY third-party weather addon all bets are off. Nothing was changed with regard to its operation since 1.2. I have observed the glideslope warning, too. I think in the real aircraft this would maybe not pose a problem because the signal is weak on the other side of the antenna, I am not sure. I could not glean any information on this mode beyond that it will sound if you are "below the glideslope" (varying frequency and loudness). There is no logic to check flap setting, rate of climb or anything else to suppress those for climbouts.That being said, I am only aware of one airport in Europe (LFML) that requires the DME off of an ILS for a SID - there used to be a departure out of Orly like 20 years ago...and then there are the Brits, of course . We will use the new setting in planemaker that was enabled with 11.50beta11 that always "forces" experimental flight model on. I also like it. Cheers, Jan

We have some reports of sounds not playing nice with WMR headsets... also running any other addons that create sounds (like ambient wind, birds chirping, etc.) may possibly interfere with our own sounds. Cheers, Jan

Hmm, thats a new one... can you post a Log.txt file so we can see your hardware capabilities and other plugins which may interfere with the sound system? Is there internal engine sound? Are the engines running? Do you have your volume up? Can you hear other sounds (APU, airconditioning packs, electrical hydraulic pumps)? Cheers, Jan

I will see what is going with that and report back! Gracie, Jan

Hi Torbinator, make sure that you don´t mistake the noise of the running air-conditioning pack for wind noise. I have changed the default settings for the "turnaround" state so that one pack runs (to keep the passengers comfortable). To test, simply turn off the pack before going to the outside view. Cheers, Jan

When you set up your VR configuration in X-Plane there is an option to show the green "manipulators" - not quite sure what the option is exactly called, but you will find it. It is in the same menu where you choose between "realistic" and "ergonomic" yoke and also enable/disable the VR-mouse pointer. Let me know how it works out for you! Cheers, Jan

I just tested the mouse in VR and for me it works flawlessly on the overhead panel (and everywhere else). Here is something to keep in mind: Our manipulator clickspots move with the switch. So in case of a "click to toggle" switch like the yaw damper, the clickspot will move away from your mousepointer once you click the switch! You can see that the little "hand" turns into an "arrow" at that time. You will then have to move your mouse again until it touches the switch (and turns into a little hand) again to toggle the switch a second time. Cheers, Jan

We are working on the fix!

Thanks for the feedback, guys. I don´t know about the sounds - I would think that it is some sort of resource problem - first thing I hear about it and don´t experience it on my computer. But then again I usually set the flight up in 2D and only then switch to VR, maybe that has something to do with it. I will try. The manipulators in the VR cockpit are tuned for operation with a VR controller, I have to try with the virtual mouse. But the yaw damper switch is a simple "click to toggle", so I can´t see why that wouldn´t work. I will report back! Cheers, Jan

Hi Krzystof, are you running the beta version of Gizmo? It improves "smoothnes" of the simulation a lot. You can also get that latest beta in the post I mention below. If you are already running that, I would still need you to follow this: so we can rule out any conflict with another plugin. Cheers, Jan

...and in addition to that: I have "relaxed" the requirements of the speedbrake to be "fully down" to not trigger the takeoff configuration warning horn. It used to be at 0 (and not a single bit more), so a sloppy lever or mouse-move may have put it at 0.00000001 - and triggered the warning. Cheers, Jan

I have two buttons on my joystick assigned to "speedbrake down a notch" and "speedbrake up a notch" (or whatever those are exactly called) and it works nicely. Maybe try that? Cheers, Jan

Hi Benweston, I checked the SID. The reason for this is that our FMS assumes that you will accelerate to 250kts fairly quick. That is the reason for the BYPASS of waypoint D161D - the radius would be too large for it to make the turn without overshooting the calculated intercept point for the leg to the north... I think the real FMS may do a bit better in this case (you can see how the route draws good before you ACTIVATE the route)...but this is a tough SID to fly for our FMS and therefore was not handled perfectly. You did the right thing in flying it manually/HDG SEL, though. There are a few SIDs in real life that I always flew like that (DEGES2S in LSZH or SPI7C in EBBR) because it is more efficient. Others (DET2G in EGLL) must be flown in HDG SEL because the FMS would bust the first turn going too wide... So the pilot always has to monitor the performance of the automation, you won´t get away with a "but the FMS flew it that way! It is not my fault!" Cheers, Jan

No idea - I don´t have the Better Pushback plugin, I don´t think we did anything to the green planning lines and this seems to be not a widespread problem (at least its the first complaint I heard about BP and the IXEG 737). Maybe you can find more help at the BP support forum? Good luck, Jan

No worries at all - the button is pretty inconspicuous (on top of the EFB) - and I made Tom make one (before the tab was always on) - because I thought it looked odd to enter a "cold and dark" cockpit and the laptop is running. Background story here is that we have EFB´s in our real aircraft, too - of course. Procedure is to shut down the EFB when you shut down and leave the aircraft, but some people simply forget (he who is without sin may throw the first stone!) and when the battery goes dead, so does the display of the EFB (even though the tablet itself is still running in its docking station). So sometime during the night the tablet will reach low power and go to sleep mode. But for some odd reason it will not wake up from it again, UNLESS you take it out of the docking station, flip it open, and hold down the power button for a few seconds. The problem is - we are not allowed to do that - it´s considered a maintenance task. So basically if you are on an outside station in the morning with no company maintenance available, you would have to contract a certified engineer, fill out a bunch of paperwork, do a million phonecalls (incur a few hundred Euros of cost) and delay the flight for a minimum of one hour. Or break the rule, take the laptop out, start it up and be done with it. Which I would never do, of course. Hence my obsession with the power button Cheers, Jan

Me neither! As I always say - Checklists are for the bad pilots - the good ones never forget anyway... Cheers, Jan

Hi Daniel, we have had reports of the nav radios failing for some people - here is one case where it was probably some hardware interfering: Maybe you can try the "reboot gizmo" trick (little flash symbol on the right-side pop-out menu)? And the EFB turns on - tada - when you push the power button on it . (You are not the first one to not see that, no worries!) Cheers, Jan

As Cameron said. I have the sound for that ready, but it will be part of the "FMOD" sound upgrade which is a few months into the future...

Off the top of my head there are just a few minor differences. In the real plane the spoilers don´t have to be armed for the autobrake to engage - if this is the case in our aircraft then this is a bug (but I will have to file with Laminar to resolve it, as we use their autobrake system). I don´t think you can engage the autobrake after landing, at least I was not aware of such a function and it was not mentioned in the manual. If you try to move the selector to one of the autobrake settings with your speed above 60 kts would simply show the DISARM light. When the autobrake gets disarmed after landing (your points ii-iv) the DISARM light will stay lit until the selector is moved to the OFF position. Cheers, Jan

I see what is happening: The waypoint you are flying to was getting BYPASSED (means the plane could not fly over it because of the turn radius) - and appearantly this was by more than 2.5NM lateral distance, so the waypoint never sequenced (got deleted). The plane is - however - following the magenta track, it does not "know" that it missed the point. The cure for this is to fly "direct to" the point you are actually flying to - in this case ANC. Then the flightplan is "in sequence" again and the plane will behave normally. To avoid this happening in the first place, make sure that you have no "bypass" points in your route - often the speed of the plane is too big in that case, or the waypoints are at too acute of an angle. Cheers, Jan

I have seen font problems in relation to the X-Plane Vulkan API. If you are running X-Plane Beta 10.50 that could be the problem. It would be up to Laminar to fix that. Cheers, Jan

Hello Krzystof, you are right that the sideways traction of the nosegear is not as good in X-Plane as it is in real life. Laminar Research is aware of it and will improve it in the future. Like Iain said, it is important to keep the steering angle of the nosegear below a "critical" angle for it to work. Otherwise the nosegear will "stall" and just slide without much friction (gliding friction). To help with that: 1.) Keep your CG at 20% MAC or less (more pressure on nosewheel) 2.) Limit speed to <10 kts in turns 3.) Only move the nosewheel very slow and do not deflect it too much. It will not "steer more" if you deflect it past the critical angle. Taxiing a real airliner is very much about passenger comfort and you will feel getting "thrown left and right" much more than in a small plane, because you are so much further from the center of the turning point - so naturally you will apply and decrease tiller input very deliberately. I have no problem taxiing the IXEG 737 on dry surfaces when applying real life speeds and turning inputs, but I agree that the margin for error is much smaller than in real life. I hope that Laminar will fix this in X-Plane 12. Cheers, Jan

No it wasn´t. The root cause (in the new gizmo beta) has not been found yet. If it really bothers you, you can always go back to the stable version. I choose to enjoy the much smoother performance of the new beta and live with one gen bus not getting powered - nothing important on that one anyway ;-) Cheers, Jan

Yes, I think the light level is pretty good the way it is. I realize that the surfaces in X-Plane are far less reflective (bumpy) than a real runway, so it will look like the lights are a bit too dim. Turn on the taxi and landing light when you approach a building, and you will see that they are already so bright that they will almost burn everything in their way. It is also a common misconception that landing lights must be super bright so they illuminate at least half the runway.... not so. Cheers, Jan

No problem. I did a very brief search and came upon this post: https://forums.x-plane.org/index.php?/forums/topic/217345-ultra-weather-xp-v26-issues-situation/ ...so it seems that this also affects the Zibo and the "Pocket rocket" and getting fixed by the developer. Cheers, Jan