Litjan

Ah, I just read that you installed the plane on an external storage device - sorry for not reading this more carefully before. This will certainly be the problem - the access to an external storage is probably too slow to handle the data transfer during FMS database access. Or the external storage is even going to "sleep" when not being used, so it needs to wake up and spin up whenever a data request happens... X-Plane and the airplanes for it need to be installed on an internal hard disk, I think. Cheers, Jan

Hola, buenos dias, I am almost positive that you are running into the windows defender/antivirus problem. Make sure that you disable ALL antivirus checking (also the built-in windows defender) for the WHOLE X-Plane folder (not only for the IXEG aircraft folder). There is a lot of database accessing while the route in the FMS is in the MODIFIED (not EXECuted) state, and an antivirus program will try to check all the data going back and forth - this makes the process so slow. You can obviously run virus checks on the X-Plane folder whenever you want, just not when running the FMS. Cheers, Jan

I don´t think Ben took it as an attack at all. He just hinted at the fact that the more data we force to be loaded, the more lag and stutters we will introduce (just like I said in my post above). Even the 747-400s I flew where not able to load a worldwide database, they were loaded with "east" or "west" databases, dependent on the destination... Jan

I agree with most of your findings (except for the time between 10 and touchdown, that depends on how hard you like to land ). We are NOT going to implement a custom radar altimeter model that takes antenna position and body angle into account. We are using X-Plane´s internal radar altitude variable, and are cueing our radar altitude readout and callouts off of that. I applaud your attention to detail, but there is a point where we have to say no . Cheers, Jan

It is not, don´t worry. We are just trying to give an insight into why we as developers are a bit surprised about the fascination with and the desire for a perfectly working VNAV. Coming from a real airliner pilot´s perspective it was suprising for me. From an economical point of view (factoring in development time and return of investment) we felt that it was a less critical item than some other things. But I personally have learned a lot about the different needs of simmers and pilots in the course of the release of this plane (wingflex, passenger window view, cough ). I think the fascination our plane holds on many people comes from the fact that it was closely modeled along the experience that a real 737 pilot would have when flying a real 737-300. For those not interested so much in that we will continue to flesh out the experience with adding a more profound VNAV/FMS modeling and secondary 3D/texture work in the future. I am not saying that the real 737 does not have good (I am not saying perfect, mind you) VNAV, and it certainly has a passenger wing view and wingflex. It was just a matter of priorities, but we aspire to go the whole 9 yards, eventually. Jan

That is certainly true - we are starting to get CDO arrivals (continous descent operation) here in Germany, too. And while a seasoned pilot can certainly fly the profile in selected modes, it is more economical and safe to do so in a vertically managed mode. Again, we are going to "fix" VNAV - its just going to take some time... Jan

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