Litjan

I have to try it, and I think it used to work correctly: The trailing edge flaps can be extended and retracted with the toggle switch. The leading edge flaps will only "fully extend", but never retract. Extending the leading edge flaps is achieved with the "standby hydraulic system", which will start to operate when the alternate flaps switch is activated. Jan Edit: I just checked, and it works correctly. If you can find it work in a way it should not, please make a short movie and post it for me to look at. Thanks, Jan

I agree that this thread is hard to find (it is only the second pinned topic in the "bug report" forum, with the cryptic title "Solution to freeze and stutter when modifiying the route in the FMC" - but I will give you a hand and find it for you - heck, even copy and paste a link for you! Ping me if you need any further help with that! Edit: Sorry for being sarcastic, and that you are having a problem with our plane. But we can´t really make the solution to the problem you encounter more obvious and prominent, I think. I don´t know what kind of "altitude error" you had, but with the solution mentioned in the thread you should be able to retain control and at least fix that problem... Cheers, Jan

...and you can reboot gizmo via the right-side pop-out window (the little flash symbol)... Jan

Hi and thanks for the nice words! I think we have fixed some stuff wrt to the index of engine indications not being lit at night... so that should get fixed with 1.1. I am pretty sure the needles of the VOR RMI work - make sure that you are in range of the tuned VOR and that you have no "failures" enabled in X-Plane, messing with you. If you still can´t get it to work, please post a screenshot with the RMI and the VHF-Radios in view, together with stating your plane´s position, so I can doublecheck on my end. I think we will not be able to fully flesh out the PROG page for the next patch. Too much goes into doing a full navigational polling of the entire route (distances, planned airspeeds, forecast and actual winds, etc.), and we need to get VNAV working better for this to be accurate. We want to do it right. Cheers and have fun flying, Jan

There are a lot of aerodynamics and physics at play during those crucial last few seconds. The pitch change needs to be fast, and the plane will need a few moments to decrease the sink rate - so yes, we call it a "break" where you do a fast and deliberate input. A lot of factors will affect the trajectory of the plane, and very few landings are really alike. We aim to fly the approach with Vref+5 (and wind correction), bleeding the speed of to Vref at touchdown. Its mostly a matter of repititve training at different conditions. Jan

We will adjust and tune for XP11 when it is final - until then the plane is officially "XP10 only" and you can use it in XP11 at your own risk and choice, of course. Cheers, Jan

If you come in on the ILS, your approach angle (the path the plane takes) is usually 3 degrees. So you must pull up BY 3 degrees to enter level flight - not TO 3 degrees. In other words, notice your attitude as you fly down the ILS (it might be anywhere from 0 to 5 degrees nose-up) and then ADD 3 degrees to it when you flare. Example: During approach you determine your attitude to be 4 degrees nose-up to stay on the glideslope. For flare, pull up to 4+3 = 7 degrees nose-up. Thats all there is to it! (Well, in theory... ) Jan

Thanks, curious to hear if that will fix your problems! Jan

Thanks for your effort, BrianCoyote, I will check it out! Jan

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