Litjan

Hi Dave, Yes, the view is like that from the rear, not dependent on the angle. I ment that we are not going to add angle-dependency in the future. It would not be hard for Tom to make the N1 disk opaque from the back as well. I personally have no preference, I haven´t looked through spinning CFM65s from the rear to really form a solid opinon. The way it is now seems plausible to me, but if we get more feedback on this...sure, we could change it. I will try to get some glimpses through the engines of our A320s when I go back to work, they are not that different. Maybe there is also a youtube video that one can find to prove (or disprove) your point? Cheers, Jan

Yes, this could be the problem - although I never heard that a file in our installer causes objection by Windows Defender.

Hi Sdwr87, I totally know the feeling of "when all things don´t go as expected"...so no worries. I hope very much that we are not far away from the stable 20.xx version, Ben is working his *ss of to get to the bottom of the remaining quirk(s). A lot of users are really good about reporting bugs, posting detailed explanation and attaching the Log.txt. But we had so many frustrating queries with not much to go on for us... Rest assured - your and our ultimate goal is congruent: Having a high-performant and stable Gizmo version without any on-screen interjection for the customer. Cheers, Jan

In the real plane this depends on the angle you are viewing - the blades are "slanted", so if you look from a slanted angle you can see through the "N1 rotor disk". Add the effect of something moving too fast to see and I think this is not so far from realistic. It is a bit like a spinning propeller - you can see it really well when the engine is stopped, but you can´t see it at all when it is spinning really fast. We will not model the opacity of the spinning fan blades dependent on obliqueness of viewing angle. Cheers, Jan

It is difficult to help you, because (at least this) seems to work for everyone else and you are not providing much detail about your problem. What would you tell me if I ask you "Help, I can not fly this plane. Can you help me? " Possible reasons: Wrong ICAO code. Airport does not exist in your nav database. If you could show us some screenshots (or even better a video) of what you are trying, it would help! Another solution is to try and find help on a local language forum if you are having trouble with english. Last but not least, you can watch my tutorial videos here: https://forums.x-pilot.com/forums/topic/10746-training-videos/ Maybe they can give you a hint of what you are doing wrong. Cheers, Jan

Thanks a lot for the nice words, Carl!

Relax, guys. We are providing the Gizmo beta for those willing to help us test it. This comes with some benefits, but also with some burden. It is exactly the same as installing an X-Plane beta version. Now the funny part is - the customers perception of what a beta run is is not the same as the vendors. The customer thinks that a beta is an improvement to the product. Not a regression. Anything not an improvement or at least being equal is considered a HUGE disappointment. The vendor releases the beta to test it against these regressions. Often that includes special "beta" options, such as increased logging of inputs and variables, or has other requirements. So here is the lowdown: If you want us to help make the next version of gizmo stable, smooth and an improvement, please install the beta version and provide feedback. It comes with some benefits, but also some caveat. Install at your own will, we appreciate your help! If you don´t want to, install the stable version. The white writing will stay until the beta run is over, how ever long that may take. You are entitled to a Gizmo version that is stable and has no white writing. You have that one included in your installer. If you guys keep going on about it I can tell you exactly what will happen...There is a LOT of internal discussion at X-Aviation if it is the right thing to include betas with our product, and I think I just about was able to sway the opinion to what we have now. If I won´t succeed in the future, you know why. But at least you won´t have the white writing anymore, then Cheers, Jan

Also - make sure that your speedbrake lever is really all the way down. When using the mouse or a hardware lever it is really easy to not push it forward completely. Looking at your video closely it looks like it MIGHT not be in the full forward position. In the real airplane we had that problem as well, from time to time. The first thing the CPT would do when the takeoff warning went off is to slap the speedbrake handle a bit. Sometimes the position switches got worn and would need a little whack. Note that you do not arm the speedbrake for takeoff like you would in an Airbus. I will nevertheless look over the code with Tom, and I will also "relax" the requirement for the speedbrake position a bit. Right now it must be 0 for the alarm to not sound, so any "spiky" axis assigned to speedbrake or a manual retraction to 0.000000001 would still trigger the alarm. Cheers, Jan

This is probably related, donoscar. It seems that when trying to connect both generators "at the same time" (as the GPU does), this problem occurs. The reason is most likely an underlying computational issue - Ben is investigating it actively and it would surprise me if he doesn´t get to the root cause of this. He always has . Cheers, Jan

Nothing was changed at all with regard to sounds. Cheers, Jan

I think I may be on to something... If you want to make sure this doesn´t happen for now, reboot gizmo during your stop at the gate (pick "turnaround" as a spawn option). Cheers, Jan

You would turn the switch to FLT as part of the "After start flow". If you forget it is not a huge deal, because the pressurization switches to FLT automatically as you lift off. You would just get an uncomfortable "pressure bump" during rotation, as the airstream rams into the (wide open) outflow valve. If the switch is in FLT, the outflow valve is mostly closed (to maintain the slight pressurization), so that this bump is avoided (passenger comfort). You would also notice the cockpit windows "rattle" during take-off run (this is not simulated ;-)). After landing, the Captain calls for the "after landing intems" when the runway is vacated. The FO does the flow, putting this switch to GRD is part of it. Cheers, Jan

Wow, that is a new one... I believe this line in your log hints at the problem: 1:04:12.947 G64: error: Run_MouseClick(xp): OnMouseClick: [string "ixeg.733.gui.lua.ra1"]:65: attempt to index a nil value 1:04:12.971 P/GVA: Updating position time from every 3 to every 2 frames (fps=42) 1:04:12.971 G64: error: Run(gui): OnDraw_Windows: [string "ixeg.733.gui.lua.ra1"]:218: attempt to perform arithmetic on a nil value So I will see what Tom says about this. Thanks for letting us know...and if you can reproduce it, we would be grateful if you told us how. Cheers, Jan

There have been reports of this happening on subsequent takeoffs...I have not been able to narrow this down, but it could be related to speedbrake position. I think that maybe the "speedbrake extended" position is retained in memory and not getting reset. Maybe related to the replay code. I will do some more testing. When it happens, try to pull the speedbrake up and then push it back down all the way. Thanks for the report, and compliments on the professional way you handled the aborted takeoff! Cheers, Jan

Ok, this is the second key on the right side? We haven´t seen any problems with it internally, I will doublecheck. If it happens again, try to tell us which page you were on and what you tried to insert, maybe with a screenshot? That would help us narrow it down. Thanks a lot, Jan

Yeah, this particular bug is still under investigation and not fixed with the latest Gizmo beta. Cheers, Jan

Hmm, some things crop up in your log.txt that may hint at the problem: A:\Xplane/steamapps/common/X-Plane 11/Resources/plugins/xpInsider32.xpl : Error Code = 193 : %1 íå ÿâëÿåòñÿ ïðèëîæåíèåì Win32. Failed: A:\Xplane/steamapps/common/X-Plane 11/Resources/plugins/xpInsider32.xpl. (This file is missing, not a DLL or could not be loaded due to another missing DLL.) Failed: A:\Xplane/steamapps/common/X-Plane 11/Resources/plugins/xpInsider64.xpl. (The plugin refused to start by returning 0 from XPluginStart.) You are also still running Marginals ground traffic plugin for various airports, could you try to remove that (temporarily) just to test? Did you change anything related to your shaders in X-Plane? Run any alterations to the way it "looks"? A lot of people have made tweaks to the art assets (either with a plugin, or manually) that will enhance the way X-Plane looks. Did you try with the "stable gizmo" version? You could also try to go back to OpenGL for rendering or even downgrade to 11.41 again (to check). If all else fails, try to re-install X-Plane (put a copy of your old installation in a safe spot to restore it later), and then just install the IXEG 737 and see if that works. No other idea at this point... Cheers, Jan

No, unfortunately not. This is something that would be nice - but it would require us to save every position of every knob and dial and also all the values (datarefs) that get affected by it. People would also expect the FMS to be in the state they left in, and that would be incredibly complex to do. Cheers, Jan

Yeah, I think the airspeed pointer should be at 0. I will set that up for the next patch. However - when you apply power - it will drive to zero. The dashes on the DME fields signify "no data" - I don´t remember if there were dedicated flags. Cheers, Jan

We used the rotary AC meter switch after engine start to check the generators for nominal output. But that was it. Yes, the FLT/GRD switch was always used - to FLT after engine start and to GRD after leaving the runway. Pretty important, too, for various reasons (like slightly pressurizing the aircraft before takeoff and depressurizing it after landing to enable opening of the doors). Cheers, Jan

Are you sure that you have turned electrical power on? That is the only thing I can think of. If that does not help, please follow the standard troubleshooting protocol outlined here: Cheers, Jan

Yep, this is how we did it. The fuel pump for APU was not really a requirement, although some technicians used to do that. The APU ran fine without it. Engine bleeds were not touched all day. Too dangerous to forget them on subsequent takeoff. Cheers, Jan

I am very happy with the way it handles. Have flown both Cessnas and this aircraft. You can absolutely tweak the flight model using the planemaker, of course! Cheers, Jan

Be aware that using the "start with engines running" in the X-Plane menu has no effect on our aircraft. You need to set up this in the IXEG menu (PREFLIGHT) - pick the option "READY TO FLY". Cheers, Jan

Hi Joni, thanks for keeping us on our toes! 1.) The Nav lights are off on purpose. You would only turn them on at night or in bad visibility, thats why I chose to leave them off. I am open to debate, though ;-) 2.) I can confirm the UV map problem on the upper and lower side of that plate. Thanks! 3.) The reverse thrust is limited in N1 - so the fuel flow is throttled at about 3000kg/h. This is the same in the real aircraft. The "jitter" you see is our code artificially limiting the fuel flow, it is a bit more elegant in the real plane. Although I must say that I rarely looked at the fuel flow when using reverse thrust in the real aircraft. Cheers, Jan