Litjan

Yes - I see the problem on my computer as well - the computed N1 is correct, but autothrust does not set it... I will investigate! Thanks for the report, Jan

I understand that for testing/dev...and/or if you really know what you are doing...

You can also doublecheck if you have the option "turn downwind ILS off" enabled in X-Plane. If that is on, the ILS will be "switched off" if there is a tailwind on the runway... Cheers, Jan

Good morning Seamaster, while we have some VNAV problems, often the problem you report is due to the MCP altitude not being lowered prior to reaching the TOD. Once you are past the TOD the plane will switch to ALT HOLD and will not descend by itself anymore, even if the MCP altitude is lowered then. Cheers, Jan

Thanks for the report! Not sure about the takeoff config - it doesn´t sound for me. The thing most people forget is to set the trim, so it is not in the green band, which triggers the warning. Could you doublecheck if that is the problem? Cheers, Jan

Good to hear that. Yes, you will need electrical power for the navigational radios to work. Cheers, Jan

Hello Faisal, can you see the ILS on the X-Plane map (m key)? Can you click on it and choose "tune on Nav1"? Maybe you can load the plane at an airport with an ILS serving that runway you are on, then tuning it to NAV1 and then send me two screenshots (of the Nav Radio and the artificial horizon)? Thanks, Jan

Hi everyone, we are happy with the renewed interest in our beloved 737 and while we would of course prefer you to not have any problems with it - the next best thing is you reporting your problems so we can fix them and hopefully one day (unlikely!) get to the point of no one having any problems with it anymore . If you encounter what you think is a bug or observe a problem: 1.) Do a search in this website (IXEG section) to see if anyone else reported it and what the status on it is. We want to try and avoid having 27 threads of "oh, it looks like the mousewheel scroll direction is wrong, has anyone else seen this?" 2.) If you report a bug, it almost always pays to attach the LOG.txt file (found in your X-Plane main directory) to the post (attach, don´t copy the contents of it to create a wall-of-text). 3.) If you encounter a crash of X-Plane, the culprit is usually an incompatibility with a plugin or memory exhaustion (RAM or Lua). To troubleshoot, please remove all plugins except for the Plugin Admin and Gizmo, then try to run the IXEG 737. If that works, add your plugins back one by one or in batches to isolate the problematic plugin. Often you will find that this plugin has been updated and you can get a more recent and hopefully compatible version. Let us know - even if you succeeded, other users may benefit from your findings. 4.) The same applies if a weird bug or unexplainable behavior is exhibited by the IXEG 737. We need to rule out third-party interaction, so to troubleshoot, please remove all plugins except for the Plugin Admin and Gizmo, then try to run the IXEG 737. If that works, add your plugins back one by one or in batches to isolate the problematic plugin. Often you will find that this plugin has been updated and you can get a more recent and hopefully compatible version. Let us know - even if you succeeded, other users may benefit from your findings. Thanks for all your continued support to help us improve the IXEG 737. Jan

Oh, wow - I really don´t know what went wrong there... Initially you moved your controls (with the mouse) so the autopilot reverted to CWS pitch. I assume you tried to re-engage VNAV which did not work because probably your controls were still deflected. I have no idea why VNAV calculated these high speeds, though. I think I would like to add that some of the more serious problems we have seen are with users that fly with a mouse or trackball. I would even go as far as saying that if you are serious enough about flightsimulation to buy and fly the IXEG 737, you should really buy a joystick first before spending 75$ on an add-on aircraft like this one. Even if that means that no money is left for the IXEG 737 and we loose a sale . Cheers, Jan

Thanks for the report - both known - the flap will be fixed, for the seat we have to see how we can improve the "fuzzy" looking of the edges without killing framerate. Cheers, Jan

Hi there, you are running quite a few plugins that have been causing conflicts in the past, Silver Lining, Flywithlua, XPUIPC,... I would ask you - to test - to remove all the plugins except Gizmo and PluginAdmin. Then run the IXEG and see if it crashes. After that you can add your plugins again in batches until you find the offending one. My bet is on SilverLining, it messes with the art of X-Plane and is known to be iffy. But also some of the plugins for scenery (KSFO) and other can be a problem. Cheers, Jan

Will check those, thanks for the report! Cheers, Jan

This is what I see in your log: Loaded: C:\Users/jeffr/OneDrive/Desktop/X-Plane 11/Resources/plugins/XPUIPC/64/win.xpl (XPUIPC/XPWideFS.). Lets try to REALLY get rid of it and then see what happens... Jan

The N1 bug is showing the maximum N1 (full takeoff thrust) for the given environmental conditions. Just so you know where to put your engines if you need that. The actual N1 commanded will be much lower if you derated your takeoff thrust (TASS or Derate). Could this be the case here? Cheers, Jan

To add what Tom said - we have not seen many of these errors popping out the gizmo log window anymore, so while the VNAV code isn´t working correctly, at least it is working pretty stable...except in your case here, sorry for that. Whenever you see this and want to continue your flight you can do this to at least somewhat "continue it" and do the landing. Bump your mouse on the right side of the screen to open the gizmo window. Click the reboot symbol. Now you have to be quick to raise your landing gear, deploy flaps again - but at least you can keep flying. Cheers, Jan

Hi Bryan, I have consulted my documentation again, it says: "With the APU operating and AC electrical power on the airplane busses, operate at least one No.1 fuel boost pump to supply fuel under pressure to the APU". So operationally your setting is against the rules ...but I am inclined to say that it should indeed supply fuel to the left manifold and with the APU DC boost pump being off if APU RPM is >95% (running), it should supply fuel from the right wing tank. I will put it into my bug list, good find. Can´t say when we will get to it, though... Cheers, Jan

Hi Robert, you will notice that the "linearity" setting is gone from the control setup - you can make a "response curve" now. This is what mine looks like: Cheers, Jan

Good morning, please add an exclusion to your antivirus (usually Windows Defender is the problem) for the whole X-Plane folder. It checks in and out operations when the IXEG is accessing the nav data (during FMS route modification) which slows the rendering extremely. Let me know if that helps? Cheers, Jan

Yes, same here. Tom has been using a new export script for Blender...I wonder if that has anything to do with it. This line in my log: 0:00:20.648 E/SYS: MACIBM_alert: C:/jenkins/design-triggered/source_code/app/X-Plane-f/../../engine/hardware/vr_manips.cpp:471 may hint at a deeper problem with this that may have to get solved by Laminar Cheers, Jan

You need to have the avitab plugin installed in your plugins folder for the option to enable it to show. The test button should be active...we have had reports of missing sounds when the users´s sound allocation system was maxxed out. Also make sure that all your sound sliders are up. Cheers, Jan

Perfect! Cheers, Jan

Hmm, I just tried, but renaming the file to the usual B733_cockpit.obj (and making the necessary adjustment in planemaker) did not solve the problem... It is curious that the SimVRlabs package also contains a 733_cockpit.obj. Why is that necessary? There was already a 733_cockpit.obj in the version 1.21 folder? It is also obvious that the new cockpit.obj has a far more detailed nomenclature for the manipulators than the old one. Compare: Old: ATTR_manip_axis_knob hand -400 400 1 1 ixeg/733/MCP/mcp_plt_course_act none New: ATTR_manip_drag_xy rotate_medium 4000 0 -400 400 -400 400 ixeg/733/MCP/mcp_plt_course_act none ATTR_manip_wheel -1 Quite a difference... Cheers, Jan

Your main problem is that you never get out of TOGA mode. Changing the speed in TOGA does not work like it does in FL CHG, because TOGA refers to the MCP speed selection, but will also adjust this (up to selected speed + 20) - because you are supposed to fly at V2 + 15 (unless an engine fails). So to get proper behaviour, employ the proper procedure: For acceleration select FL CHG or VNAV. Cheers, Jan

Could very well be - I am just investigating that with Tom...

May I direct your attention to this post? (pinned at the top). The fix for your problem is explained there: Cheers, Jan