tkyler

that one is fixed for the next hotfix. -tkyler

CDU items have been addressed for next hotfix....the LEGS distances and also the OAT entry ( addition is NOT subtraction Tom)...equation error No work on the electrical yet...that is definitely last page stuff as it took a real pilot who actually gets into the electrics (cause Jan didn't) to catch it. ...but I will want to fix this up one day. -tkyler

No, because the arm light works within a tolerance zone that is probably bigger than the noise deviation you are experiencing, whereas XP does not. I am unsure if the nullzone applies to axes settings. I have confirmed that there are no nullzone sliders for indiividual axes in the hardware setup screen. I'll probably talk to Laminar about this as we don't want to have to code around such low level behavior (even though we do it for the throttle) if we don't have to. -tkyler

I'm betting a "noisy axis"....not unlike Jan's throttle in his movies. The axis system employed by x-plane only reads the axis values if they are changing. If they are "fixed"...then x-plane does not try and read your hardware....if the value is changing, x-plane will try and match your hardware.....so in this case, there was a fight between X-Plane and IXEG....most likely instigated by your hardware though. Moving your hardware lever ever so slightly might be enough to stabilize the dataref, of course you have zero clue if this is going on without watching the datarefs....which is impractical for the end user. Without opening X-Plane and looking right now (cause I'm hungry and lazy)....does each axis have a nullzone adjustment? If so, it probably exists for this reason. -tkyler

I'll give this one a look see tomorrow...dig into the nav data and see whats what. -tkyler

yea, Tom does have a professional itch to get these a bit more refined at the proper time. This post is noted -tkyler

Are your rendering settings set to HDR? -tkyler

This looks to be fixed in the next hotfix, due our shortly. -tkyler

a hotfix is coming out shortly....I tested a bunch of stars at LROP with NG1605 and have had no issues. the problem was very obvious in code and hence why I think its fixed...but we hope nothing new shows up. -tkyler

several fixes to LNAV coming up in a impending hotfix.....hopefully this one is covered. it did for me just now with NG 1605. -tkyler

In the next hofix, we will be implementing the ability to save company routes; HOWEVER, this will not include the saving of procedures...only the departure and arrival airports and at least one enroute waypoint. This is accurate to the real thing and why we chose to go this way. We will save the coroutes in the same formate we read, that is: *.fpl format. whenever the minimal information is entered to save a route, the RTE page 1 will displaye a '<SAVE ROUTE' option. Routes with a disco in them will not be saved though. -tkyler

think I have this one fixed. I was able to reproduce the soft crash, fix it, and finally entered the ILS without the crash. A good fix! -tkyler

Fixed. Lets hope they don't remove or add a few spaces in the text file -tkyler

Indeed...this is a very rough week schedule wise. "Graduation time!" Family, events, etc. I am about to begin some serious FMS calibration work though, beginning next week....looking to squash bugs and work on missing features and improved LNAV and VNAV. After that, I'll definitely be interested in evaluating the shared copoilot situations. -tkyler

Thx for the report xplana. I am about to enter a phase of very dedicated FMS work and hopefully catch all of these items. I am having to take a week off due to family medical issues and in addition, I have a daughter graduating college/university this weekend. ....and I'm dealing with family most of the week. I am VERY anxious to jump onto the FMS in earnest and bring it to its potential...is is much closer than the gizmo soft crashes would indicate....I just need to fly a lot. Thx again for the reports. -tkyler

We did not get them in this hotfix. A developer is working with a prototype set and if they all pan out, we'll including them in the next hotfix. -tkyler

It is a challenging feature to implement and I want the more common bugs handled first. -tkyler

I think I have this one fixed, I'll have to flight test it though. -tkyler

Hi xplana. Log.txt indicates that maybe X-Plane's ATC system was involved...I'm going to forward the report on to Laminar. tkyler

will check Franz. Perplexing and frustrating..for both of us. Thx for reporting. -tkyler

The route drawing "rules" are a bit complicated. With over a million possible route combinations, we are going to improve the LNAV 'rules' for various situations during a tuning phase. The "bend" is not a bug, its as intended for the moment. It is a "re-intercept" of the leg between the two waypoints, which IS valid for legs over a certain length...though that length is not defined anywhere, but more "common sense" -tkyler

<ERASE is active after an initial route EXEC. ...and you need to 'undo' your changes relative to the active route. If no route is active yet (due to no EXEC), there is nothing to "erase" per se....and the method here is to simply overwrite what you have before. -tkyler

Thanks guys. We have come across just about everything and as mentioned, what works in one set of situations, tend to break down in other siuations in other parts of the world where procedures tend to have different 'patterns'. This is why someone who flies regularly in one part of world thinks the FMS is 'great' whilst someone who choses a part of the world where the procedures are a bit more...um...challenging, see the FMS as buggy. Writing rules to make the FMS smart in all these cases....while not completely the 'bane of my existence', certainly presents challenges...especially since my ability to fly "routes all over the world" would take me some number of months indeed. Boy would I love to believe that....but Jan has proved me (and himself) wrong on a few occasions with our assumptions. With over 300,000 nav points in the database, the combination of what you might encounter is tough to predict sometimes...I am amazed at the combinations I see sometimes. I am firmly of the opinion that evaluating these on case by case and expanding and adding to, the "rules" relative to other rules is the best course....though we clearly have to wait until they are encountered to evaluate them properly. -tkyler

awesome. THX for posting that debug file.....this is what we do with it...analyze the VNAV path. The path should descend after WHHTE and I can see instantly the issue and we can begin working on a fix....though we are focused on soft crash prevention at the moment. -tkyler

interesting. Yea, the FMS is kicking into descent mode during the calculation, which is why the deviation pointer pops up and the CLB page goes blanks (as it thinks the climb phase is over). Will look into this for sure. -tkyler