Litjan

My favourite video on the subject...

You are most likely running into a "range" limitation of the FMS data point loader. We had to limit the scope of the database to a certain distance - including all fixes and airports worldwide would lead to unacceptable slowdowns during access. The real FMS´s work just like that, they never hold "the whole world", but mostly a certain region of operation. Since a lot of users seem to like using the 737-300 outside of it´s typical operation regime (flights up to 3h), we consider extending the range a bit with one of the next updates. For now you can work around this by planning your flight to maybe Iceland, then reboot Gizmo while you are enroute over Greenland (this reloads the database in a certain range around you), and after stabilizing the plane again (gear up, AP on, ALT HOLD, A/T on, select speed) you can enter EIDW as a destination, and then start building your route again. Cheers, Jan

There will be a resolution advisory, consisting of both the symbol changing colour/shape (red square), a voice advisory (i.e. "climb, climb") and EADI symbology showing a pitch target ("keep out zone") to achieve the necessary change in vertical trajectory. Jan

It´s perfectly normal for the plane to fly the current heading when you disengage/change a VERTICAL mode. The direction of the plane is determined by the LATERAL mode (LNAV, HDG, CWS R), while the vertical patch (pitch) is controlled by the VERTICAL modes (VNAV, V/S, FLCGH, CWS P). So I think you are not seeing VNAV issues but rather a problem with understanding autopilot modes. Cheers, Jan

I have just checked the approach again more carefully - you can try with 1.1 but I think this will probably NOT work, because it is a "RF" approach - which requires the FMS to be able to fly a "fixed radius" - you can see this between MUPPY and FS951. The FMS software version we simulate (and all the real 737-300´s, to my knowledge) are not able to fly approaches with a "fixed radius". Only very modern FMS systems can. Domo arigato and Sayonara, Jan

I personally think that this approach can only be flown accurately after the liberal application of Sake! I don´t have the RNP29 approach in my database (it must be very new), so I can´t verify this, but I believe we have the "kink in the route" bug mostly fixed. So my answer would be: I hope so! Cheers, Jan

One step at a time...but yeah, I think you are right ;-) Jan

Yes, it is helpful, I agree. In the future (after patch 1.1) it should work, too. Thanks, Jan

Ok, took a few shots for you guys - so you know that we are not making this stuff up : Distance to go and ETA for next active waypoint displayed on top line of EHSI: Improved symbology when IRS units not aligned: INOP labeling on the TERRAIN button of First Officer (yes, we are working on having it display on his side, too). Also new EGPWS control panel: INOP label on logo light switch if winglets are fitted: lbs labeling on the fuel gauges if imperial units are chosen: Opening cockpit door (note that the cabin is still WIP and will improve in the future (better 3D/textures/lighting): TERRAIN ON DISPLAY button, and TCAS symbology (showing a proximity traffic): Cheers, Jan

Thanks guys for the added information, and especially for the lead on how to avoid the crash! Investigation is ongoing... Cheers, Jan

You are right, I said that - didn´t get around to it yet (I actually forgot!!) . Not at home right now, will try to get that done this week. Keep reminding me if it doesn´t happen! Jan

Thanks for reporting back on this, Rob - glad you got it fixed. I think someone posted that there is a third-party dataref viewer that still allows the IXEG datarefs to be seen... not sure where I read that. Cheers, Jan

Hi there, I can assure you that we haven´t changed anything on the 737´s code in the last few days, weeks or months...unfortunately, if I may add so. So whatever happened, it must have been some event on your side. I haven´t heard of similiar symptoms like you describe, so it is certainly hard to give advice or diagnose. A good shot into the dark is always to make sure X-Plane´s own little faults are turned OFF. It is all too easy to have X-Plane fail something - we had a user complain that the flight-controls (some) did not work for him. Guess what happened? Another possibility might be some sort of driver update - or a plugin conflict. In flight-school we learned that if the engine suddently quits, remember the last thing you did and undo it (like selecting the other fuel tank or leaning the mixture or such...). Hope you will get it sorted, Jan

Happy you got it sorted - the logic behind the lights on the buttons is always: If it is LIT, it can be pushed again to disengage. It does not mean that the mode is actually ACTIVE (you have to look at the FMA on the primary flight display to see that). ACTIVE modes are green, ARMED modes are white. Happy flying, Jan

Hi Denco, I am not really sure what is going on with that. It is normal for the APP button to distinguish (this means that this mode can´t be disengaged by pushing the button) - it is "locked in". Some common mistakes are: 1.) Having the FD master be on the wrong side (ILS tuned on left, but FD master on right, for example) 2.) Using the disengage bar to disengage the autopilot (this also removes power from the flight-directors) 3.) Forgetting to turn the CRS selector to the inbound course - not the FD (or AP) will turn away from the localizer once it captures If you could post a video of what you are doing, we could see a bit better what is happening. Cheers, Jan

Yeah, frumpy is right - we have seen this before once... but I also can´t remember the solution . Re-installing is NOT the solution, it barely ever is. Cheers, Jan

There is a problem with "unusual" flight plans in the FMS like that - and specifically one when you pass the last waypoint entered. This should get fixed with the next update (1.1) Note that it is absolutely optional to enter a flight-plan into the FMS, and especially for practicing touch and go´s I would even call it unusual. It´s like turning on your car navigation system to drive from you carport onto the yard . Cheers, Jan

Let us know how the story goes on! Thanks for reporting back, Jan

Hmm, the only thing I could think of is a.) not to use Webroot b.) don´t MOD your route while you fly c.) live with the processing slowdown between MODing and EXECuting Sorry I can´t give you a better solution at this time, Jan

I am very sorry that you are so angry to not find this in our list for patch 1.1. We realize that it is the single most important feature in a virtual aircraft for some users, and I fully respect your descision not to fly our plane anymore until this is added, but I will miss you in the virtual skies, though! Cheers, Jan

Your thoughts are noted - and I can assure you that we did not omit that out of ignorance or being lazy. I do would like to know how you fly one of the static library objects, though - I would love to try that myself and have dreamt of flying one of the big hangars across the Pacific single-handedly for a long time! Cheers, Jan

You have several plugins running that could be in conflict with each other or gizmo. To help us narrow the problem down, I would like to ask you to disable all other plugins temporarily for testing (you can do this in the plugin pull-.down menu with ENABLE/DISABLE) and then add them back one by one until the crash happens again. So: start "on the runway". Disable all plugins except for gizmo, then test if the crash still happens. If it doesn´t, add the first plugin back. My money is on your EZ pushback plugin or maybe AutoGates... Thanks for helping, Jan

...and there is always the possibility that you run out of "sound slots" if you have a less capable sound card...

This is not a problem with the IXEG 737 but with X-Plane in general. We don´t provide ATC service - you have to access X-Plane´s ATC service for that. A good place to aks for help would be the general section of X-Pilot.com. http://forums.x-pilot.com/forums/forum/11-general-discussion/ Jan