Litjan

Thanks for the logs!

Well, Laminar is wrong, because the add-on developers themselves have no clue why your X-Plane crashes at 20.2% N1 . There are a myriad of possible reasons in operating systems and hardware, we used the OpenAL engine for our sounds to our best ability but I think there is nothing we can do right now to fix this for you...except ask you to keep your window closed during engine start and maybe wait for us to move to FMOD sounds, it is planned for the future!

Thank you for the logs - despite what Tom said about possibly secretly "fixing" the frequency problem, what speaks against that narrative is that I have NEVER experienced our frequency to be out of bounds or not set to what it used to be set to previously... Looking at your log.txt I see that you load SEVERAL aircraft (A300, MD82, C172, 737-800, SR22,...)but never the IXEG? Here is a snippet from your log: 0:01:10.035 I/FCG: Starting new flight in Aircraft/iniSimulations/iniSimulations A300-600R(F) v2 - Passenger/A300_P_V2.acf at Piste 05 0:01:10.035 D/STM: Transitioning from state state_QuickFlightWizard to state_NormalLoading 0:06:47.236 I/FCG: Starting new flight in Aircraft/Laminar Research/McDonnell Douglas MD-82/MD80.acf at Piste 05 0:06:47.236 D/STM: Transitioning from state state_Normal to state_NormalLoading 0:07:34.371 I/FCG: Starting new flight in Aircraft/Laminar Research/Boeing 737-800/b738.acf at Piste 05 0:07:34.371 D/STM: Transitioning from state state_Normal to state_NormalLoading ...and so on... It would be interesting to see a log.txt where you actually USE the ixeg (and no other aircraft at all). Do this, please: Start Xplane, use the IXEG and set both NAV receivers to 115,00. Then shut down X-Plane. Now load X-Plane again, using the IXEG and see what the NAV receivers are set to?

That is a crazy coincidence! It could be something related to sounds, but we are running our OpenAL sounds, so I can not imagine how that can crash X-Plane?

That is TWO OF US! Don´t ask how many times this happened to me when testing and then I wonder "WTF is wrong now??"

Interesting, thanks for the videos! I have no idea what would initialize these frequencies in a different way. We COULD possibly code a way to store the last frequencies or at least default to valid ones, but as you said it is not a huge problem. I would like to understand why this works differently on different computers, first. If you guys want to, you could post log.txt files from your sessions so I can take a look if there is maybe something you have in common?

Scavenge pump http://www.b737.org.uk/fuel.htm (Scroll down to about midway, the scavenge pump system is explained there) It is possible in the real aircraft, but due to technical limitations it is not possible in our IXEG aircraft. We would like to fix that in the future. To solve the problem you are reporting I would recommend to either fly from the FO´s side (and put the weather radar display on the CPT´s side) or you can DIM the weather radar returns (the brightness knob for the EHSI is actually TWO knobs, one is for wxr/terrain) so that they don´t blot out the navigational info. Cheers, Jan

I would check the fuel level...

I just tested on my machine and between reloads of X-Plane the frequency of NAV1 stays the same and NAV2 decrements by one "click" for both the megahertz and 25 khz knob. The nav radios show default X-Plane nav frequency datarefs, so if you see something else you may want to check other aircraft you fly in between or third-party plugins (flywithlua, etc.) that may fiddle with this. Also make sure that you always select the "engine running" option in the X-Plane flight setup GUI, even if you then use the "cold and dark" initialization in the IXEG menu. The communication VHF radios stay at the same frequency for me.

Ok, I will doublecheck those reports today. In reality the nav frequencies stay at the last frequency, as they are mechanically moved, and they should not be outside the valid band in any case.

I can not reproduce that - on my end the frequency is still the last one I set it to when i shut down X-Plane from the previous session.

Yes, the ultimate line in the log.txt shows that X-Plane detected the crash, but no further hints at why that is. I think that providing the crash report to Laminar Research in the form of a bug report could help, they should have the technical ability to diagnose the reason why X-Plane crashed.

Hmm, ok - I don´t know what the problem is, then I think Pils is right, since there is an entry in your log.txt that X-Plane detected the crash --=={This application has crashed!}==-- --=={FILE: D:\X-Plane 12\Log_ATC.txt}==-- there is a good chance that Laminar Research can figure this out.

Do two more things for me, please: First, remove all the scenery that has plugins (Marginal ground traffic) associated: Fetching plugins for Custom Scenery/MUSCAT_OMSS_TAIMODELS_XP12/plugins Loaded: Custom Scenery/MUSCAT_OMSS_TAIMODELS_XP12/plugins/GroundTraffic/64/win.xpl (Marginal.GroundTraffic.MUSCAT_OMSS_TAIMODELS_XP12). Fetching plugins for Custom Scenery/2_b_OMDB_Dubai_Taimodels/plugins Loaded: Custom Scenery/2_b_OMDB_Dubai_Taimodels/plugins/GroundTraffic/64/win.xpl (Marginal.GroundTraffic.2_b_OMDB_Dubai_Taimodels). Second, try to run without any AI aircraft and also do not use ATC. Does it still crash then?

How did I know this would get asked?

@trisho0 Hi and welcome to the IXEG 737! This post may answer a few of your questions as a new user: Let us know if there is anything else we can help you with. Cheers, Jan

I have tried to replicate this problem - but was not successfull. For me this works as expected (no error). Since you are the only one reporting this so far, there is the chance that you do something very unique to trigger this error, I doubt that it is interference from another plugin (although flywithlua and volanta are known to cause problems sometimes). If we can not get to the bottom of this, one solution would be to trigger the "reboot gizmo" function (right-side pop-out menu, the small "flash" symbol) to reset the logic for the second and subsequent flight... Cheers, Jan

Thanks for confirming that - I will replicate this tomorrow and give Tom detailed reproduction steps.

I REALLY don´t want this thread to devolve into the same old same old "my sim is better than your sim" discussion. We X-Plane people don´t care how many copies MSFS sells (maybe a little bit, the more the better since it introduces people to the flightsim genre that might try X-Plane as well later on), we only care about how many copies we sell and if those are enough to cover our cost and make us enough money to keep doing this. We could make a LOT more money coding some farm game where you can raise pigs or plant barley, but we like making airplanes better.

You still have a bunch of (potentially conflicting) plugins running in your installation - I am especially wary of the terrain radar plugin and the marginal ground traffic plugin. ActiveSky and XPilot are also non-default plugins, they should work but you must make sure that you have the latest, XP12 compatible versions. Last but not least - it could be that running Zink might cause problems with the OpenGL rendering functions we use, so it might be good to disable Zink, just to test this theory.

Hmm, but then people would complain that "in the real plane the switch pops back to neutral the second you let it go" I think that is just one limitation we have to live with. If you don´t trust the cutout switch, you can trigger a fire via the failure menu, use the cutout switch to silence the bell, and once you have established that it works, extinguish the fire by "fixing all faults" and then commence with the cockpit preparation . Hmm, maybe we can assign a command to the switch so you can use a key or button to "hold" the test switch?

Right - getting to the core of these bugs is super time-intensive...but maybe if you fly the same routing again and the plane looses the track over IKEKA again, let me know. Cheers, Jan

Hello Pavel, currently there is no option to show the displays in separate windows, but there may be in the future. One way to make the appear larger is to get a larger monitor and sit closer to it, that is what I do. We won´t do the loading and fueling in the FMS, but there will be a new and improved GUI that will allow loading and fueling the plane to your heart´s content - I am working on that with Tom at the moment. Cheers, Jan

Huh, that is the first time I see that reported... this used to be a problem on the default GPS units in X-Plane until Philipp fixed this recently, if the leg distance was over 60NM or so, the plane would veer offtrack in direct-to mode. But haven´t seen this (or heard about it) in relation to our 737. You do have a vast assortment of potentially conflicting plugins in your installation and unless I get more reports about this happening on our 737 I would have to ask you to run the IXEG in a "vanilla X-Plane installation" to rule out interference, just to test this. If you have a "surefire" way to trigger this misbehavior (like a route that ALWAYS does that at a certain point), please let me know and I will verify it on my end.