Litjan

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

Hi Art, I will check what is going on with that - thanks for the heads-up! Cheers, Jan

Holdings dont work. If they are important to you, I would stay away. Cheers, Jan

This may be a bug with 11.20vr3: https://forums.x-plane.org/index.php?/forums/topic/141415-strange-mouse-glitch/ Cheers, Jan

Here is the problem: Tom created the datarefs, but they need to be hooked up the autopilot logic. Nils is in charge of the autopilot, but he is out of the picture (due to private reasons) until about Summer 2018... Sorry for the tease - lets take the chance to review whats there, and collect what else you may need. I will compile those into a big list and then hit Nils with it when he returns ;-) Sorry, Jan

Most reports of "ILS not working" are due to the user selecting the wrong ILS frequency. Often the navigational database has changed, but the ILS´s in X-Plane don´t change, even if you install Navigraph or Aerosoft data. Another batch of reports are due to "shut down tailwind ILS" option selected. The rest is due to being out of range. The ILS receivers in the IXEG work exactly as the ILS receivers in the default planes - check on the map (M) to see the correct frequency. Cheers, Jan

hi Tim, havent heard of that one before - but we had some reports of users that can´t click buttons on the MCDUs after using the IXEG built-in view settings... could that be related to your issue? Cheers, Jan Edit: Also try upgrading to 11.20vr3, they fixed some problems with the mouse becoming unresponsive if the VR mouspointer is activated.

Good morning, 1.) Yes, we have some code interference - this will be fixed with next update. 2.) I see this as well and we will try to fix it. Two ways to avoid it: A.) Don´t click "resume last flight", instead choose "new flight" (should be same parameters). B.) IF you get the APU not running, flip the switch to START, wait until APU started and then connect both APU generator switches. Cheers, Jan