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

No offense taken, I knew someone would bring that up so for the record.....I don't consider that video IXEG 'official jargon', but rather an impromptu interview, hence my usage of the term (didn't work though). I think your post misses the point of my post (but not my quote #1) and this thread; however....your keen memory is noted by all. -tkyler

A great quote by author Cory Doctorow, which is why we type in these infernal forums incessantly, so need to question why people have to sound off on every little thing, its in our nature to just gab. ..and another great quote: The community coined the term "study sim" somewhere along the line, I'm quite sure we've never used it in our official jargon at IXEG. I'm also pretty sure there is no written down definition of just what a study sim is so each person's expectation is up for grabs no?.....furthermore, our simulation is only what we target it to be and Morrigan hit the nail on the head there. Our primary goal was/is an airliner that is an accurate simulation of a normal and typical 737-300 flight, so that we can get busy flying ops on vatsim and using the FMS to conduct normal flights because its just fun....NOT a 'study sim' as I define it in my head. If ol' Bob the customer's goal is to engage in mental masturbation while looking at fold out technical diagrams in the center of the manual....ol' Bob will just have to wait or build his own simulation.....while the rest of us will be 'flying' Now nearly every thing we have put into the sim thus far has a physical manifestation that can be observed by the pilot in some capacity and is the reason why our 'behind the scenes' stuff is as detailed as it is...its not just for the sake of the detail or so some A&P can practice his diagnostics. We have simulated electrical relays because it affects how things appear and get powered in the cockpit, VERY visible when simulating normal flight. We have simulated hydraulic systems in depth because it affects the controls and gauges....VERY visible during normal flight. We have simualted the LNAV and VNAV as best we can because when you don't level off at the right altitude...VERY visible during normal flight. Manually entered holds....NOT very visible during normal flight....is everybody getting this? note our goal above if not.....and read it as many times as you need to until you do....think of this post as a study level post. ...I wasn't going to type anymore but I know that some folks will miss the fact that the word 'primary' insinuates 'secondary', i.e. a follow-on goal. Our secondary goal is to get the simulation as accurate as we can in the infrequent/abnormal areas, just for the satisfaction of completeness and bragging rights....and no other reason....I have ZERO desire to use a manual hold in sim, don't even care to read about it. BUT....those that do want it all can rest assured that the pursuit of our own satisfaction in this regard will ensure that we keep going well after V1.0 hits the shelves. -tkyler

I'd like to add that, even though I'm one of the developers, I am by no means a "airliner guy". I barely know how to operate the thing on many levels, certainly do not have proficiency. I have not nailed one flight yet beginning to end but I am driven by the challenge to do so. One of the things I am looking forward to as a relative "newbie" is learning how to operate the thing. BUT in order to do so, I need guidance and mentorship and a good training program, not just a FCOM. Of course we have just the man for the job in Jan and we will be including several training videos with the 737 purchase to go with tutorials we are providing with the product. Also, we have a longer term vision to craft a more comprehensive 'training program', the details of which still have to be pondered upon and thought through.....but my point is that we understand that the learning process can be as rewarding as the actual operational process and we want to cater to both thereby serving both newbies and experts alike. -tkyler

Nah, you just have to not let it get to you....find other stuff to do than read the drivel. Who knew that trolls really existed till the internet came around?....besides the Norwegian government of course On another note...can you believe this crap? What kind of insanity is this!!! http://money.cnn.com/2016/01/20/media/star-wars-episode-viii-date-moved/index.html

Works for me I have no problem with folks blowing steam. I get it, but neither am I affected by it. I've been around the block a few times and involved in project based businesses for some time. One of my biggest life lessons is "don't stop moving" I also have another saying that I like, 'targets are a way to stay focused'....my own virtual carrot dangled in front of my own face. There is no way you can undertake a project like this and not have to find ways to keep moving after 5 years. Once its out and running smoothly, all this will be forgotten. So.....I'm finally over my cold, back on the FMS and rushing to get this to market asap! Want to know what i'm doing right now? I'm working on setting AP speeds during the descent phase. Easy? Are we already in VNAV? just engaging? Are we in the mach or IAS regime? Are we bound by a current speed limitation? which one (maybe we engaged VNAV midway between two restrictions) Are we above or below the speed restriction altitude? Are the flaps out? Are we in speed or path mode? Is the descent speed manually overriden? etc. etc. -tkyler

That's not the plan anymore. "Soon" is a reference relative to the whole and still applies. Of course it is subjective....but I think we'll beat the vernal equinox. -tkyler

when its ready