Litjan

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

Hmm, ok - maybe you set up some buttons or switches on your hardware to cut off the fuel supply? It happened to me, I got a new Thrustmaster throttle with switches on it, and my son always flips those when he stands by the computer. One of them was set up to operate the start switches and it kept killing my engines that way. Also "fly with lua" is a usual suspect here, or anything that interferes with datarefs. Last but not least we have a fair share of customers that somehow can´t get the activation to work correctly and the plane is therefore not unlocked DRM-wise. Usually you can see this by seeing the pilots in the cockpit (while in the cockpit view)... Cheers, Jan

it could be that your fuel is empty - or you have selected the option to start "cold and dark" (all systems shut off). Cheers, Jan

I think I have seen this problem before...but can´t quite recall it. I think you want to check that your graphics adapters drivers are up to date and also run the IXEG WITHOUT the "show vortices" option checked. Also make sure that you are not running any third-party code or alterations that play with X-Plane´s shader effects. If that does not help, remove all other plugins (fly-with-lua, etc.) and add-ons to get a "vanilla" installation of X-Plane and then try again - if that helps, slowly add the other plugins back, until the problem returns, then let us know what the conflicting plugin is. There have been some changes to the way that X-Plane handles graphics between 11.3x and 11.4x and it shows in some incompatibilities and graphics problems that were "fine" before (not really, but they didn´t show any symptoms). One example is our "vortices" hack, it can lead to the cockpit "disappearing" during flight now. It will therefore be disabled in a future update. Also make sure that you attach the log.txt file if the problem persists, our experts here can glean a lot from that info. Thanks, Jan

No - this is still a mystery to me. When you press the APP button with a localizer within capture criteria, the autopilot will initially bank towards the course you have set on the corresponding side. This would explain the sudden banking when you engage APP (and have additionally set the ILS frequency of the runway you are flying to, but NOT the corresponding inbound course). The autopilot has no means to trim the aileron or rudder, so if the plane is truly mis-trimmed after you disconnect the autopilot, something else must be at play. Do you have any other third-party plugins (fly with lua, etc...) installed? Again, to truly solve this I would need to look at a video of what is going on - texting here in the forums is like describing whats special about the Mona Lisa on a postcard... ;-) Cheers, Jan

Ok, that is the reason - you don´t push the APR button when doing an RNAV approach in this aircraft! It is not an A320 (thank god). You fly RNAV approaches in LNAV and VSPD (VNAV is not authorized). Cheers, Jan

Hi, the first thing that comes to mind is that you have set up malfunctions within X-Plane and a flap was not working. This would result in an asymmetric flap extension and a resultant roll. It is curious that you would get that (random) failure on two consecutive flights, though. To further troubleshoot this problem I would ask you to somehow take a video of the incident so I can check your flight for other possible reasons (icing, incorrect speed, asymmetric thrust etc.). Cheers, Jan