Litjan

I noticed this as well, and we are looking into this! Cheers, Jan

I haven´t tested this at your airport and those settings, but what you describe could very well be realistic behaviour. When starting the CFM56 engine you have "20 seconds" between putting the start lever to IDLE and seeing EGT rise (not even spoolup!). It could take a long time for the engine to spool up, the starter time limit is 2 minutes (from engagement to cutoff). So as long as you stay below that, you are fine. Also make sure to turn off all air-conditioning before you start the engines, this is a common mistake sim-pilots make. At high density altitude, jet engines accelerate VERY slow. This is the reason for the "flight idle" setting which is considerably higher than the 21% or so you get on the ground. It would simply take "forever" to accelerate the engines from 20% while at FL200... When the jet passes 80 kts during the takeoff roll, the autothrottle servo motor gets "cut off" from it´s electrical supply (shown by THR HOLD at 84kts). Now it can´t drive the thrust levers anymore. If the correct N1 is not achieved by that time, the pilot has to set it manually. This is normal. To avoid that, follow correct procedure: Hold brakes Advance thrust levers until both engines reach 40% N1 Click TOGA (for IXEG: Advance both hardware thrust levers full forward) Release brakes (note: If you are at a very high airport, you may consider holding your brakes until N1 passes 60% or so - this should ensure that calculated N1 will be set by autothrottle before the aircraft is passing 80 kts. You can even hold your brakes until N1 is achieved ("static takeoff") but it is not recommended as it places a lot of stress on landing gear and wheels and also increases the chance of foreign-object ingestion and adverse flow in the engine in high crosswind situations. Cheers, Jan

The real aircraft has this and we plan to implement it - in a future update of the FMS. It will not be part of the next interim update, though. If you want to "emulate" this function, you can enter the fix (in this case BTG) on the FIX page and then enter (draw) the desired inbound course as a radial from that fix. Then fly to and follow that radial (=bearing inbound) in heading mode (or enter the direct-to again when on the desired bearing). Jan

I do - it is a list in progress - and I am not ready to share it yet ;-) Cheers, Jan

That is unfortunately not true...there is still a problem with some of the lit textures, that button being one of them :-/ Jan

Sneak peak - new material for throttles:

Thanks for the feedback, skydriver! I have also not noticed any detrimental effects in 11.50. My framerate increased by about 30% (Nvidia card). Cheers, Jan

Yeah, wow, that sound just blasted my ears and almost blew out my speakers. How could I have missed that??? Seriously - yes, I hear it. Its not going to jump to spot ONE of our to do list, though. It will probably slide in just in front of that little "swip" sounds the red flags on the RMI make when popping in and out... Cheers, Jan

Unfortunately I can´t for various reasons ;-). You can probably find some on the internet, though. Note that we model the 20k version of the CFM 56, only. Cheers, Jan

That is true - I have to search my old videos again for this. My memories fade, it has been almost 8 years since I last flew a 737 :-( We are looking at moving all of our sounds to FMOD - but not for this next update. So I will add this to the wishlist for the future. Cheers, Jan

I don´t remember this "click". What do you think would cause it? Jan

Hmm, that is normally not required - I can simply use any view keys during replay, no need to reboot or so. Maybe some incompatibility with another plugin (fly with lua, etc.) Cheers, Jan

No, it is a bug of your system :-) Cheers, Jan

We´ll see ;-) Jan

Thanks for the reports, guys - unfortunately there is way too little/inaccurate information in them to really even understand what your problem is - let alone trying to guess the cause or the solution. I would suggest troubleshooting on your part (nav data, user error, proper procedures, etc.) and if that doesn´t help, come back and give me a detailed report (including pictures and/or video) describing step by step instructions to show the problem. Don´t forget to include the Log.txt and of course to remove all other plugins and third-party addons before you try to recreate it. Cheers, Jan

Cptburgos, I will never say never when it comes to X-Plane...but there really was nothing changed in the way the radios or nav-database works with 11.50. I also checked on my side with 11.50 and the navradios work fine. Cheers, Jan mmerelles: Working on it ;-)

I think it already works with Vulkan! Cheers, Jan

I am sorry, then I have no idea. They should work with Xenviro, at least I have never heard that they don´t. Cheers, Jan

Make sure you are not in autothrottle mode - the throttles won´t "work" (can´t be moved by your hardware) while that autothrottle is controlling them. You must be in "manual throttle control" (autothrottle disengaged or even off) for the throttle to work. When you transfer control from the autothrottle to manual throttle (by disengaging it) you will see some "ghost throttle" symbology. Move your hardware throttle until it "matches" the ghost throttle - at that point the throttles will "snap" and you have control again. Cheers, Jan

Your screenshots look fine - you should see the effects of the landing lights. Maybe some other plugin or third party program (altering shaders or art effects?) is interfering. Cheers, jan

Hi Pierre, It is very well possible that your change confused our FMS. Especially with the descent calculations it is very unreliable. It works "ok" when you have no restrictions. With restrictions - not so much In the real aircraft it was dependent on pilot´s preference what modes were used. In general, for smaller descents (<3000 feet) V/S was used. Also when ATC gives you a descent rate restriction (descend with more than 2000 feet per minute...) The most economical way to descend is using an idle power descend (= FL CHG). But especially when your target speed is still a Mach number, this can result in very high rates/low pitch, so some pilots didn´t like to use that for passenger comfort. Cheers, Jan

Hello Pierre, often the TOD does not change when you enter or change constraints on the descent path - because it is not affected by a new constraint, or lifting an old one doesn´t affect it. Imagine a "idle descent" path that passes well under a restriction of "be at FL250 or below". Now clearing this restriction won´t affect the calculated path, because it never affected it in the first place! The calculation of the VNAV PTH descent in the real 737 worked fine - but it was complex and had some potential pitfalls. Especially when winds were unknown (as they mostly are) or when ATC changed your lateral flightpath (as they almost always do) the calculation of the optimum path can get you in trouble. This is due to the fact that the FMS will plan the descent in an optimal way - without any conservative reserves. So if there is less headwind or the routing gets shortened you will immediately be "too high" to start your approach. This does not work well with the conservative and safety-oriented attitude that airline pilots have. Also the complexity and missing transparency of VNAV calculation make real pilots shy away from using it - don´t use what you can´t understand and doublecheck. So speaking for my airline, the typical use of VNAV was seen in climb and cruise. In those portions of the flight VNAV works exactly like FL CHG, with the difference being that the target speed is calculated by the FMS. Usage in descent was close to 0. We used the TOD and vertical deviation bar to "sanity check" our own descent calculation, but the VNAV PTH descent mode was barely ever used. Cheers, Jan

Hi Pierre, you will find most things are the same as when you left (I know, I know...) - some deficiencies with the FMS mostly. Not sure when you left, but here are the things that cropped up within the 11.xx run: 1.) When you don´t have rudder pedals, the simulator now tries to "help" in turns by braking for you asymetrically. This can be fixed in planemaker, but when you do there is now a problem with some internal lights not working anymore as a result. 2.) The option "show vortices" does not work anymore. In fact it will also render your cockpit invisible in certain circumstances. Don´t use it. 3.) Don´t use the "experimental flight model". The plane will fly ok, but not by the numbers. 4.) There is a certain combination of external lights that will make your MCP panel go very bright (it has the wrong object property). This only surfaced recently. 5.) Stall warning test buttons do not work on the ground We are working on an interim patch (pre- XP12) that will ensure Vulkan compatibility and also fix all of the above (in the list, not the FMS deficiencies - those will have to wait for the full FMS rewrite planned for the XP12 patch). Cheers, Jan

In addition to that - it can be fruitful to experiment yourself with the lua Garbage collector: Go to the Data Output tab in X-Plane. Enable the second checkmark (Data Graph Window) in the first line (Frame rate). Now open the data graph window (default: CTRL-g). You can see the framerate like a "heartbeat curve" now. Be advised that displaying this ALSO consumes framerate, especially if you increase the "time frame" of data to be seen. Now open the lua garbage collector setting in the right side gizmo menu. You can "play" with the two values, trigger threshhold goes from 1 to 500%, the Cleaner Strenght goes from 100 to "very much" ;-) I basically find the first value the more useful - if you go up high, your "trash can" goes up in size...so it fills longer (smooth, high framerate) but then it also takes longer to dump it out (noticeable stutter every few seconds). I think one can easily find a good compromise when adjusting those two values. Cheers, Jan

Hi Andromeda64, If the stutter is so definitely periodic, it is most likely the Lua Garbage collector. You can adjust the setting to your liking - basically you have the option to move the effect between: A.) Great framerate, but pronounced stutter every few seconds and B.) Slower framerate but very little stutter. In general, the more RAM you have available, the better the situation (you can pile up more "garbage" before it needs to get cleaned). Cheers, Jan