Litjan

Thanks for the heads-up! If you want to do me a favour, please file a bug report with Laminar! I will try as well. Cheers, Jan

I agree with Shanwicks assesment. We are looking to complete the FMC because we feel that it is part of the aircraft and if it is on the aircraft, it should be in our simulation and working correctly. It is true that VNAV is not widely used in descent on the Classics - pilots use it as a "second opinion" and we like to watch the altitude deviation scale to give us an idea what the FMC "thinks" of our energy situation. It can provide a valuable "heads-up" in some situations. I used it frequently as a "socially compatible" reminder to my FO´s that he is way below profile. "Oh, the FMC thinks you are 10.000 feet low. Well, we both know it can´t calculate very well..." - Silence - FO dials in V/S -200 . It is very rare that you get to fly an approach fully on LNAV and VNAV in real life - so you need to ad your local knowledge and guestimates to the descent calculation, something you can´t do well in the FMS. Yes, you can add an "expected" shortcut, but if you don´t pay attention and NOT get the shortcut, the plane will turn anyway - leading to a clearance violation. The only airports I used to regularly fly VNAV into are ESGG and LHBP. They reliably use RNAV STAR and transitions. Everywhere else its FL CHG and V/S. Jan

Hi Kristo1, 1.) You are experiencing the speed reversion mode of the autothrottle. The flashing 8 is showing that the autothrottle is stepping in to save your aircraft (either limiting your speed to prevent overspeed or adding thrust to save you from stalling). You should never see this in normal operation. Read up on the "flap-speed schedule" and adhere to it. Technically there is nothing preventing you from using the autothrottle to control your thrust all the way to touchdown, even in manual flight. Just be aware that it will automatically retard your thrust levers when you pass 27ft radar altitude. 2.) If the FMS calculates "wrong" landing speed it is usually due to the user putting in wrong data. Make sure that your GROSS weight is correct. A common error is to put in the Zero Fuel Weight in the Gross weight field - then the FMC´s computed weight will be "too light" by the amount of fuel it senses in the tanks. You can always doublecheck your FMC speed computation by looking at the placard over the window. Add at least 5kts to this "Vref" to get the "Vtgt" (target speed). 3.) This is actually and X-Plane bug. They are aware of it, but it seems to be (like many other lighting-related bugs) not easy to fix. Cheers, Jan

The IXEG 737 is not in Beta - hence there will be no beta updates. When the 737 was rolled out, we did offer "hotfixes" that could be downloaded quickly, kinda like the updater for the FFA320 works now. We are planning on rolling out more improvements and bug fixes in the future, but they will usually be packaged in a regular installer. Cheers, Jan

Hi marianol, no, that is not correct - the whole N1 limit page is working "so-so", a byproduct of our internal swapping of the FMC development. You can also see that AUTO (which is active) is displaying a value of 84.6% - it should show the current value vor CRZ (91.2%). The orange carots are also not driven properly in all modes (as you correctly observed). This section is slated for an overhaul along with other aspects of the FMC. The current workaround is to disregard the carots and the AUTO numerical max N1 value - the autothrust should heed the correct value. If this bothers someone with a very purist vein, it is always possible to pull out the manual N1 limit knobs and set the carots manually (this does not affect autothrottle operation, it is purely an indication reminder). Jan

Yes - please follow the advice posted here: Jan

the glideslope will capture at 2/5th dot deviation - no matter if you are above or below. You CAN actually capture the glideslope coming from above, it´s just pretty hard because the airplane needs to descend fairly steep to capture it. The other prerequisites are "LOC captured" and heading within 110 degrees (or so) of inbound course (so you don´t capture an erroneous glideslope by accident on a backcourse loc approach). Jan

The capture critieria for the LOC and GS are fairly stringent - on purpose to prevent pilots from doing fringe or silly things ;-) The LOC will capture according to closure rate. If you are closing with it very slowly (i.e. the needle moving towards the center very slowly) you will have to be almost ON the LOC before it caputures. Your second shot shows you being one dot left of the LOC, with a closure of 1 deg - almost nothing. The LOC seems to be offset from the LNAV approach path, possibly due to the LOC not being aligned correctly in the X-Plane world (remember that ILS components are NOT updated with Navigraph/Aerosoft updates). The GS can ONLY capture after the LOC has captured - so you can never fly GS with LNAV. Cheers, Jan

This seems to vary from setup to setup. Some people have problems with it, some don´t. Same for the 4K resolution, works for most, not for some. At this point I would venture out to say that we as add-on developers didn´t do anything "wrong" - the problem is more likely to rest with the way Laminar Research implemented multi-monitor support. Cheers, Jan

Don´t worry - this is supposed to be a fun AND a learning experience! Viele Grüße, Jan

That is hard to say without knowing the exact nature of the crash. But if X-Plane itself crashes, it is usually due to some plugin incompatibility. The way to narrow this down is to remove all other plugins for testing, then see if it still crashes. If not, add them back in one by one until the crashes happen again... Jan

...and before you spend the time trying - we did not model "thrust degradation/flameout" at high altitude, there is simply not enough hard data to model this accurately. So you can turn off the fuel pumps even at high altitude with no ill effect. You most likely can in the real aircraft, too. The manual says "may occur"... Cheers, Jan

Try to see if maybe your monitor setup (multi-monitor, resolution) has anything to do with that? Simply bumping the mouse on the left screen edge should pop them out, there is nothing else to it... Cheers, Jan

To me it looks like you are flying way too high for your weight. Look at how close the two yellow bands are to each other, and the "nominal cruise speed" is inside the "high speed buffet" band. Flying over your "optimum altitude" will increase your fuel burn. Also note that the plane during normal cruise will pitch up about 2.5 degrees. Yours shows about 3 degrees, that is well in the ballpark and can be attributed to you not reaching your nominal cruise speed (magenta marker), probably because you are too heavy for your altitude. If you calculate fuel burn over ground speed you will also see that you have a very strong headwind of 150kts, and a resulting GS of only 273kts. Fuel mileage will be really bad due to that. Cheers, Jan

Hmm, that seems a bit excessive! We are not using any custom modeling for the oil temperature (default X-Plane) - I will check and see if it can be tweaked. Cheers, Jan

Yep, we are still tracing/fixing the "gizmo error after changing aircraft" problem that still appears for some users. Cheers, Jan

Hi Arslan, the message will not do much - all airports are crowdsourced and someone has to A.) Request the airport identifier to be added to the airport database (on the Scenery Gateway website) and then B.) Make the airport in WED and then submit it to Laminar Research via the Scenery Gateway. Google "Jan Vogel WED tutorial" to see how that is all done. The x737 may carry its own database of airports, so it may work differently for them. I am surprised/doubtful about the airport having an official RNAV approach, it is a private airstrip and I couldn´t find any official approach data. Cheers, Jan

We are polling the official X-Plane airport database (apt.dat) - not the user´s Custom Scenery folder. Thats why it won´t show up until you either hand-edit the correct apt.dat or (easier) upload the airport to Laminar Research. Cheers, Jan

I just checked, the speedbrake increases rate of descent at 250kts from 1600fpm to 2000fpm. Thats exactly like on the real aircraft. As for it being "too ineffective" - you just found out one of the reasons why proper descent planning is so important in the 737 classic . CAL4 is not known as airport in X-Plane. You can "make" it with WED and upload it to Laminar, if you want it to be in the simulator. Thats why it can´t be picked as destination or origin. It can still be found as REF airport, because that position is coming from another (official) database, and we do not crosscheck if the airport is present in X-Plane when entering that field. Cheers, Jan

Hi, Morten is right - the real speedbrake´s effect is pretty bad, especially at low speeds. On the upside, you don´t have to observe a possible increase in stall speed, like you do on Airbus-type aircraft. The speedbrake at the FLT detent (don´t use it above that while in flight) will give you roughly 30% more sinkrate at 250kts IAS. Less when slower, a bit more when faster. As for the nav database range: We did increase it substantially in patch 1.2 (iirc). No idea why an airport would go into the REF AIRPORT field but not in the ORIGIN, have to check that out and will report back. Cheers, Jan

Hi Krzysztof, you may not be quite up to the current status of our VNAV implementation. Unfortunately VNAV is unable to follow more complex arrival procedures, and it also fails to read some restrictions from the database (especially waypoints with both above and below). For now you will have to fly descents like real pilots mostly do - in FL CHG or V/S modes, calculating the descent parameters in your head. We are working on improvingh VNAV in the future, so that also less experienced pilots can fly complex arrivals. Cheers, Jan

Yeah, and it may be worth checking if you have antivirus software running that could interfere with the FMS computations. There is some of that going on starting at lift-off, and you may have modified the routing/performance calculation unknowingly (like entering a new weight) and not executing it. So the FMS is constantly recalculating the modified routing. If antivirus checking interferes with this, the slowdown happens. I know many people are VERY worried about disabling live antivirus checking, and they frown upon excluding a folder from checking, but it may be worth just trying to test if that is the cause. We are still looking at options to remove this adverse effect of database accessing. Cheers, Jan

Never heard of this so far - lets see if other reports crop up. Do you have a modified route on the FMS (not executed)? Cheers, Jan

Hi Gareth, thanks for the reply - and again sorry for the inconvenience. We have a fix for that in the pipeline! Cheers, Jan

Hi Gareth, thanks for the report - what happens if you load up the IXEG first? I mean not after re-installing, but after shutting down the simulator completely, then starting up again with the IXEG 737 selected as aircraft? In other words, can you only fly after re-installing, or can you also fly if you don´t fly another aircraft in the same session first? Thanks for clarifying, Jan