tkyler

Hi All, We've posted another video demonstrating some of the VNAV features during the climb phase. There are many different ways to control/affect the aircraft's vertical progress, including flaps, restrictions on speed and/or altitude and the MCP altitude knob. Follow along with Jan as he explains some of the features of the climb phase.

We're using a INTEL i7 based FMS. Seriously, the FMS and CDUs are always being upgraded and do have 'software revisions'. There are some features in later model FMSs than earlier ones. We did have latency, but for testing, its a real PITA...we don't have that kind of time to wait. Our flap extension is instantaneous too for testing. I'm not 100% convinced I want the latency in there, no matter how "real" it is for older units. I'd rather 'believe' that our 737 has a much upgraded hardware and software and I don't have to wait for those pesky calculations. -tkyler

Hey...no promises. I quit all my other jobs with X savings in the bank in order to finish this thing...and I'll give you a little hint...I run out of savings in about 90 days I am working almost 10 hours a day on the FMS and addressing bugs left and right. If we take a bit longer and yield an aircraft/FMS/AP that is duly stable..I guarantee that will be worth it! We are flying many test routes every day and the things we are trying to 'break' is mind-boggling. Imaging taking off with an active route.....then altering a speed restriction...changing the cruise alt.....dropping the flaps (which has limits associated with them)...and then cancelling/erasing the whole route modification with nary a change in performance! its a lot of work We really want for you to be able to operate this thing in a realistic manner. -tkyler

Thanks Mike (hope I assumed the name right). You guys keep at it! It does look very smooth! -Tom

Speak for yourself Jan So as to not to sound too fatalistic here, we are certainly closing in on it very rapidly. I cannot tell you for certain today that we won't release it in 2015. But if we determine that an extra week or two or three to do a thorough once-over and final round of beta flight testing in order for us to feel really good that you will be getting the product you are hoping for, then we will certainly do that. Sometimes, the lipstick makes the difference -tkyler

thanks for all those .fpls guys, we'll try a few of them this week...should be no problem. We hope so....it doesn't take long to export them all into a list; however, making that list nice and pretty with descriptions of each might be time-consuming enough that we wait until after release. Do note, we plan to be very busy after release as well. Certainly a list of both datarefs and commands are warranted. -tkyler

Hello Heinz, so we managed to write an importer for this format (.flp)....at least for the sample given. Would you mind tossing another .flp plan out with a DIRECT in the route, so we know how .flp represents those? a small inconvenience with the .flp example files you provided is that the first airway (or via) in the file is an airway...whereas usually the first line in a plan/coroute is a "DIRECT' to some point and then from there airways are specified. I have to do a bit of a code tap dance around this when a simple entry such as: Airway1=DIRECT would fix the issue. Is this something you have control over? or is this just how the plan is generated? Its not critical, we've already coded around it, but I'm more curious if we are apt to see a variation that we haven't accounted for in the format. -tkyler

There are a myriad of things we want to do and have no argument against putting a lot in. There really isn't a request we are not aware of or haven't heard of, and perhaps agree with. Most of these what I will call "convenience items", scrollwheel, shared copilot, hardware integration, replay, saved situations, etc...they MIGHT be doable. It is difficult to answer the question TBH because we are not currently looking at / focused on those things. We have given ourselves an imperative to get the product out with as much "accurate functionality" as we can muster. The INTERFACE to that functionality and conveniences thereof....we'll really have to wait until after its released and we can turn our focus to those items. The ability of the software is getting so vast now that what we CAN do is increasing faster than our resources can keep up. The paradigm of having a super complete product is more difficult than it used to be. We certainly need a minimum amount of course and our idea of a minimum amount is a lot, but its not all. Ok, given all that jibber, "mid-flight" scenarios have their challenges mostly due to x-plane's own simulation engine. At the instant you reset the state, about a gazillion variables are getting intiialized and not always in the correct order, meaning some variables we try to read at startup/reset aren't ready yet...and this can be enough to cause havoc. So while we have the means to control start state of controls on our end, we do not have the ability to control start state on x-plane's end. There are probably ways to code around this, but it won't be looked at for a bit. The request/desire for the feature is duly noted though, even with us. Flying complete flights to test approaches isn't the most efficient use of time at the moment. -tkyler

Thanks for providing those, Looking at it, I think it might take about an hour to implement the import of that format -tkyler

Regarding liveries, the list is not final. We expect to provide the paint kit when the aircraft is released . -tkyler

we hope so. And what we mean by that is, if there is a published hold as part of the route (the magenta route), then the FMS / AP will draw/ track it, BUT we do not have entry sectors into the hold calculated/drawn. So if the entry angle is particularly challenging and you are traveling at a high speed, it might be difficult for the AP to hold the line and get you into the pattern as the angle changes abruptly in the absence of a calculated entry path. That being said, a direct entry should be the most reliable. About a year and a half ago, during flight testing, I flew into a hold when we were developing the route tracking code....flew round and round a few times, then exited and said, "Ok, the foundation seems to be good, we'll tweak it after we get the more important parts in".....and that still holds true for published holds. We are getting to that phase where we will look at the published hold flight performance but its still in line behind a few other milestones. -tkyler

Also... if someone has 100 flight plans already created and saved and all they want to do is copy the files over to our coroutes folder, then this has merit....rather than re-exporting 100s of them again from their software. With our time crunch, we are unsure if or which flight plan formats we'll be able to accomoadate initially. As stated, we won't stop working just because the product is released. We ourselves are every bit as demanding as customers...and we'll keep working to improve out of sheer desire to get better features for ourselves too! -tkyler

that is correct. We are out of time for these few outstanding features for the initial release. We do have 'hold code' and it does compensate for wind effect and you'll see this on the procedural holds. The code is untested for nearly 2 years. 2 years ago, we flew into and entered into holds successfully, but much has changed. We'll have to come back to it.

We just today finished a "save/load route" feature into the FMS CDU so you can save your routes. The format is proprietary and we are working with a few flight planning resources to provide our format (*.ixg), however, we are going to try and implement the import of other formats...notably .fpl and .fms, if we can squeeze it in in time. Ideally, you'd just copy all your flight plan files into a folder we provide and we'd be able to read them as long as the file names were unique (no LAXSAT.ixg vs. LAXSAT.fpl), etc. Right now, its all about time. We will keep moving just as rapidly after release to keep adding in features. If anybody wants to send me their .fpl file from PFPX, we can certainly give it a try. -tkyler

Good question! We will not have the hold page up yet...where you can enter holds wherever you want. Neither will we have procedural hold entry paths drawn (in magenta). That, of course, requires a bit of work depending upon your entry angle. Also, we do not have "abeam points" implemented. We have all the infrastructure in place to implement it...just not enough time. Um....what else......we do not have an 'offset path'. That is more common on oceanic routes and so shouldn't be missed by most. I will say we have designed our code to handle most anything, so we are not in so deep that we can't address whatever a real FMS can do in the future, its just a matter of picking and choosing after 5 years. Our FMS development has gone through some ups and downs (it is our first one) and we are shooting for a high level as we have some catching up to do. That being said, we are really happy with what we have so far. If Jan can conduct a flight with it as normally as he does in the real word...we're in a good spot! We are hoping to get a last video in before release that showcases the FMS features in a real world scenario (you know that Jan ALWAYS has problems on his flights). ...if you're on a Lufthansa flight and the pilot says, "Hallo, I'm your captain Jan Vogel"...get off the plane! So....I've been at it for about 14 hours today and spent the whole day programming in "flight plan loading and saving". We will be implementing our own flight plan format initially, (*.ixg) and it should be available on onlineflightplanner.org at some point. Ideally, we'd like to be able to read in multiple formats, but alas....we have to draw the line for the initial release. At the least, you can save your routes (with some limitations) and can share these text files if you like. We will be providing a "coroutes" folder that holds "company routes" flight plans for the initial release. Ok, back to it, this was just a break to blog about today's work. -tkyler

I don't know. I am putting in 12 hours a day, do not have another job in sight...this is it until this thing is out! If its not December, it will be as fast as possible on the other side of the new year.....I'm not slowing down and I can not tell you at this time that it will NOT be December as we are on a very productive pace. We'll know more in a few weeks. If 5 more days past 2015 are required to add much needed stabililty, then we'll take the 5 days rather than ship a product with a known bug. We're close, moving fast and we'll let folks know in a few weeks where we are. -tkyler

The last couple of days have been bug chasing for route editing features, mostly as it applies to VNAV calculations. The ability to edit the route in almost any circumstance is very important to simulating real operations. For example, the kinds of things we test are like so....give these a try on other products 1.) Enter a SID only, fly it on LNAV.....then enter an approach while in flight, EXEC....change your mind and enter a new destination airport while flying...select a new approach.....EXEC...begin flying that approach, shortcut to some point further down the approach for grins, EXEC.....enter a SID from the airport you are on approach to..... while on that approach (wipes out the previous route), EXEC... (plane should go into 'climb' phase and begin climbing)...and fly that successfully. 2.) Enter too high a cruise altitude for a short flight (KLAX > KTOA)....the FMS give you a "UNABLE CRZ ALT" warning and then calculates the intersection of the climb/descent "peak" and will change from climb to descend mode automatically as you pass this virtual intersection. OR you can begin to lower the cruise altitude on the CDU and as you do, you can watch the T/C and T/D symbols get closer and closer until you can visually see that you can make the cruise altitude. 3.) Fly a route on LNAV past a DISCO......lnav cuts out...AP needs to revert to hdg and pitch modes....then fly past the point on the other side of the DISCO...it (and the disco boxes) should automatically sequence off the CDU and you should be able to re-engage LNAV and continue on. 4.) Bunch of other crazy tests... Jan is the toughest beta tester I have ever seen...the stuff he does to try and break the FMS is ridiculous. If he can't manipulate it almost exactly as he does in real-life...he cracks the whip! Folks want to learn what its like to operate the real thing.....that means it has to be like the real thing. You know how stable and flexible the real thing has to be? That being said, there are several FMS features yet that we will not ship with V1.0 simply due to lack of time. Most all of these features though are 'fringe features' and certainly do not detract from typical operation most users will utilize. Putting those features in post 1.0 will be as much a matter of team pride as anything as most of the features will rarely get used. Still, we can't help but keep at it. As for right this moment, we're just finishing up a 'flight plan loader"...that will eventually be able to load and save routes. If you want to get a head start on your favorite routes, the format is rather self-explanatory. (format subject to VERY slight changes) Gear up! -tkyler

Hi BaBene....I read over my post and noticed I left out a few adjectives...which I normally don't do, but certainly can see how you've taken offense. What I should have clarified was when I said, "linux users that we have communicated with regarding x-plane products......blah blah...demanded". So I would absolutely agree with your statements about the majority of linux users not being so; however, we are not fortunate enough to deal with the non-complaining majority as much as the complaining minority (relative to linux user base) so we only see the complainers. Thanks for the encouraging words, and again, me and my linux box here next to me apologize for sweeping us all up into our prejudices! -tkyler

To reiterate here again, since I was just thinking about this very thing this morning....we will probably issue some kind of press statement as we get closer as to what we do and don't have. We want it all of course, but have to draw the line. The FMC is definitely the last major system to get in place, specifically the VNAV performance / calculations. We are well into them and will be entering a calibration phase shortly. We believe it is one of the more full-features FMS systems available, though it won't be 100%. What has been left out are rarely used features....we do want to put them in just the same asap. Jan has guided the feature set based on his experiences so what we have left out are not deal killers. We are focusing on flexibility and reliability for normal operations for the initial release. We are leaving out the more detailed "eye candy" and bells and whistles for the initial release, mostly with regards to animations and small detail 3D. For example, no cargo hold, a basic cabin, no animating doors, no voice-over flight attendants, no passenger sound-pack, no flight attendant panel, etc. We have put all our efforts into what goes on forward of the cockpit door. The rest of that stuff is easy, but takes back-burner status to the systems and operation from the perspective of the left seat. After the initial release, we will continue to refine the product and get all that cool stuff in not long afterwards. -tkyler

I'll try and shed a little light on the attitudes FWIW....need a 10 minute break from programming FMS anyhow...attitudes here defintiely have historical context and what I'm about to say is the way it is. I initially programmed the MU2 in linux...was a big fan of it. Loved that x-plane ran on it.....the rate of change of linux libraries drove me nuts though....it wasn't economically viable and my products/procedures had to be in order to make the business work. I understood that about linux and accepted it. Fast forward to now...and in the 7 years of so we've been in business, we've had this Linux debate a LOT with a whole lot of folks. All these discussions most here were probably not privvy to and so cannot fully understand where the "jaded" attitude comes from. Now I have a reasonably decent education...lots of math....did some economics, pressed some buttons on a calculator...and never was I able to justify the support of linux for my own add-ons using some well accepted business forecast techniques. The numbers never added up. Now as a for-profit business, that's an easy call. I go to bed at night, sleeping well knowing that I made the right call for my business and family. BUT....and here's where the rub started all those years ago....linux users have historically never asked for support, they generally demand it....or try and argue the merit of support when it clearly makes zero business sense given the fact that the goal of a business is to make money. ...and the few that did ask for support, when politely told 'no', mostly disrespected that polite no....and entered in on some kind of diatribe about our lack of customer concern or care.....when from our perspective it is equally arguable.... "and you don't care about my support of my family"? Just simply trying to convince anyone that linux support is justified economically in this market can be construed as a form of insult to general business sense and that is where the jaded attitude comes from. As a previous linux user, my attitude has always been one of, "I know it makes no sense to support it financially...anybody can see that...but would you consider supporting it just the same?" I can't say we've see that kind of attitude in years past from the linux crowd, we do tend to shoot first.....our apologies if you're swept up in our prejudices . -tkyler

The problem is with the navigraph inconsistent format. The fix needs to come from them. We began with navigraph...used several iterations of the data and its only recently that we are seeing this borked set. We use a format that is common to existing products so there is NO reason you cannot use navigraph. You just need to understand that some procedures may not show up in the CDU during procedure selection. This is not our issue to "code around". We are shipping with Aerosoft's data set because it is currently the most accurate and it is formatted correctly. If you want to swap out to Navigraph, you certainly have that option. We will try and get a dialog with them to get an IXEG published and will voice our concerns, but they have been slow to respond so there is no telling when it may happen. Just know that we do want both sources available to customers. -tkyler

Not at this time, we are not looking into anything "extraneous" at this time, it will have to be enough initially to just get the thing released and working in x-plane itself....then we jump onto bells and whistles. -tkyler

The comments are still true. Failures are "integral" to the code infrastructure, but no management of them has been implemented. You might have caught in one of Jan's videos the failure menu. This was strictly a debug menu to test the accuracy of the systems, but the menu will ship with the aircraft so you can fail major systems with this menu manually. The failures in the menu are easy enough to add some type of randomization to as its just a matter of setting a variable to 1; however, these failures are more "general systems" rather than some super-specific component so for now, its probably just fine to do it yourself. In the long term, I do envision some type of statistical heuristic based system for handling component life and failures....possibly cloud-based and cloud-managed to really add to the element of the unknown. -tkyler

NOTE: This is my candid opinion and version....and I present it as a form of "history for the curious from Tom Kylers perspective". I am quite sure others' perspectives will differ. Any attempts to argue these points in this post will result in a rapidly locked thread. The finer points of some of the high level statements below are best left buried here. Such points can only be dredged up over many hours of spoken words and beer. In the beginning was x-plane.org. It was a true dotorg, non-profit and for the community. In the early days, it subsisted on sales of coffee cups and T-shirts to cover some costs. It grew at a nice pace. Over time, the ownership changed hands a few times. The org became THE place to share x-plane information, scenery, aircraft and such and many of us were regular contributors to add-ons and knowledge. The current owner saw this value and purchased the org several years back and turned it into more of a business. He operates a store there and of course the forums and free downloads draws folks to the domain. There was no competition to sell x-plane add-ons at this time. (pre 2009) In 2008, I created a product for sale, the Mitsubishi MU-2, but before I sold it....I had very particular needs and specifications that I insisted upon as a vendor of 3rd party aircraft. I felt as though the x-plane add-on world, at the time, did not portray the kind of quality the rest of the flight sim world (i.e. FSX users) was used to and in order to draw more FSX folks to what x-plane was capable of, I felt we needed better products and better marketing. There were products being sold on x-plane.org and marketed as "the best of x-plane", but these products were getting insulted by the FSX community. I didn't much like that as I felt it was stifling x-plane growth. I had a dialog with x-plane.org concerning selling my MU-2 there but we could not come to terms to my satisfaction. I approached the now-owner of X-Aviation and requested he build a new store for my product and in 2009, X-Aviation opened its doors with the MU-2 as its sole product and built on a platform of high quality....the definition of which is, of course, subjective. We had been spreading word of the MU2 during its development through x-plane.org and when I didn't sell the MU2 there, it was seen as a bit of a slap to the ownership by some. But you see, for the longest time, the org had no such alliances with any commercial interests....but with the new ownership, the forums were now inextricably linked with the store. I personally viewed this as a potential conflict of interest given the spirit of the org and its .org domain. I made the case to switch it to a .com and I'd be satisfied, but did not like that the site moved forward under the guise of a "open" dotorg, given its link with the store. There were hints that the forums were only open to "supporters of the org business model". The forums became an advertising ground for the org store. So, when it came out that x-plane.org had competition, words began to get exchanged behind the scenes, feelings were hurt, X-Aviation and myself were deemed "arrogant" and narcissistic...and creating another store came across as "our stuff is too good to be sold on your site". Once feelings were hurt, then views began to become skewed and what is true gets lost to one's perspective, tinted by their emotions...we are all subject to this. To make matters worse, a few other developers came to X-Aviation to sell their products here and they were rejected due to a lack of quality...that really pissed off some folks too. Some of those folks now sell at the org store but one went back to the drawing board, upped his quality and came back to X-Aviation....so not everybody took the rejection in the same way. That person went on to be part of the LES team that sells the SAAB 340. So it was that in the course of words exchanged, some publicly, some behind the scenes...x-plane.org banned several of us from the org and we had no 'home' per se.....and so we created X-Pilot as a 'free' community. Again, by doing this , we further insinuated that the org was now a dictatorship and if you didn't support the leadership, you found yourself cast out.....Animosity flourished further. There were cases were innocent users would purchase my MU2 at x-aviation, post a picture of it on the org, unawares of the link between the forums and the store... and that users post would summarily disappear from the org. A few users got vocal about this and were banned from the org also. Those users inevitably came to the only alternative...and x-pilot started life as a band of 'outcasts' from the org...malcontents who complained all the time and bad-mouthed the org. Feelings of key developers and distributors really got hurt during this time in x-plane history. As with any breakaway, it wasn't pretty and we were scrapping for our place in the x-plane world against a juggernaut....so yes, we were a bit edgy at the time. These stories are buried here on x-pilot somewhere I'm sure. In the heat of battle, some folks were banned from x-pilot as well just to keep the peace. Both sides were stalwart that their 'ways' were justified. Only a few folks know all the facts and we all seem to interpret the facts differently. Time passed. Since that early beginning, X-Pilot and X-Aviation have grown steadily and healthily, fueled by persons that say, "we should do things X way"....while the org and its developers are fueled by persons that say, "we should do things Y way"...competition 101...and these ways are different and we don't agree on many things....and a lot of folks still have hurt feelings. A lot of us have also moved on, feeling that those early days are typical of any early business battle/growth and we are no longer at the same place we were then. Apologies by all parties have not been forthcoming over time though so bad blood still persists with some...not terribly unexpected, we can still remain civil though. I myself have sincerely reached out to everyone that I know I offended to apologize. To this day, I still harbor no ill-will, see the past as a struggle we had to go through to be where we are today. So, finally..... regarding the forums, X-Pilot was never intended to be a replacement for the file sharing that goes on at the org...sure we have a file library here, but it seriously lacks compared to the org and really only exists to give people with sufficient conviction an alternative to post their work. X-Pilot was created just so us old-timer outcasts could communicate. I would simply tell you that the owner of the org forums DOES own the org store as well and does not tolerate what I would term, "sending folks away from his site", so post no links to the outside world or competition for sure! I myself have come to respect his position, albeit reluctantly in the early going. The org is a fantastic place to discuss and interact with the community, get information and answers about a great many things. I will not tell you to favor one forum over the other, you should judge the merits of each based on what you expect and further receive from each. Each forum has a different 'tone' and the size/resources of each make for a different atmosphere at each. I WILL say though, that with regards to x-plane add-on development and operation, that x-pilot has a few folks with very deep knowledge who are unable to contribute to questions/conversations should they be put forth on the org only. -tkyler

The problem we've seen with Navigraph is that their format for procedures is inconsistent. We obviously have to write code to parse the file and interpret the procedures and Navigraph will have, in the same file, two separate syntax for the same type of procedure...and while we read one of them fine, there is a new one in there also that would take a bit of effort to parse. What this means is that if you use the navigraph dataset, then some procedure will be missing from the FMS. Ultimately, we can add code to parse this "strange syntax", but its not our first choice. The fact that there is two 'competing' syntax in the file for the same procedure type doesn't make any sense and we'd rather navigraph correct the issue. If they do that, then there is absolutely no problem with using the navigraph format. We will look into the issue post release. -tkyler