Litjan

And I also doublechecked the engine start times in our latest version: Time from actuation of start switch to 25% N2 (fuel introduction): 20s Time to starter cutout (46% N2): 25s Time to stable idle run (21% N1): 55s I agree that the time from 25% N2 to 46%N2 is a bit too fast (this is a X-Plane problem that should be solved in the near future, I worked with Austin on this), but the total startup time is realistic.

I am not sure if you are using the IXEG or some other aircraft?? Here is the LIGHT TEST button, if you activate it, no sound is played: Here is the Firewarning test switch, if you toggle it to the right, the warning lights illuminate and the bell sounds: Here is the EFIS CONTROL PANEL with the VOR/ADF pushbutton, if you enable it, you can see RMI indications on the EHSI map:

No one likes to hear that, I will maybe just say in the future that I have no idea why someone is suffering crashes but good luck and all the best! For some reason people like to hear that more than the cold hard truth . Note that if you file a bug report with Laminar about your X-Plane crashing and they see a log like this, they will politely tell you that they are thankful for your report and that making X-Plane stable is one of their chief priorities and then they will suggest that you install X-Plane fresh (I wonder why they would suggest that? ). Try it if you don´t believe me And I´d like to point out that "Better pushback" miraculously installed itself into your vanilla installation. However - this should not cause the crash, it would be interesting to know if a (true) vanilla installation runs on your computer without crashing and if it starts crashing after you added the IXEG (and Gizmo).

Remove everything that did not come with the initial installation of X-Plane. Then run X-Plane and you will find that it will not crash. Then start adding everything you removed one by one, and test for a longer time before you add the next item - once it starts crashing, you have found the problem (it was the last thing you added). I can not tell you which of the myriad of add-ons and extra scenery causes your crash, not even Laminar will know, you have to find out yourself. The more you add to X-Plane, the more likely it is to crash. I recommend running it as "vanilla" as possible for a stable experience.

I thought we fixed the quick engine start...it was a problem with X-Plane itself, not our add-on. Let me test that when I get home on Tuesday, I will get back to you. The crash will likely go away if you delete all that cr*p you piled into your X-Plane installation and also update your Nvidia drivers.

Hi! 3 and 4 are known (and mentioned in the "Things not working in..." post I made. The others are new to me - I will test that at home, but I think you are doing something incorrectly. The bell only activates if you do the fire warning test on the center pedestal fire warning panel. This is correct and the real plane does it, too. The light test is not part of the preliminary procedure (enabled with the BRT/DIM/TST switch), and it should not trigger the bell. The VOR needles on the EHSI should work, make sure you have the button on that enables the arrows and that the VOR can be received.

Great pictures! And I am happy that you seem to enjoy the plane, make sure you explore some of the options like using the "classical" steam-type instrument panel (you can switch on the fly)! Happy landings!

I will have to doublecheck - I am not at home right now and don´t have access to my X-Plane computer until Tuesday - but there could (should) be custom commands for the landing/taxi/strobe lights (search for the term "ixeg" in the command list). The problem here is that for example the strobe lights have three possible positions (auto,on,off) and therefore the default X-Plane commands do not work for it. I do have the full specs for the 737-300, I retained it from the time when I was flying the plane in real life, but it is on paper in big books and it is proprietary information that my airline does not allow me to share publicly. If you find any official documentation on the aircraft online, that should work.

I think the year is fixed - you can not change it. But the day/month you should be able to set using the switches just like in the real aircraft.

Thanks for letting us know about the solution, this will help others in the future with the same problem.

You need to updated the Navdata, not the aircraft. You will need to purchase a navdata set from Navigraph (google it) and buy an updated set of navigational data. It will contain the point that you are trying to enter (they change all the time in the real world), you need to install it into the folder that Cameron mentioned (Navigraph data contains an installer that will do it for you).

Thanks for the nice words! This is the first time I have heard about a problem like you describe it...upon releasing the left mouse button, dragging the mouse should not move the manipulator anymore. I wonder if there is anything special about your mouse? I will doublecheck the manipulator behavior in 12.1.3 tomorrow - what kind of framerates are you getting?

I just doublechecked, indeed the light in the forward entry area does NOT turn off when the cockpit door closes and the camera is in the cockpit area - I will talk to Tom and see if we want to implement this (again). Thanks for the headsup, @manguras!

Hmm, I thought that we automatically "turned off" the cabin lights when the cockpit door is closed to avoid this effect (which - Cameron is right - can not be controlled otherwise by aircraft designers as X-Plane does not calculate shadowing by aircraft parts). I will have to check later today...

If the cockpit appears "dead" AND you can see the pilots, even while sitting in the cockpit, that means that your Gizmo plugin is not working correctly or did not validate your license correctly. This is the relevant part of your log.txt file: dlerror:dlopen(/Users/louislepage/X-Plane 12/Resources/plugins/Gizmo64.plugin/mac_x64/Gizmo64.plugin.xpl, 0x0006): tried: '/Users/louislepage/X-Plane 12/Resources/plugins/Gizmo64.plugin/mac_x64/Gizmo64.plugin.xpl' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/louislepage/X-Plane 12/Resources/plugins/Gizmo64.plugin/mac_x64/Gizmo64.plugin.xpl' (no such file), '/Users/louislepage/X-Plane 12/Resources/plugins/Gizmo64.plugin/mac_x64/Gizmo64.plugin.xpl' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')) I don´t know anything about Mac computers (only that they are bad for playing X-Plane), but this seems to be the problem. Maybe something is incompatible... If you can´t figure it out (or someone here like @Cameron can shed some insight), you will have to go and file a support ticket with X-Aviation. This thread may be of interest (it says that Gizmo can not work with ARM, if I understand it correctly) https://forums.x-pilot.com/forums/topic/27542-ixeg-is-not-usable-in-apple-silicon-with-latest-gizmo-avionics/Cheers, Jan

Hello alireza, Please read the list of things that do not (yet) work correctly - as displayed prominently in our support forum here: https://forums.x-pilot.com/forums/topic/8526-things-that-are-not-going-to-be-in-v15/ You will see that VNAV during descent is not considered reliable in all cases and you as the pilot are responsible - just like in a real aircraft - to make sure that you follow your planned vertical profile and revert to other autopilot modes (like V/S or FL CHG) to ensure adhering to it. The ILS localizer alignments in X-Plane are in general more and more accurate these days. If you tell me which airports and runways you experience misalignments, I can investigate what the problem may be. Cheers, Jan

The IXEG 737 is provided for X-Plane 12 only. It will not run on XP 10 or XP 11.

In a way that is very true! There was a famous accident with a Hapag-Lloyd Airbus A310 in 2000, they took off and wanted to fly to Hannover, but the landing gear did not retract. They looked at the FMS and it said that they could make it all the way easily...but the pilots did not know that the FMS did not calculate with the additional drag of the gear being down. The pilots failed to do the basic "fuel flow x estimated flight time = fuel needed" calculation, instead relying on the FMS...and made a flame-out landing in Vienna because of fuel starvation.

Thanks for the kind words! Yes, 1.5 is the current version for XP12. We are planning to updated the aircraft further in the future and are very aware of it´s current shortcomings, especially in the FMS department. Unfortunately we can not provide a realistic timeline as to when the next update will drop, we have a history of lengthy dormant phases and then stretches of working hard on the aircraft - both Tom and me do this as a side project in our lives in addition to our "real" jobs and family, so don´t expect the same cadence of updates that you would get from a dev team that does this "full time". As you said, the plane can be flown safely, realistically and (I think) with having a lot of fun with it - I flew the real aircraft for 10 years and regularly fly our model in it´s 1.5 status and still enjoy that immensely...despite the shortcomings. I know this may sound apologetic, but real pilots (at least the older ones) still pride themselves in their ability to calculate and execute descent planning better than the FMS can . Cheers, Jan

V2 should be in the 120-150 range...not 437. The maximum allowable speed you can set on the MCP is 340.

Hmm, is this only happening on a certain path (i.e. the same airport and SID) or does it happen a lot and in various scenarios? If you could provide reconstruction steps and a log.txt, that would be helpful to find out what the bug is - because it is clearly that, not user error. The speed window should never show these out-of-bounds values, no matter what the pilot does. Thanks, Jan

Hi Seahawk, as stated here (check the last bullet point for FMS): https://forums.x-pilot.com/forums/topic/8526-things-that-are-not-going-to-be-in-v15/ the VNAV calculations during the descent part of the flight may be erroneous, especially if restrictions are part of the path coding. Entering restrictions manually is further increasing the chances of things going wrong. For now we recommend calculating descent paths manually, there is also a "descent path helper table" available in the documentation that you can refer to. The landing elevation on the overhead panel is used to set up the pressurization system - it has nothing to do with autoland or the autopilot Chances are that you used a wrong approach speed, the wind was unusual or your center of gravity was out of limits - however it is pretty normal for the 737 to not do a very smooth touchdown when using autoland. Happy landings!

Interesting! ...and hard to reproduce, of course - with your report being the only one for this so far (after many many years and many many users ;-)). If this happens repeatedly, you can "reboot gizmo" while on the ground, that should really clear all variables and reset the plane as if you just booted X-Plane. Cheers, Jan

If you log in to the forums and there is not a post about the update, it means exactly that.

Hi Jarret, That looks cool! I think posting the .acf file here should not be a problem - the aircraft does not run without the other files and the DRM, so there is no risk of someone "pirating" the plane. Maybe give a short credit (like "This is a modification of the original .acf file by IXEG"), so people know the heritage of your work. Cheers, Jan