Litjan

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

Huh, that is really weird. The checklist is a simple .png file with 1024x1024 pixels, found in the main folder of the 737. Maybe you have opened it, turned and resaved it? It should look like the pic below, clicking on it swaps the front and back... Regarding the views - we planned to remove the "preset" views, but found that some people still like and use them. They are from a time when there was no "custom views" in X-Plane. Nowadays it is much easier to set up views the way you like, then press CTRL-NUMPAD key (any number) to save a view, then the NUMPAD key (same number) to recall it. You can also map those custom views to your joystick buttons. So if the default views give you trouble, just use the default X-Plane view system. Cheers, Jan

There is one more thing you can try - switch off the WXR SYSTEM switch (found between the two CDUs). Some meshes have a very high count of elevation points - our weather and terrain radar scans these elevation points at regular intervals and we had reports of those causing "code slowdown" every few seconds. The other question is: What kind of framerate are you getting with OpenGL and with 11.50? Cheers, Jan

Wow, nice shots! Yes, I think X-Plane still contends pretty well with MSFS at night! Regarding the rudder - on the real 737 you do not need to use the rudder at all - except when taking off and landing (to track the centerline) and when you "decrab" for landing in a strong crosswind. Obviously you also need it during an engine failure - thats why the rudder is very potent, it needs to be able to offset the large assymetric thrust when an engine failed. So during "regular flight" you should not use the rudder at all, there is no need for "turn coordination", as the roll spoilers cancel any adverse yaw. That being said, the rudder shouldn´t cause you to crash, maybe your butterfly switch is set up in a way to "increase" the deflection while it is pushed down, reaching large angles very quickly? You can output the values for flightcontrol deflection as "small green numbers" on your screen if you choose the Data Output tab and click on the leftmost box for "flight control deflections" - that lets you troubleshoot problems like that. Cheers, Jan

Glad you got it sorted out - and thanks for reporting back with the fix. I still don´t really know how all the "deleting preferences" works, but it seems to be some sort of magic fix for a lot of things. I wish that would work in real life, too. I had my second simulator session last night for requalification on the A320 and the brand-new A320 NEO simulator we had developed a software problem mid-session. Some buttons didn´t work, couldn´t use the transponder panel, stuff like that. The technicians had to run several resets and we had to wait 45 minutes before we could resume the session...got home at 2 am... Cheers, Jan

...and I just doublechecked as I saw your post on the .org - my floodlights work fine with 11.50r3. Cheers, Jan

Hmm - I see a few reports of these ones in your log: 0:00:25.142 E/OBJ: ERROR: object Resources/default scenery/sim objects/apt_beacons/beacon_mil.obj has a bad light name: apt_beacon_white_mil_glow Maybe one of your light replacements or other experiments has overwritten or changed some default files? I would try these things: 1.) Try to run with the latest beta of Gizmo (run the Gizmo installer) and see if that helps 2.) Delete (remove) your preferences: https://developer.x-plane.com/2016/11/you-dont-need-to-reinstall-x-plane-to-fix-it/ 3.) Run the X-Plane installer and let it find and fix any files you have changed 4.) Doublecheck for latest Nvidia driver and HDR on (the report of "light bulb bright but no light cast" is usually a telltale sign of it not working) If all of the above steps fail, you can reinstall the aircraft - but you will probably have to reinstall X-Plane as well to cure whatever damage was done. Cheers, Jan

Hi Fred, I am glad to hear that! Yes, flying a fast aircraft like that takes a bit more skill - but the feeling of accomplishment is bigger as well, I feel. I have flown the real 737 for 10 years and learning to fly it went from "totally overwhelmed" to "second nature" pretty fast. So I am sure you will get the hang of it - it is really constructed quite logically and operating it, even if things break, always "makes sense"...not like in the aircraft made by that "other manufacturer" I have to fly these days . If you have anything else that gives you trouble figuring out, just let me know. Cheers, Jan

Hi Fred, the tutorial is very old - and the functionality may have changed in regard to the EXECute light. Basically this key will light up every time you could change an ACTIVE routing. So the first time you enter a routing, you must press the ACTIVATE prompt on the RTE page, then the EXECute button should light up. Now every change to the flightplan or even entering a different weight will make the key light up - as a way of the FMS letting you know "Hey, you changed (modified) the active routing, if you really want to do this, please press this button. Hope this helped, Jan

Yep, 11.50r2 currently. Are you sure that your HDR is on? Cheers, Jan

Yeah, I have a request for that flagged - as Cameron said, when the more important fixes are done, we will turn to these requests. Cheers, Jan

Yeah, it may be that your light scripts screwed up some settings... here is what the cockpit looks on my end. The screenshots are a lot more dark than the "live" picture, for some reason... 1.) Just background lights, no map lights: 2.) Background lights with map lights: 3.) like 2, but including flood lights on DIM 4.) all lights full bright (including flood and emergency) Cheers, Jan

I can confirm the issue - affects the steam gagues, not the electronic versions. Added to bug list. Thanks again, Jan

Hi sho, it could very well be the problem - especially now with Vulkan in the picture. Please try to run without the light mod and let us know if that helped? Thanks, Jan

You are probably right with your observation. It is all to human for us producers and purveyors of a product to instinctively react defensive - especially when the customer pulls the "other products..." card . It strikes a very sensitve nerve in us competitive human herd animals! It takes the patience of a Jedi to not raise your heartbeat a bit when someone says "I have this problem with your aicraft, and all the other aircraft don´t have it!". It is akin to saying "how come you guys can´t do as well as the other guys?" Nevertheless it it always correct to point out a problem that you have with a product - and sure, if we don´t acknowledge or even deny a problem - reinforce the point by making a comparison with another product. Cheers, Jan

Good hint, Torbinator. I don´t have SAM, so I can´t confirm, but it is always a good idea to check for plugin dependencies when a problem appears. Cheers, Jan

Hi Torbinator, yes, we are unlikely to do extensive work on the sounds before the conversion. The biggest problem is one of resources, some users are affected more than others, and often those effects are intermittent, too - making them so much more hard to track down. Once the plane is FMOD I will count on you guys to help me catch and iron out any remaining quirks, though! Cheers, Jan

Hi sandpatch - thanks for the report! We recently "fixed" the EGT needle to show the exact same value as the digital display, maybe an error got introduced when that happened. I will verify and add to the list of things to fix. Cheers, Jan

Hi Logan, you have stumbled upon the "GPU bug" - we are currently investigating it and the next version of Gizmo should fix it. What happens is that after the two generator buses have been powered by the engines, it is not possible to power the LEFT gen bus again with the GPU. IF you look up while you get this "black and white" display, you will likely see that the left BUS OFF light is illuminated. This causes the avionics ventilation fans to stop, and consequently the CRTs to go into monochrome mode - same as on the real aircraft. You can recover this by powering the bus again (with the APU, for example). I know you wrote that the APU also causes this - if this is really so (please try connecting it to both buses so that the BUS OFF light is off), then we have a new bug on our hands. Hope this helps, Jan

Cameron is right, this can be misleading. Different aircraft are providing different methods and depth of simulation and that will show in the load on the computer hardware (i.e. framerate). We are constantly striving to improve performance and Ben Russel, the developer of Gizmo, has made great strides in this - plus we as the developer of the 737 are learning more tricks all the time as well. I am happy that the beta Gizmo brought some improvement for you. Especially with the increased "smoothness" of X-Plane (11.50 Vulkan) it has become even more important to us to not add unnecessary periodic load on the process and we still have some ideas in the pipeline. Cheers, Jan