Litjan

Oh, ok - this is something we need to address. You are clearing a speed restriction that is associated to a waypoint. I am not even sure if you can do it on the CLB page on the real plane - but it should be done on the LEGs page (use DELETE) to remove the restriction associated with that waypoint. I will talk to Tom, maybe we can allow this entry to be made on the CLB page as well, or we at least pop an INVALID DELETE. What you are seeing is certainly a bug, so thanks for reporting that! Jan

No idea what happened... and haven´t heard of that one before, either. The only chance getting a video of something like this would be running something like "shadowplay", it records all the time, and with a keypress you can save the "last 2 minutes" onto your harddrive. I mourn the loss of virtual Norwegian life! Jan

We like you guys so much, we want you to be closer to us! Thats why!

Hi XPlanePort, thanks for the detailed and excellent report. I see the quirk and I am sure Tom will be able to reproduce the problem very quick. We are currently still in the "kill all crash-issues mode" - the fixing of erroneous VNAV path will ensue very soon. Your case is logged and we will look at it fairly soon. For now (just as a temporary workaround) try to stay ahead of your FMC´s VNAV calcs. The plane will rougly do 1000 feet in 3 miles. Anytime you see that your next restriction (like 9000 at CAPKO) can´t be made, assume the FMC is trying to **** with you and revert to FL CHG and make the plane go where YOU want it to go. Airbus came up with "4 golden rules for pilots" - well, actually two of them have been there since the Brothers Wright - and one of them is "Take action if things don´t go as expected!". That´s why there are still pilots in the cockpit these days. The simple task of flying from A to B could be easily done by a computer... like our FMS . Jan

Hi Kerry, this is an excellent bug report - almost perfect. The debug.txt can sometimes not be generated (four times .... on the left CDU) because either the code crashed too bad before, or the user hasn´t selected the "DEBUG mode" option in the PREFERENCES. I believe that Tom has already fixed this bug in the next version coming up - there was a bad quirk in the STAR and TRANSITION selection process, that hit a lot of people... I will forward this to him just to make sure it is the same error, and please do me a favour and check again after the next update, would you? The N/S thing will also be fixed - just be aware that sometimes using the REFERENCE AIRPORT position is not accurate enough - especially on big airports. Use the GPS like you did, that should work fine everytime. Thanks again, Jan

Yes, if you are quick you can open the windows before the pressure builds up... we are going to have a fix for some window-problems in the next update. Jan

Did you check your failures setting in X-plane? Maybe you have random failures on (its on by default!) Jan

Sweet, thanks Stefan!

I think you are fine with 2, actually - the plane is not small and nimble, so I think that should be fine. Jan

Thanks for the follow-up! Good to know it´s not our plane Jan

A good lead - I will try that!

Thanks for that report back and glad you got a smoother ride, now! Jan

Well, this has nothing to do with the FCC master - that only determines which of the two radios is being "slaved" to the autopilot. For example if FCC A is master, the autopilot will only track VOR´s or ILS´s that are tuned on NAV 1. However, the EHSI´s still display their respective radio signals, so you could show an ILS set on NAV 2 on EHSI 2 - the autopilot (or FD) simply wouldn´t track it. And autopilot trumps FD - so if FD 1 is master (FCC A) , but then you engage autopilot B, FCC B becomes master. Jan

For now, just be aware and dial the speed back real quick - the plane takes some time to pitch down, so you should be able to catch it . Jan

Thanks for the feedback and very constructive criticism! We will certainly consider your suggestion - it is always a tradeoff between visual quality and performance - the eternal tug of war... And yes, that screenshot looks really nice! 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

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