tkyler

I agree the question warrants an answer. I don't mind putting it out wherever I can so the word gets out. We don't know exactly when....and here's why. We all have day jobs but my particular day job is project based, rather than 9-5 based. Sometimes, these projects, being deadline based, can consume multiple months with narry any time for anything else...which is exactly what is going on at the moment. Despite my deepest desire to NOT being working on my current project, I am contractually obligated to finish it....and it is now consuming 70+ hours a week of my time and feels like "work prison". .....here's the good news though. When this project is done....and do note that I initiated this contract a good 8 months before the release of the 737..... I won't be taking on another. I will go back to the 737 and you will see the frequent updates you saw after the release as long we can find things to improve. When is this magic date? To be perfectly honest, I thought it would be by now....but sewing up final details is dragging out longer than I thought and I have no path but forward to get it out of the way and get back to the 737 for you guys. This is not an "abondonment" issue. Just the nature of the beast for x-plane devs who have to supplement the work with other forms of life support for the moment. I wish it were not so...but until x-plane has a larger market share, tis what it is. I can only assure you these folks on the team are some of the most dedicated and stable individuals I have ever worked with and have no doubt we'll be delivering again soon. -tkyler

All fixed up. Had a > 2 when it should have been >=2. Hope that doesn't break something else Was able to put "CH" at the beginning of the route successfully though after confirming the bug before the fix. -tkyler

I just fixed a bug from another report that I believe is related to this. Whenever you have an acute turn at a waypoint...and the next waypoint after the acute turn is too close to make (bypass)....then the plane would depart the LNAV path after teh waypoint BEFORE the acute turn. This bug is due to our "look ahead" code that tries to anticiapte turns in order to give better LNAV tracking I just enterd the route and see the waypoint combo I expected to see (OTBED > MONTY > WAL24)....and the route draws well now (it was kink'd before). So I think this is fixed for the next update. -tkyler

I just fixed another bug that was very similar, so similar in fact, I think it might fix this issue too. Had to do with a very acute turn into a tight sequence of waypoints. -tkyler

Got this one fixed. In this particular route, the problem was a very acute turn followed by a close, next waypoint (but next WP is inside the turn radius of the acf) ...and given this specific sequence (acute turn + next waypoint inside turn radius + next waypoint < 15 miles from the previous point ), my code did not execute a bypass, causing a route kink and all sorts of issues, including departing the LNAV early. Here's a workaround for now (screenshot below). Place BALAS after COUNT, (or delete TIGRZ and ROBBI)..... This gives my code in this particular case room to "complete the calculation" and you can fly this route without departing the LNAV. -tkyler

Hi guys, I'm starting to go after this one. I'm guessing that it will be related to our "look ahead algorithm" on the route. We try and look down the route to anticipate turns and such and I have seen occassions where my "look ahead", gets distracted for some reason and says, "oohh...look at that over there". -tkyler

The data points are definitely associated with the procedure within the nav data XML file. This is one we should probably pass on to the data providers. I still need to have a protocol for working with the providers on issues like this. I'm not sure if its best for end users to notify the data providers or us developers. -tkyler

we would definitely try and make use of it. IIRC, I think we may set the transition altitude to 5000 east of -48 longitude. This basically puts transition altitude for America at 18k and Europe-> east at 5000. Though I just now see that EGLL is at 18k due to my having the 'demarcation line' at 50d longitude. (I've changed it to -48 for next update) Of course if other standards are needed and encoded in the format, that would be a plus. It would not be difficult to put some kind of lat/lon bounding box around certain areas and set the transition altitude. We'd just need a listing of all the common transition altitudes in the major area...that would probably keep things "nominal" for 99.9% use cases. -tkyler

This one is fixed for next update. I'm calling this one the "two digit arrival runway bug"...reared its ugly head for more than a few people. Darn space character. -tkyler

As Morten mentioned, we are in a bit of a "rebound" for the families. Its summer, I have 3 kids in college, with associated moving and orientations and such, etc.....I know the rest of the team is taking some time for their family vacations as well. School starts in a week though here in the US and the routine will start to return I expect....those with school age kids may relate ... maybe not as fast as the hot-fixes after the release, but getting back to improvements and such for sure. We still have a list to chase no doubt. -tkyler

Hi Paul, indeed we do monitor the forums. Super thanks to mmerelles for helping out. We are finding there is just a bewildering array of combinations of routing and "rules" to be implemented for various cases. My approach is to monitor the forums here and any time someone comes across a situation I haven't seen, then I try and reproduce it (assuming I have the route info) and then try to figure out what is what. -tkyler

Hey Tom, yea, this is something that we need to fix, but is a pardigm shift with what we current have in place. The real aircraft use a method called, "step integration" in order to calculate route profiles and accurate predictions on this level require access to reams of aircraft data that we don't have access to. We use a 'approximated' route, that only considers straight lines between the waypoints for most calculations, BUT we draw the symbols on the magenta because they look funny when they're not on the route (as sometimes happens). I do want to move all the calculations to be relative to the magenta route, but that requires a modified data structure that I have to integrate into refactored code......BUT when we do, that is when I really expect things to start getting better. -tkyler

Our apologies but this method is NO longer needed. We have removed it. What we have in its place now, is whenever you EXEC a route, a debug file is automatically generated called "IXEG_FMS_Debug.txt". The four button method above, while great internally for debugging, didn't work so well in the wild. Now folks only have to post this log file for us to have all their route info. It can be found in the 737 root folder. Best protocol is, whenever you see something "funny" or "not right" with LNAV / VNAV (after EXEC), then you should submit that new log file. -tkyler

I does now. Something else is going on. Need to debug.

It switches to T/D for me. Unsure what the issue is. Need the IXEG_FMS_Debug.txt file to recreate. -tkyler

Please post the IXEG_FMS_Debug.txt file any time you see a route issue so we can recreate. Thanks! -tkyler

Understood. Note that we tend to do development "in stages" and getting good behavior up to a normal landing is priority as 95% of customers work in that regime. We are starting to get into the "go around, holds" and other less frequent regimes though....so we will be looking at this very soon. -tkyler

Correct, that is a much more challenging calculation than simply the next waypoint or so where the speed / fuel flow is generally constant in that regime. Predicting fuel at destination means evaluating multiple speeds / altitudes well far ahead of the aircraft on a waypoint by waypoint basis. Its much more than just a number in a field less than the previous field and we want to implement it as best we can. PROG is a work in progress and is front and center on our plate! -tkyler

THX. The PROG page is a WIP. Only page ONE is really supported up to the touchdown. I don't do many go-rounds just yet, its enough to just get it all working up to a normal landing. When it seems that it is all working up to the point with page 1..... then we move to "go around" and other more abnormal / complex scenarios which take quite a bit of time and effort to tweak. We'll be cleaning this up though as we are now doing more "in flight" work on the FMS. -tkyler

yes, that is absolutely Fix #1 above! It was a simple typo on my part. Sometimes when you code for 12 hours....you get some "muscle memory" in your fingers and end up typing things you shouldn't -tkyler

I have 3 fixes in this emergency hotfix. 1.) Fix to soft crash on climb page (the most critical) 2.) Fix to VNAV profiles when cruise altitude was above the mach switchover altitude. If you do cruise alts less than @ 27000', you won't see this bug. 3.) Fix to DCT to points on the RTE page disappearing (but still on the legs page). If I can find / fix anymore in the next few mins before XA gets back from lunch and shoots out the hotfix, I will! -tkyler

thanks for reporting. the issue has been identified and we are working on a fix. This functionality got borked when we tried to make a smarter FMS choose between two identical waypoints that are next to each other (happens when appending points to airways and procedures). Our initial approach was to 'choose one', but the proper method is to create a 'hybridized waypoint' with some properties from one (such as restrictions) and other properties from the other (such as whether its direct or part of an airway). -tkyler

This crash is a known issue......I had it fixed but didn't submit it to XA just before the hotfix went out. It happens whenver the climb page is visible on the CDU and you have any restriction in the climb, be it flaps or otherwise...basically all the time. We are desiring to get out an "emergency hotfix" asap. time zone differences make this a bit inconvenient for some I know. I'm really sorry, it was my fault for not submitting the fix from my local computer to the requisite servers. Hopefuly we'll get this patched up fast. -tkyler

THIS one is my fault for not committing / SYNC'ng with XA servers before the hotfix went out. This issue IS already fixed and we'll get a rapid turnaround hotfix out asap. Super sorry folks, it was a long day of debugging and I got sloppy! -tkyler

did you purchase the 737 in the last day or so by any chance? If so, there are known issues that are getting worked on even as we speak to rectify issues that customers of the last day or so will experience. X-Aviation should send out emails for a update soon with some added information. -tkyler