tkyler

Jan will have to sound off on this one, but I do not believe we provide this, at least not for V1.0. I myself (who programs the target speed and alts) haven't dealt with this function though I know of it. Sending the plane a target speed / alt is trivial, clearly we do that already, but integrating it into modified 3D modeling, display and interaction would take some time. Both of these, being "options" as it were, this falls down the priority list compared to standard, common functionality. We are beginning by ensuring that the most common scenario by the majority of users is implemented, i.e. "normal, predictable, uneventful" routes that can be flown and editing with no issues....then we'll turn our attention to some of the more esoteric functions of the FMS. -tkyler

More like how a goofball like me names the file when I'm writing code to save/load the coroutes. As soon we we're done with this, I'll be the first in line for Jan's training! -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