Litjan

Hi Seamaster, thanks for letting us know! We will try to replicate this crash - if this happens to you another time, please attach the Log.txt to your post, that makes it easier for us to track this down! Thanks a lot, Jan

Hmm, ok - or maybe you heard another (AI) aircraft taxiing by? The ones with FMOD support can now be heard outside, caught me off guard a few times . Cheers, Jan

Thanks for reporting back, Denn. This may prove very valuable for other people with the same problem (I know there was at least one other customer...) Happy flying, Jan

Ah, thanks for the headsup. I remember we had that problem before. Solution is to make one manually, but it should be in the installer, of course! Then again...maybe including it would overwrite everyone´s stored routes? Cheers, Jan

Not sure what you exactly mean. We have not changed anything with the sounds at all. If I choose "ready to fly" and then choose "cold and dark" I hear exactly nothing at all. Cheers, Jan

Output (DATA OUTPUT option in X-Plane) your thrust and your brake setting to screen (little green numbers). Then show us a screenshot of when you try to taxi out... Jan

Roger, lets get some more input - and I agree, the "totally unobstructed view" is probably not very realistic . Cheers, Jan

Was thinking...did you at some point install or apply a mod/tweak that changed the streetlights? There was a fairly popular mod out that tweaked these artref values to make them more bright or extend the range or such... I believe that this may cause our "lit" textures to become dim. Cheers, Jan

Oh, look at this video I made a while back - engine just spinning with the wind... FanMilling.zip

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