Litjan

We´ll see ;-) Jan

Thanks for the reports, guys - unfortunately there is way too little/inaccurate information in them to really even understand what your problem is - let alone trying to guess the cause or the solution. I would suggest troubleshooting on your part (nav data, user error, proper procedures, etc.) and if that doesn´t help, come back and give me a detailed report (including pictures and/or video) describing step by step instructions to show the problem. Don´t forget to include the Log.txt and of course to remove all other plugins and third-party addons before you try to recreate it. Cheers, Jan

Cptburgos, I will never say never when it comes to X-Plane...but there really was nothing changed in the way the radios or nav-database works with 11.50. I also checked on my side with 11.50 and the navradios work fine. Cheers, Jan mmerelles: Working on it ;-)

I think it already works with Vulkan! Cheers, Jan

I am sorry, then I have no idea. They should work with Xenviro, at least I have never heard that they don´t. Cheers, Jan

Make sure you are not in autothrottle mode - the throttles won´t "work" (can´t be moved by your hardware) while that autothrottle is controlling them. You must be in "manual throttle control" (autothrottle disengaged or even off) for the throttle to work. When you transfer control from the autothrottle to manual throttle (by disengaging it) you will see some "ghost throttle" symbology. Move your hardware throttle until it "matches" the ghost throttle - at that point the throttles will "snap" and you have control again. Cheers, Jan

Your screenshots look fine - you should see the effects of the landing lights. Maybe some other plugin or third party program (altering shaders or art effects?) is interfering. Cheers, jan

Hi Pierre, It is very well possible that your change confused our FMS. Especially with the descent calculations it is very unreliable. It works "ok" when you have no restrictions. With restrictions - not so much In the real aircraft it was dependent on pilot´s preference what modes were used. In general, for smaller descents (<3000 feet) V/S was used. Also when ATC gives you a descent rate restriction (descend with more than 2000 feet per minute...) The most economical way to descend is using an idle power descend (= FL CHG). But especially when your target speed is still a Mach number, this can result in very high rates/low pitch, so some pilots didn´t like to use that for passenger comfort. Cheers, Jan

Hello Pierre, often the TOD does not change when you enter or change constraints on the descent path - because it is not affected by a new constraint, or lifting an old one doesn´t affect it. Imagine a "idle descent" path that passes well under a restriction of "be at FL250 or below". Now clearing this restriction won´t affect the calculated path, because it never affected it in the first place! The calculation of the VNAV PTH descent in the real 737 worked fine - but it was complex and had some potential pitfalls. Especially when winds were unknown (as they mostly are) or when ATC changed your lateral flightpath (as they almost always do) the calculation of the optimum path can get you in trouble. This is due to the fact that the FMS will plan the descent in an optimal way - without any conservative reserves. So if there is less headwind or the routing gets shortened you will immediately be "too high" to start your approach. This does not work well with the conservative and safety-oriented attitude that airline pilots have. Also the complexity and missing transparency of VNAV calculation make real pilots shy away from using it - don´t use what you can´t understand and doublecheck. So speaking for my airline, the typical use of VNAV was seen in climb and cruise. In those portions of the flight VNAV works exactly like FL CHG, with the difference being that the target speed is calculated by the FMS. Usage in descent was close to 0. We used the TOD and vertical deviation bar to "sanity check" our own descent calculation, but the VNAV PTH descent mode was barely ever used. Cheers, Jan

Hi Pierre, you will find most things are the same as when you left (I know, I know...) - some deficiencies with the FMS mostly. Not sure when you left, but here are the things that cropped up within the 11.xx run: 1.) When you don´t have rudder pedals, the simulator now tries to "help" in turns by braking for you asymetrically. This can be fixed in planemaker, but when you do there is now a problem with some internal lights not working anymore as a result. 2.) The option "show vortices" does not work anymore. In fact it will also render your cockpit invisible in certain circumstances. Don´t use it. 3.) Don´t use the "experimental flight model". The plane will fly ok, but not by the numbers. 4.) There is a certain combination of external lights that will make your MCP panel go very bright (it has the wrong object property). This only surfaced recently. 5.) Stall warning test buttons do not work on the ground We are working on an interim patch (pre- XP12) that will ensure Vulkan compatibility and also fix all of the above (in the list, not the FMS deficiencies - those will have to wait for the full FMS rewrite planned for the XP12 patch). Cheers, Jan

In addition to that - it can be fruitful to experiment yourself with the lua Garbage collector: Go to the Data Output tab in X-Plane. Enable the second checkmark (Data Graph Window) in the first line (Frame rate). Now open the data graph window (default: CTRL-g). You can see the framerate like a "heartbeat curve" now. Be advised that displaying this ALSO consumes framerate, especially if you increase the "time frame" of data to be seen. Now open the lua garbage collector setting in the right side gizmo menu. You can "play" with the two values, trigger threshhold goes from 1 to 500%, the Cleaner Strenght goes from 100 to "very much" ;-) I basically find the first value the more useful - if you go up high, your "trash can" goes up in size...so it fills longer (smooth, high framerate) but then it also takes longer to dump it out (noticeable stutter every few seconds). I think one can easily find a good compromise when adjusting those two values. Cheers, Jan

Hi Andromeda64, If the stutter is so definitely periodic, it is most likely the Lua Garbage collector. You can adjust the setting to your liking - basically you have the option to move the effect between: A.) Great framerate, but pronounced stutter every few seconds and B.) Slower framerate but very little stutter. In general, the more RAM you have available, the better the situation (you can pile up more "garbage" before it needs to get cleaned). Cheers, Jan

After some research I found out that the "Wing inspection light" is indeed connected to the 28V AC ground service bus. Since we do not model the actual ground service switch (yet) we coded this as if the switch was always on = Ground service buses powered. The logic behind this may be that the wing inspection light needs to work for the ground crew to establish wether de-icing is needed, even before the flight crew powers up the aircraft. Cheers, Jan

Will take a look for the next update for sure! Just about finished updating the flight model for the "new experimental flight model"... Cheers, Jan

Yes it is. Jan

You are running an enourmous amount of plugins and extra scenery. Several of these plugins are known to cause problematic behaviour if not updated diligently. To find the conflicting plugin, disable all of them, then run the IXEG 737. If that works, add your plugins back in batches or one by one until the problem reoccurs. Once you have identified the conflicting plugin, check for an update of it. I know you said that you already did that, but if that is indeed true, you may have a hardware or windows installation problem. Your log.txt does not show that X-Plane detected any crash. Cheers, Jan

You are running a number of plugins that have been known to be problematic in the past, especially when not updated diligently. These include fly-with-lua, several ground handling plugins, but also some custom airports (with their own plugins), etc. Standard troubleshooting protocol applies. Remove all plugins (temporarily) and run X-Plane with the IXEG. If that works, start adding your plugins (maybe even in batches) and see when the problem re-appears. Cheers, Jan

When you answer this post, use the blue "choose files" underneath. Click it, then go to your main X-Plane folder (after the program crashed) - then locate the file GizmoLog.Txt Click on it, then choose "open". After that you will see it beneath your post - click on the litte + to attach it to your post. Do the same for the Log.txt (you can add both in a single step, if you select them both while holding CTRL). Cheers, Jan

Hi, I just tried myself, and I can hear all sounds (2500 - 1000 - 500 - 400 - 300 - 200 - 100 - 50 - 40 - 30 - 20 - 10) just fine and at a very normal volume. I attach the screenshots I took of the corresponding volume settings. Now that I think of it, I think we used to have problems with some user´s systems that had a soundcard that was only capable of playing a limited number of simultaneous sounds - and they were actually running out of sound channels, so they couldn´t hear all of them. Maybe thats something to investigate as well. You may also want to try and disable the XPrealistic pro, there is just no way of knowing how that may interfere with other stuff. Yes, we are still working on FMOD, that may help with some of these issues. Cheers, Jan

I faintly remember hearing about the problems of low callout sounds before...the first thing to check is that all sound sliders are at maximum, both in the IXEG sound preferences and also in the X-Plane sound preferences and then try again. Also try the callouts without an ILS tuned, I have to admit that I don´t completely remember which callouts the "smart" system suppresses in an ILS approach and I am too lazy to run downstairs and get my 737 OM-B out ;-) I just remember that we implemented that feature... Cheers, Jan

Hi there, you are running several plugins that are considered "problematic" when run together with other plugins - especially if they are not diligently updated to the latest versions all the time. Standard protocol applies: Remove all other plugins, then test the 737 again. If that helped, start adding your other plugins again until the crash re-occurs. You can also try to see if there are updates for some of your plugins, especially "fly with lua", "better pushback", "airport navigator" and that fmc plugin. Cheers, Jan

Hi Yohannas, I am not sure why you are not hearing those. I can hear them all fine. The "500" callout on the 737-300 is a "smart callout" and will only sound if you don´t have an ILS frequency set on your nav radios. If you have a decision height set on your DH window, it will say "minimums" at that DH, omitting the corresponding altitude, so that they don´t overlap. Cheers, Jan

No. You can only use fuel from one tank for both engines - effectively stopping fuel usage from the other tank. To balance the fuel you would open the crossfeed, then turn off the pumps on the tank that is less full. Cheers, Jan

This is due to the Windows Defender anti-virus checking every in and out operation. You have to exempt the X-Plane folder from Windows Defender live-virus checking (it is ok to scan it with the normal system scan, of course). Virus checking while data is transmitted slows down the computer so much that it looks like it freezes. Cheers, Jan

Hi, there definitely is a plan to get the plane VR-ready. I don´t know when that will happen, though. I am a big fan of VR myself (have an Oculus Rift), but with my headset I find the resolution too poor to use the FMS without either leaning in like crazy or using the zoom (which makes it hard to hit the buttons). I think the next generation of headsets will probably fix that, and having the plane be fully compatible with VR is definetely our goal. Cheers, Jan