Litjan

Thanks for the report and getting back to me on this! If you enter a cruise of 230 but have restrictions that are higher than that, I think the FMS will disregard them (or even eraze them for you). This will be part of the VNAV tuning that we will do over the next weeks and months... Again, really happy that you report this, and yes, make sure that you have DEBUG OUTPUT selected in the PREFERENCES and then click the .... on the CDU. You will get a message "debug exported" or so - and the debug.txt will be in the aircrafts root folder. Thanks, Jan

Thanks for the report and getting back to me on this! If you enter a cruise of 230 but have restrictions that are higher than that, I think the FMS will disregard them (or even eraze them for you). This will be part of the VNAV tuning that we will do over the next weeks and months... Again, really happy that you report this, and yes, make sure that you have DEBUG OUTPUT selected in the PREFERENCES and then click the .... on the CDU. You will get a message "debug exported" or so - and the debug.txt will be in the aircrafts root folder. Thanks, Jan

Hi torgeir, this seems to match our observations - whenever a route is in the MOD state, it gets recalculated continuously (so that it can take the moving airplane position into account). This places some load on the CPU and data access. We will see how we can alleviate that. Jan PS: some people reported windows defender to be a problem...

It is a bug and it is fixed for next update. Jan

Thanks for the nice words, Devrim! The pressurizatin problems SHOULD be fixed for the next update - as the temperature control (I learned to avoid the word WILL in this context...) Jan

Good report, thanks! Most of this stuff is known - we will have to figure out how to deal with the MOD framerate problem - it seems to depend wildly on some other parameters (are you running a virus scanner?) Thanks for the nice words, they go "down like oil", like we say here in Germany Jan

Hmm, I think the problem is that the last two waypoints before turning onto final are VERY close together. So the plane can not "lead" the turn as it usually wold - this would cause it to miss the last waypoint. Or maybe the waypoint is an overfly type? Can you include a debug.txt for us to look at? Description how in the "Bug reporting guide" in the documentation. Jan

Hi guys, I would REALLY like to get a video of that so we can reproduce and fix this! Please also include a debug.txt, if you can? Thanks, Jan

Hi, this is a know request (I wouldn´t call it a bug, it is working as expected) and we realize it messes up cool videos... thats why we fixed it for next update! Jan

Hi Tom, another good report, complete with debug.txt and everything... thanks a lot! I have never really deleted a coroute in the real FMS... not sure, but I don´t think the DELETE button would work. Conceptually it is just "triggering" a load process. Afterwards it is irrelevant... in our FMS simply type in the ORIGIN 4-letter ICAO again, this will clear the route. In the real FMS I would simply "overwrite" the old route - enter new data, clean out the old by shortcutting (copy+paste the first waypoint of the new route+STAR+Approach and then insert it right after the last waypoint of the new SID). You shouldnt have a crash, though, we will investigate that! Thanks, Jan

Hi Xander, There is a thread about braking and brake-pedals - I dont think this is really in our court, maybe more Laminars... The deceleration levels for the autobrake are default X-Plane, we can´t overwrite those... I agree that the values are a bit less than in the real aircraft, I prefer to use 3 or MAX (which ISNT maximum braking, despite the misleading name...). SETI works for me, just tried to make sure. What is the problem you face? Thanks for the nice words! Jan

Hi Stefan, this is most likely a bug - could it be the same thing happening as here: ? I will try to recreate that one... next time you see something funny like that, please export a debug.txt (need to enable debug mode in PREFERENCES and then click the . on the left MCDU four times....) Thanks! Jan

Ok, will look into that! Thanks for the report! Jan

Hi, and thank you for the excellent report - did you output a debug.txt by any chance? This enables us to examine the vertical profile with the click of a button, instead of reflying the whole route ourselves... Will look at this nonetheless, of course! Jan

That's correct. Jan

This is realistic. The fwd pumps "uncover" if attitude or acceleration is high, the fuel surges aft. More prevalent the less fuel you have. This is the reason the master caution only triggers if both pumps run dry... Jan

Hi, Initial Problem most likely due to residual control Input, most likely from flying with the Mouse and not centering. Or a spikey Joystick. The second problem (crash) is probably fixed with next update! Jan

Looks a bit funny - but at least no crash, right? I will recreate and add to list. Thanks for the good report, Jan

What, and pass on my secret tricks??

Hmm, crap. Where you able to narrow it down at all? Plugins? Artwork control tweaks? Video card drivers? Jan

! And my poor brother, too!

Thanks for the log - I will forward it to someone who can read that cryptic stuff ;-) Jan

That IS strange... thanks for reporting it to Ben. Nils thought it might have to do with HDR (since the lightning ups lighting values across the board, some lights may appear dimmer in relation, or such...) Jan

I will try to keep that in mind, thanks! Jan

Hi Josheph, thanks for reproducing it - I just tried, and I see the same thing. However - I also see this effect on the default airplanes (tried with the Baron).... SO: 1.) Don´t set weather like that (its REALLY unusual to have CAT II ops AND thunderstorms) 2.) File a bug with Laminar Research Good luck! Jan