Litjan

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?

Ok - I ran some tests on my end and I see the problem. I try to explain it: The control wheel for the Vertical speed on the real 737 can turn "without end" - infinitely. The pilot can spin and spin and spin...it will always be able to spin more. In X-Plane, the V/S wheel has a limit - it can only turn a set amount of revolutions. So if you spin it "down" until it stops - it can not spin "down" anymore. So if you select V/S and then spin down to -5000 fpm - then disengage V/S - then engage it again - you can not spin down to -5000 again, because it "hits the limit". To work around this problem you would have to "turn back" the V/S wheel while V/S is not engaged - this gives you enough "turns" again... It is a limitation of the manipulator in X-Plane...I will talk to Tom and Ben to see if we can use another manipulator of if we can work around this problem. I have opened an issue on our internal bug tracker and I will announce it once we find a solution. For now - if the wheel stops - just disengage V/S (it will go to CWS P and keep the rate), spin the wheel "back" and then engage V/S again. Thanks for bringing this to our attention (it will only happen if a user inputs large V/S values repeatedly, so no one reported this before. Cheers, Jan

Hello! This is a bug with the manipulator that I had once - but never again. I could not figure out what caused this. Normally you should be able to decrease the value at liberty - if the mousewheel does not work, try to "drag" with the hand by click-holding and then dragging down. Are you running X-Plane 11.50? There was a bug fix by Laminar Research that pertained to some manipulators not working right at certain angles... Let me know if you spot this behaviour again or if you can figure out what triggers it? Thank you, Jan

Hi mizra, I can make them start at a different location - I agree that the airspeed needle should be at the last value it was when power was removed...usually zero. The plastic bugs I am not so sure about, they would also be where the last pilot left them - which is usually just where they were for the last approach. I would think that it is easier to grab and move them if they are "spread out" a bit. But if you want to move them "all" to a certain value, just grab the highest one and slide it down, it will "collect and push" all the other ones so it is just one single motion. Cheers, Jan

Thanks for getting back to me on this! You can also enable the DATA OUTPUT field #62 (fuel weights) to readily see on screen how much fuel is in the tanks and if it is getting used. If you can find a way to reliably reproduce our 737 to not use any fuel, please let me know! We want to fix it (or sell the technology to the airlines!! ;-) Cheers, Jan

Hi clif, this is unusual - some observations: Fuel loading in the 737 only works through the IXEG side-pop-out menu. You can´t load fuel through X-Plane´s fuel menu. You can see the fuel loaded in that menu, though. When entering a PLAN fuel - this never changes. It is a value the pilots can input to PLAN a flight (i.e. if the real fuel wasn´t loaded yet). Don´t use the PLAN field - or if you do, eraze it afterwards (this will otherwise stay locked and never change the gross weight). Switching off the fuel pumps will not starve the engines - not in a real 737, either. The engines will keep running through suction feeding, but thrust degradation at high altitude or high powersettings may occur. Now I have to doublecheck if using a PLAN value will preclude fuel from being used - that would of course be a bug! Normally you don´t have to reboot the aircraft after a flight - you can just go on the next one. Cheers, Jan Edit: I just doublechecked - using a PLAN fuel input does not affect fuel usage on my end - on the first flight. Are you running any plugins that could be affecting this? It is the first time I have heard of this problem.

Oh, thank you for letting us know! It should not be this way, we will doublecheck! Happy you got it sorted out, all the best, Jan

Why is your folder named X-aviation - when the instruction clearly says "X-Aviation"?

Hmm, that is weird - are there any special (greek alphabet?) letters in the folder names? Also make sure that the folder is named IXEG 737 Classic (no underscore lines like this: IXEG_737_Classic). Also make sure the folder is Aircraft and not Aircrafts. Let me know how that goes? Cheers, Jan

Yes, the solve is as follows: Detected an unsupported file path. Please make sure this aircraft is installed in [your X-Plane folder]/Aircraft/X-Aviation/IXEG 737 Classic/ and restart X-Plane. In other words - your IXEG must be installed to the filepath as specified. Please doublecheck your installation folder and if necessary re-install to the correct folder. Cheers, Jan

Hello, not sure about the TCAS targets - nothing was really changed for that - I will have to try on my end to see if the traffic still displays. The problem with the gross weight sounds like you enter the PLAN fuel weight - it never updates because it is only used by pilots on the ground to "plan" for the flight while the fueling is not finished yet. Don´t use the PLAN fuel or at least delete the entered value so that the real fuel weight can be calculated and added to the ZFW to yield gross weight. Cheers, Jan

Hi Andi, you should be able to change the speed and altitude constraints for a waypoint - but the FMS may not fly the profile correctly. This will be part of our VNAV rewrite that we are working on. To change (or add) constraints to a waypoint you dont "click on the left side bottoms" in the FMC. You need to type the new constraint into the scratchpad (i.e. /250B for "be below FlightLevel 250") and then click on the right line-select key next to the waypoint you want to add this constraint to. Grüße ins Ländle, Jan

No, to my understanding you will not get ANY random failures if that box is unchecked. If you check it, you can set the MTBF, which means X-Plane will randomly fail something at an average time as set. Cheers, Jan

Hi Torbinator, you are correct - there will be a setting in planemaker to "always force experimental flight model on". We will incorporate that in our next update - but I think you can just set the option in the .acf file yourself right now so it *should* always work. I haven´t tested this yet, but will soon. Cheers, Jan

A lot of shortcut commands were changed/corrected/added - maybe that is causing problems for old assignments? Cheers, Jan

You can just see it more readily because the ground "rushing by" covers more appearant angle when you are close. If you are tracking a taxiway light with your eyes while you pass it taxiing at 30kts it you have to turn your eyes like 50 degrees in one second. If you watch the same taxiway light while flying by at 5000 feet you need to turn your eyes 0.5 degrees per second. So if you have a "stutter", the "jump" of the light is bigger when you are passing close by. Cheers, Jan

There is a lot of calculation going on behind the scenes when you run the IXEG 737 - and with the base simulation becoming faster and more smooth, this calculation (naturally causing lag) is becoming a bit more appearant. In the past the emphasis was on causing "less total load" on the system - so you would run some operations only every 5 seconds, instead of "every flight loop". This would allow to keep the general framerate up, and small dips did not "stick out" very much in an already fairly slow and stuttery base simulation. Now with Vulkan allowing faster and really smooth framerates, calculation delays cause these observable stutters. Ben is continuously working on evening out the load placed by these computations by improving Gizmo, and we will also have to look into our code and decided if we need to "spread out" things more to get a more smooth load - at the cost of diminishing framerate. If you look at other add-ons of comparable complexity (I am not talking a small Cessna or TBM here) you may also see either a more choppy rendering or a fairly diminished framerate compared to "default" aircraft. We strive to make things as smooth and fast as possible - but naturally we need time to adapt to the post-OpenGL situation. Cheers, Jan

Hi mizra, this is indeed not portrayed in the correct direction on our 737 yet. I have had a ticket open for this for quite some time, it needs some artwork and some logic work and in 6 years no one ever noticed - except for you, good job! You are right in your description of how it should work - we currently have the OVHT test assigned to the DOWN position (it works correctly). We have no label for the PWR TEST and it is not working - but the only way to see this working in the real aircraft would be to hold it to that position and feel if the windows will heat up - after a while they should also trigger the overheat protection, especially in the summer, as the window heat is forced to full power with this switch. Cheers, Jan

Nice!

Hmm, I would have to look up the logic for the FMS resetting - it could be that it needs to get airborne or past a certain speed first before the 60kts rule applies. I am not at all familiar with SimBrief, but yeah, having the .fpl file in the correct location should work! I am not sure if maybe the algorithm only checks for .fpl files once when the plane initializes? Maybe try with the "gizmo reset" trick and see if it takes the (new) .fpl then? If so then we clearly have something we need to fix! Whats interesting about the speedbrake is that on the real 737 those "end switches" sometimes were a bit "rusty" as well - so the first thing the Captain does when the horn goes off is slam the lever forward really good ;-) Cheers, Jan

Note that you can really comfortably read all of those through the "avitab" EFB, too - I am sure you have that installed? Cheers, Jan

Hi mizra, the FMC should erase the routing once the groundspeed is under 60 kts, iirc. If this doesn´t happen (I haven´t seen this not working), you can manually reset it by entering a new ORIGin in the RTE page. I have heard of the takeoff config problem before and I believe it may be related to a variable with the spoilers not resetting all the way to 0. Another indication of this is that after a replay the spoilers always "pop up", even though I make sure that I stow them before I enter replay mode. It could also be due to an axis being assigned to the speedbrake and that axis not going back all the way to 0 - although I have relaxed the requirement for that a bit in one of the last patches. Two options: Test the takeoff config warning by quickly advancing the levers when you are on the taxi-out to the runway (the engines are slow to react, so there isn´t much danger to create too much jetblast). Another option is to simply click "reboot gizmo" when you are at the stand - this will reset all systems for sure. The oxygen pressure depleting is due to "cold soak". The pressure goes down as the bottle cools off when climbing into cold air. I really can´t answer the if the stall warning should work right away - I have never tried this in the real aircraft (push right away) - they are dependent on the "stall warning computer", which may need a bit to boot up. No idea how long, though, definitely not "a few minutes". They are certainly not dependent on the IRS units, I know for sure we tested them before those were fully aligned (in fact only a few seconds after turning those on). Cheers, Jan