Litjan

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

No worries - and happy that you figured out what the problem was! Happy landings, Jan

I just checked - the names of those datarefs are still valid in the cockpit.obj file. I will have to talk to Tom and do some experimentation... Cheers, Jan

He can not possibly talk about the dial-type "steam" instrument panel, can he?

Often using the latest version of XPUIPC seems to be a problem - they work when using an older version. Not sure why, its on the list to investigate (also kinda hoping the UIPC guys have an idea about why) ... Cheers, Jan

Hi 3rdwatch - I am absolutely dedicated to making one, rest assured. I have the Oculus Rift, and love playing in it...although not so much the 737, the resolution is simply not good enough. Will be good enough to make a VRconfig.txt, though! Cheers, Jan

We will think about it - I kinda dread the flood of new bugreports that this will create, though (from new users)... At the least I can try to find out how to erase them manually, will talk to Tom about it. Cheers, Jan

Ah, ok - I see the weights. .72 is slow for a 737 in cruise - the pitch seems appropriate. Not sure what cost index you used. Note that the optimum altitude indicated is purely a function of weight, not of speed (which means you probably fly too high for the slow speed calculated by the FMS). The "green dot" denotes the optimum L/D speed with engines running, the top of the yellow bar will include a MACH buffet margin, so at high altitudes it will be "higher" than the green dot. And - as Morten pointed out - if you have a "far forward" center of gravity, the tail has to push down hard to keep the plane level. This extra "push down" needs to be balanced by the wings, so they need more "nose up" to create the necessary lift. The saying is "As a rule - aft trim saves fuel" Cheers, Jan

Ok, you can try to run this very latest beta (found on the bottom of this post), or revert to the last stable version (included in the installer or 1.3). Let me know how that works out for you? Cheers, Jan

Let us know how that goes for you! Cheers, Jan

It has not been modeled - yet. We list it in this post (which has been up since before we started selling the 737), I continuously update it when we fix and add stuff. I even add more to it, like the lack of a dedicated VRconfig file, because that wasn´t even available when we started selling the plan 5 years ago. http://forums.x-pilot.com/forums/topic/8526-things-that-are-not-going-to-be-in-v13/ Cheers, Jan