tkyler

I'm not sure where this was mentioned...I'm pretty cognizant of what we've said and when we've stuck our foot in our mouth (which we have) and we did say we want to do tutorial videos....but I'm not sure we ever said we would do these prior to the release...or even the manner of the release....not to my knowledge anyhow. It is NOT correct to assume that the release of any videos is any gauge as to the timing of the release of of the 737. We are doing veracious QC testing atm and will release in due course as our requirements are satisfied. -tkyler

As Jan says, DCL is for debug only; however, I think other FMS systems may utilize it. (Hrm..small bug uncovered. The wrong waypoint is Magenta :P) See...still a tiny bit of work to do NOTE: Before we get in too deep....theses points are not absolutes.....except maybe the first T/D. You cross that first T/D circle and the plane enters the decent phase. The other green dots are "estimated" of course and depending on lots of things...like our performance database, winds and such, the plane may respond a bit on "either side" of these markers...but they are, in general, close....or should be. Its one of those things we expect users to help refine if we missed anything. Here's the correlation.

Flying descents nicely now.

Once you are 'out of bounds' of the route parameters, you are right that things go bad very fast. The most difficult situation is when you are past the Top of Descent point and you simply cannot make it to the runway following the procedure without flying too steep and with flight spoilers deployed and even then there is no guarantee depending on how "late" you are past the T/D point. Simply said, in such a case, you can NOT recover and still fly the given procedure, you have to extend your descent distance somehow by flying off route. Jan does this in one of his videos where he "circles back" and rejoins a procedure leg. (ala pattern work) Also, It could be your arrival procedure has some restrictions that cause you to fly level segments and if you can get ATC permission to bust the restrictions, you could make up some ground and descend on those legs. I have actually spent the last few weeks working on these more difficult scenarios...what to do "IF". As Jan mentioned...as a professional pilot, he has never seen some of these situations, but for newbies like us, we get into trouble all the time and so the FMS has to handle really odd inputs sometimes. There is one thing to note...and that is that the flight profile does have bounds....and the FMS is not a "save all". You get too far out of bounds and the FMS will do no good or give you bad results. BUT, I can say firsthand, that is why I myself keep at it....to get it right. It is addicting. I flew my very first completely automated flight yesterday, takeoff to touchdown with speed and altitude restrictions on climb and descent...all the way down to minimums, the ultimate milestone. All I did was raise/lower gear and flaps after engaging LNAV/VNAV. So whats left? There are still other scenarios we have to punch in to see what happens. Short routes, half routes, changed routes, changed destinations etc. Of course we have coded for these, but we are testing them now for stability and patching holes as they arise. Good news is the bugs are getting much fewer and far between. Stability testing with a broader group is up next. -tkyler

noted...and the value thereof. We will look into those features at the appointed time. Hold and offset probably the easier...TCAS tougher, not so much because of vector algebra, but rather getting the data of each aircraft. Besides....if we get TCAS, whose to say the other aircraft won't have a good implementation and the next thing you know you're crashing into each other anyhow. OR perhaps you mean TCAS in a simple "2D top down view" simply to avoid other aircraft laterally? As opposed to full blown "instructions" from the computer. -tkyler

on the very near term todo list!

So on another note, quite a bit of a milestone. All the code for the VNAV 1.0 feature list is in place as of today and we are beginning flight testing and debugging of the full route LNAV / VNAV capability within a few days (our main tester seems to be a real airline pilot away at work....slacker). After our internal debugging checks and fixes, we'll engage a relatively quick beta test with some selected newbies (already selected)...and then we will mop and sweep, spit and polish and release. No date given. -tkyler

No its not...but this one is!

Blender - for 3D modeling Photoshop / GIMP - for making textures Inkscape / Vectorworks (Tom only) / Illustrator for 2D artwork, sketching diagrams and helpful visualizations Plane-Maker of course Gizmo/Lua plugin as our code base BBEdit (Tom on Mac) for coding (unsure about the windows guys....Notepad++?). Once in a blue moon "Brackets" Git for version control (differing clients) (SVN for a lot of years though) Open Office / Word for Documentation Google Spreadsheets for various temporary uses, calculations and bug tracking

...If we were out to simulate a specific FMC software version, then i'd agree....but software is updatable, versions change and we can always take the position of, "well we have the latest version that is 'one better' that the ones real airlines have" "....this one goes to 11"...so we did not target a specific software version. I'd guess that they all have about 99% similar functionality though. I'd go with the latest version (assume that its the most modern in theory) and then you can just hound us if we don't have the feature. but the FMS page above does bear out that there are "what ifs" and "it depends" when it comes to this situation and FMSs have taken different positions on handling it over differing versions......so we took that tact of providing our solution that we feel is "most expected" for the given situation given Jan's input. The fact that our solution mimics U7.0 functionality is a form of confirmation that we're all thinking the same thing. -tkyler

we're not saying it doesn't. I already let the cat out of the bag with my "rookie move" easter egg message caught on video, DOH There'll be more -tkyler

I WIN.....(in my most evil Plankton voice)

Well lets say the overall route was 1500 miles...and the last enroute waypoint was 150 miles from the arrival runway...just before the T/D with enough time to get down. ...and you put a restriction of 11000B on that point (before takeoff, while on the ground, so you're clearly under it at the time of calculation). It doesn't make much sense to fly 11000B for @ 1300 miles, quite inefficient, especially if you had a cruise alt at 35k or so. It IS logical in such a case to think that kind of restriction should be applied to the descent, it would certainly be the cheapest and we know the airlines like that ....if said enroute waypoint was closer to the climb regime, then it might make sense to apply it to the climb. From an optimization point of view, you'd apply it to the regime that is the cheapest...i.e. keeps you at altitude the longest. If there ever was a "most right" answer, it'd probably be 'B' in the given example. -tkyler

As said, there really isn't a right answer because the proximity of the waypoint to either the T/D or T/C will make it "feel" different depending on it location. It is a rookie move for the most part but we have seen how differing versions of FMS software might refine behavior after some sort of rule or heuristic seems to stand out...and that is what we have chosen to do. This is fringe case...and we have applied a rule that reduces that fringe case to further fringe, thereby isolating it in about 99% of the cases to be "logical". If one were to set out to really test every enroute waypoint by putting altitudes on every one, the results might get a little funky, but would, most likely, end up like CASE C -tkyler

So this is my daily "I've been debugging/coding for 8 hours, I need a break, I'll type some brainless stuff in the forums". I thought I'd share what I'm working on....and why its relevant, and why we can't just 'release' it without this stuff done. So here's the situation....you enter a 'AT' or 'BELOW' altitude restriction at a waypoint not part of a departure or arrival procedure....and that waypoint happens to be in the enroute section of the route (Case 'A')....BUT?.....is it really in the enroute section? 'at' or 'below' restrictions generally propogate back towards their origin and affect T/C and T/D points.....but this is a case of asking, "what is the reference to apply it to"? Case B shows the VNAV if you assume the restriction to be part of the climb. Case C shows the restriction if you assume it to be part of the descent. Case D shows it as not part of either and finally, Case E shows it as totally clipping the whole route such that you never reach your cruise altitude. So how would you interpret this? I think that the more you think about it, the more you would say, "well it depends....IF X, then I'd do this...if Y, then I'd do this...if Z, then this....and I could demonstrate why in each case, there are more potential combinations of waypoints and instances that would create an entirely NEW set of rules....and the code to handle every possibility gets REAL long. So....why is this relevant? Well according to big-daddy Jan Vogel....its common enough to enter altitude restrictions at waypoints while you are flying...especially at the behest of ATC. And since we all want to fly on VATSIM and likely to get such a directive....the FMS really needs to handle it...or at least reject it if its crazy enough. You need to know, there isn't necessarily a right answer here...Jan has confirmed that these situations are very fringe cases....almost "pilot error" for entering it this way as procedures and flight regimes do reside in a well dedined box..and getting out of that box gets funky....BUT as long as folks have fingers to pry open the box, they'll find a way to explore....so we have to have something at the end of the tunnel.....back to debugging and coding. -tkyler

BOO-YA! You've been told Jan!

Actually Flo, I myself don't believe this is the case on the larger scale. As an engineer, I'm kind of a numbers/statistics guy and I am always 'arguing' with the team and others that the forums here aren't necessarily representative of the overall population. We just tend to be the most vocal ones and part of what I call "forum culture"....so perhaps within the context of the forums it would seem a lot get upset, but I'd bet if you rounded up all the users with 'negative commentary as to the time frame', maybe you'll find 20? 30? a few more or less... out of probably 1000s of customers? I believe most folks get it...we all do work of some kind, we all have someone else to give account to, we all feel pressure from somewhere and we all fumble around at one time or another. Life goes on...for me anyhow I relish the journey, good and bad. -tkyler

no worries Daniel, it was your frank perspective, not aggressive to me at all given my framework. I really do totally agree with your commentary....communication can be a precarious thing and I'm quite intrigued by the philosophy of it all. Most of us here just enjoy conversation of any type....I really do like to chat with folks and I, by no means, believe I'll really change anyones mind, just too many people but frankly, I like the diversity. ....and I have opened my big mouth more than once. Overall, this is a good getaway from coding though, after a few hours I'll say to myself, "self...see what's going on in the forums"....then type and run Back to the keyboard -tkyler

I disagree with this statement Daniel, though my framework is probably different. I do generally agree with most of your post but it doesn't really change my framework any. -tkyler

We totally appreciate you being on our side...and to your point, It definitely doesn't make me wonder at all, which is why I posted the clarification. So I'd say the 'quit bitching' request would be 'as of the post' . I honestly don't mind folks grumbling, I mean, finding the wherewithal to complete a project like this takes every motivational trick in the book...and I do not mean trick as in "trick the consumers"....I mean trick as in trick myself to keep working on it day after day, I tell myself I'm close, almost there, nearly done....I keep a perpetual carrot in front of my face to keep my feet moving. The reason it bothers me not if folks grumble.....is because at the end of the day, I know that we will be the only ones who will have done it and if we don't do it, it won't get done....so folks have to take what they get from us, and we have to take what we get from them. It will all be fine soon Regarding bugs, without a doubt we expect bugs....1000s of fingers is better than 10 or so....but we have to do our due diligence in finding as many as we can and towards that end, we do try what newbies will try and we try crazy combinations too...and writing code to protect against really crazy entries can add several days of work in some cases, it is one of the more frustrating aspects of this bug chasing process. -tkyler

Thx wiloghby, your words are encouraging. Indeed, a thorough FMS is a challenging beast. I have to admit, I was quite intimidated by it, but here towards the end, finally have a good feel for it. A friend of mind has a great saying that true success is a combination of 3 things: 1.) Passion 2.) Ability and 3.) Opportunity....and furthermore, you only have access to 2 at a time and have to expend time to get the 3rd to align. We've taken a decent amount of flak by 'trolls' over time, but I can tell you I lose no sleep at night knowing those guys certainly aren't going to get us a solid FMS/airliner for x-plane....so we keep going no matter the flak. We stick with the goal, keep eyes on the prize and get it done right....and a year or 2 after its done right, nobody will care about the release time-frame. I'm totally committed to ensuring we have a 5 year viability minimum. We will keep pushing! Thanks for the support. -tkyler

This needs to be the definite statement by IXEG as to what is "close to release"....so spread the word far and wide when folks ask! When using the word "close", you really must clarify further the relative relationship of the items described to be close. In the case of our 737, there really are two contexts in which to think of "close". We could say that: 1.) We are close to having all the features in that we want in for V1.0 2.) We are close to the release date These are NOT the same. For example, If I put 1,000,000 needles in a haystack with 10,000,000 hay needles, you will find a lot very quickly. As you get "close" to finding the last one, the time to find said last one may drag out significantly.....but you are indeed "close" to finding them all. As soon as you find the last needle, you are done. If its sooner rather than later, then you are simply done earlier. IXEG is close to "having all the features in that we want for V1.0" We are bug chasing...and we are very good at it. We are ensuring we do not have bugs that have plagued other products...we are looking far, wide and very deep for bugs in our FMS to have the greatest possible reliability when releasing. That is what we all want...that is what we have all been waiting for...that is why our team is doing it! There is a generalization that if you are "close" to finishing the feature list, then you are close to releasing...but you cannot relate the two directly. We know that as soon as we are happy with these last few features stability, we will release. could be 3 weeks, could be another 5-7, could be more......what we can tell you is that we are working very aggressively to be satisfied with the completion of our V1.0 features list and we are close to having all those features implemented. I assure you, getting it right is much more paramount than getting it out 4 weeks sooner. We are after a feature list here, not a time-frame. Take solace in knowing that we are close to having the feature list complete and quit bitching about the time frame. Relatively speaking, we're in a good spot now and kudos to those who understand and awaiting patiently, you will be rewarded! -tkyler

The FMS will do as its told (through key entry only), so in this case, it will still slow down if you don't make a change. So...If you get a 'free pass' from ATC below the speed restriction altitude, then on the descent page, you simply delete the speed restriction entry per ATC's permission and a new route with new speeds are calculated. EXEC and be on your way speeding below 10000' like a kid in a Ferrari -tkyler

So here's a small example of what we're doing and where our time is going. As we chip away on the last part of the FMS, that is the descent phase of the VNAV, we try and capture every scenario and represent it, but then when you begin flight testing as we are now, some sneak by you....like this one that took me half a day to find and fix because I noticed speed and altitude values for this cheeky little waypoint (DF644) didn't match up with common sense...so I knew I was on a bug hunt. Now when you cross the speed restriction altitude during descent and have to level off and slow down, this usually happens between waypoints....so most of the time, as you approach and pass a waypoint, you are either descending at a constant rate and speed, OR you level off and decelerate before the waypoint if a speed restriction is in effect at that waypoint. But what happens if you are decelerating at the speed restriction altitude and you just happen to cross a waypoint at that exact time? The speed at that waypoint (which you can see on the CDU) should reflect that deceleration and whose value should be somewhere south of the previous waypoints speed and somewhere north of the next waypoints speed. Well I just happen to come across such a situation....so lucky for you guys and gals ...as that's one less bug you have to find. -tkyler

Fair enough, for me it will, because I don't care to study manual holds. Is manual holding required for 'study level sim' status? I know that the NGX was called study level without having weather radar and without proper manually extending gear and with a faulty brake accumulator model.....But maybe those items are not required to get the study level sim merit badge. I'm still looking for the official governing body who bequeaths study level sim certification status so we have something to go by. Being serious, I get it, what study level means to you....we don't qualify yet given your personal definition, but you can't put your interpretation on everybody else because as illustrated above, there are areas of ambiguity and relevance based on what one wants to study....so when I used the term in the video, given what I know we've put into the FMS and systems, its pretty darn 'study level' to me. We fully understand that we have your support, indeed most everybody's and we are extremely grateful for that and we will keep plodding along and hopefully get those things in for you. -tkyler