Litjan

Hi Aaron, I have not been able to reproduce this behaviour - it is perfectly normal for the aircraft to dive quite steeply in FL CHG when goverened by Mach speed in the descent, the real plane does it, too - thats why many like to enter the descent more gradually with V/S. The reason is that to fly constant Mach you need to fly with increasing IAS when descending, so the plane needs to accelerate while going down - often leading to descent rates in excess of 5000 feet per minute. You will notice though that the plane is trying to fly a constant Mach (as indicated on the MCP) and you as the pilot have every right and authority to dial that one down a notch or two to avoid the dive becoming excessive. Also note that passengers have no ability to feel vertical speeds - they can only feel vertical acceleration. A steady 20.000 feet/minute would feel totally fine to passengers. Even body pitch angle is something they can not determine without looking out of the side windows - the feeling of "pitch" is goverened by longitudinal acceleration - accelerating feels like "pitching up" so that the nose-down attitude combined with the acceleration of the plane trying to fly constant Mach somewhat cancels out. Cheers, Jan

Great to hear that and thanks for letting us know! Happy flights, Jan

Hi, make sure that you have enough fuel - the fuel state is saved between sessions, so if you run out of fuel and then load the 737 again it will flame out the engines immediately. Cheers, Jan

Hi, this is a known bug with a "timer" in Gizmo, it should get fixed with the next Gizmo version (I am already running a test version that fixes it). Indeed you can not power the left GEN BUS with the GPU anymore after it has been powered by the APU or engine generators. The current workaround is to either accept that (no electrical users that you need during turnaround are on the left GEN BUS), or reboot gizmo once you are parked. The view (W) was intentionally moved over so you can see more of the important stuff (like the landing gear lights)...you can freely adjust it in planemaker (viewpoint) or set up a "saved view" with the CTRL-NumPad keys (you can bind recalling those views to a joystick button, too). Cheers, Jan

It is turned on by default if you use the "ready to fly" scenario. I would not assume that plugins aren´t a problem - if would still suggest moving them out of your plugin folder just as a test.

I am not sure if the manipulator framework logic for X-Plane supports this functionality - but I have added this as a feature request and we will see what we can do. Here is a post from another user that might help you (from the VR feedback thread): Cheers, Jan

The switch for the WXR SYSTEM is located between the two CDUs (where you enter info for the FMS). It powers the weather radar and the EGPWS system which is responsible for drawing the terrain on the EHSI. Picture:

Hi, the thrustreversers are pretty much straight X-Plane logic. You need to have the forward thrust at zero to engage reverse thrust, just like in the real aircraft. You can bind keys (like toggle reverse, full reverse) to the reverse thrust function or assign a joystick axis, it should all work. You can not "click and drag" the reverse thrust with the mouse or a VR wand...but you can assign a button or key to "toggle reverse" and then push the forward thrust lever forward with the mouse and it will actually pull open the reverse thrust lever. Cheers, Jan

There could be a few reasons for this, we are running some advanced code to operate the systems of this aircraft that can be causing this. Try to switch OFF the WXR SYS switch and see if that helps? Some third-party scenery has a very detailed terrain mesh that causes these lags when the terrain gets polled. Another option is to try the new Gizmo Beta version (run the Gizmo installer to get it), this also helps with framerate fluctuation. Also try if this happens at other places (try airport TXKF, Bermuda Islands) to narrow down the cause. Finally it could be an interaction with another plugin or third-party program causing this, you can try to follow the standard troubleshooting protocol to narrow down on it: Cheers, Jan

Hi Hugo, the green arrows on the EHSI show the position of the ADF 1 (thin) and ADF 2 (thick) direction. Bear in mind that a needle pointing to the 3 o´clock position can also mean "no reception", it is basically the default direction for the pointer to move to if no signal is received. The VOR bearing direction can only be indicated by turning the CRS selector until the magenta deviation bar centers. The RMI indicates correctly, you can switch it´s needles to also indicate the ADF bearings, though. So be careful what you select, default is VOR 1 (thin) and VOR 2 (thick). Cheers, Jan

Hello Sergei, yes, of course you can enter the coordinated to align the IRS to manually on the POS INIT page. The first few years I flew on the 737s we did not have GPS at all. The IRS would update on DMEs and VORs while in flight. We will look into modeling further "secondary" CDU pages as well after getting the more important ones still missing done. Cheers, Jan

I would not be opposed to the idea - the question is how easy it is to implement - if there is a way for us to tell X-Plane to "pause", it would be easy. I have added the request and we will look at it in our future enhancements to this plane. Cheers, Jan

...but why not shut down your computer while at work (works great for the electricity bill and the environment, too ;-)) and then when you are ready to play again you can spawn the aircraft at an airport "near" the ToD and then use the map view (key m) to place the aircraft at the correct altitude and speed and then "resume" your flight? Cheers, Jan

Hi, this is a current limitation of the manipulator we use for the V/S wheel. I explained it in another post recently, it basically works like this: In the real 737, the "wheel" for the V/S can spin without limit. X-Plane does not allow that, it needs a certain "limit" for maximum revolutions. Normally a value is tied to these revolutions - like on a thermostat. 20 degrees is always at X degrees manipulator turns. Unfortunately the "0" point for the vertical speed wheel "resets" every time you pick another pitch mode...but the wheel does not reset. So now the new "0" is not in the "center" of the revolutions anymore. So if you keep using the V/S wheel to descend - picking another pitch mode in between frequently - you will eventually run out of V/S downward travel. To "cure" this (until we find a fix) you can turn the V/S wheel "upward" again while NOT in V/S mode (you could just go to CWS P for a second) - then reengage V/S. Now you have the "full travel range" available again. Cheers, Jan

I also dare not ask - but did you try to "grab and move" the switch instead of "clicking" it? A lot of the switches (especially on the overhead panel) are manipulators that are designed that way, especially if they have 3 positions...

Maybe you can take a screenshot of your overhead (fuel pumps) panel when it happens the next time? Also, did you output the fuel weights (small green numbers) on screen to verify fuel is getting used (or not) on screen? I want to rule out a failure of the fuel gauges updating... The next step would be to delete your preferences folder, and if that doesn´t help you would need to do a full re-install of X-Plane and only the 737. These (especially the second) are big steps involving a lot of work, but I am really at a loss what could be causing this for you besides some weird corruption that happened to some of your core files... Cheers, Jan

Hi Biggee, I am really at a loss what could be causing this - but the usual suspect is an incompatibility with other plugins and add-ons. Make sure that Gizmo is running correctly (you should be getting the pop-out window when you bump your mouse at the right edge of your screen) and maybe disable other plugins (XPUIPC, FlyWithLua, etc.) for testing purposes? Let me know how this goes, and also attach the log.txt to your next post so I can look at your setup for a more educated guess? Cheers, Jan

Hello sujit, There is no need to take action now. Once you have built your new machine you can install X-Plane and then the IXEG 737 on it. When you try to run for the first time, the software will tell you that a new hardware system was detected, and it will ask you to specify a "name" for the new hardware system. You can name it anyway you like, but it should be a name that you can remember and that is unique. If you have already installed the 737 three times or more, it will also ask you to "lock up forever" an older machine (maybe the one you are using now, because you will never use it again). Then you need to specify the name for that machine (from the list) and also type FREEZE to confirm that you really want to lock it. Warning: Once you FREEZE a machine, you will never ever be able to run the IXEG on it again. Cheers, Jan

PS: I just googled the problem a bit and it seems that there is a bug in X-Plane where if you have the "instructor operating station" open on another window, the plane will not use any fuel (as the IOS constantly "refills" your tanks). Could this be a factor in your case?

Hmm - there may be a lead in your description - do you have the APU running while you fly? Maybe there is a bug in the fuel usage code with that - I will try that on my end... You are running two plugins that I would consider "suspect" in this case: RealityXP and XJet. However to really get to the bottom of this you would probably have to run a (lenghty) elimination process where you fly without any plugins to see if that fixes it - then bring in your plugins in batches to try and isolate the problem. I believe you when you say that no other planes suffer from this, but I dare to say that few other planes have an intricate system modeling that may be affected by these plugins in the way our 737 is. In addition this is a very isolated report - in fact it is the only report we ever had of our plane NOT using any fuel...so I deduce from this fact that it must be something unique to your setup/plugin environment. I will happily help you narrow down on the cause, of course! Cheers, Jan

Hi mirza, your observations are correct - the master caution for the center fuel tanks will only come on if BOTH pumps show low pressure. Usually one of the pumps runs dry first, depending on the aircraft acceleration and attitude (fuel going forward or aft). When you turn the pumps off, the low pressure lights extinguish (unlike the regular wing tank fuel pumps). Also when you turn off the center pumps (I forgot which one of the two) you start the "scavenge pump". It will run for 15 minutes or so and evacuates the remaining fuel out of the center tank into one of the wing tanks. Cheers, Jan

Hi clif, thanks for the nice words - I honestly have no idea what may have caused that problem for you - we pretty much use the normal X-Plane fuel usage logic for our engines... The cost index is describing the relation between flight-time related costs (maintenance costs, crew costs) and fuel prices. In other words, if the fuel was mega-expensive and the crew works for cheap, the cost index is 0 (best fuel economy). The actual speed results from the cost index and the wind component - headwind will make you fly faster (to get out of the wind sooner) and tailwind will make you fly more slow (to coast in the tailwind longer). If fuel is cheap, the cost index is high. Pilots can also alter the cost-index (usually one is recommended on the flight plan) to cater for delays (fly faster to make up time) or to save fuel if they arrive early otherwise. Cheers, Jan

Hmm, no - the cost index should have nothing to do with it...could you attach your log.txt so I can check if maybe you are running some other plugin that may be interfering with this?