tkyler

While I don't like to give dates because there are a few unknowns (FMOD sound in particular)....I think its fair to say it will come out some time in April almost certainly. I have a target on my calendar that is in April and working feverishly towards that and best I can tell, still on track. That's the best I can say atm.

a solid "maybe" is all I can say. There are some reasons for doing so now that weren't as pressing as in the past and so its occupying a corner of our minds.

we are looking into it. We have reached out to Reality XP but have not heard back yet. I certainly want to, but if/when it happens, it will be after the initial MU2 release stabilizes a bit. I have been planning for it however.

Hey guys..,.yep....my MU2 is almost out and I'm right onto the FMS right after the "stabilization period" of the Moo....so early summer the IXEG comes into long-time rotation for updating. -tkyler

another quick update. Not much has changed since the last report, except I'm a whole lot further along on my MU2 project than I was at last report. X-Plane is still full time work for me and I'm making steady progress towards returning to this guy. Jan is standing by for the aftermath of the MU2 release when we jump back onto this guy full time and work the FMC and other 3D for a good while I'm sure. I suspect we'll be back on the IXEG by the summer months. -tkyler

Been a while since an update. After reaching a natural break point in the VNAV work at the beginnig of the year, the 733 work has since been waiting in the wings. A few things happened since the last report. 1) I've been working with Laminar for some projects that will eventually make its way into XP12. 2) I wrapped up all my other non xplane contract work so that I now only work on my X-Plane projects full time and 3) I reprioritized my MU2 project as my highest priority now that I'm back developing for xplane full time. I am targeting releasing my MU2 later this year. Progress on that is described elsewhere in these forums...so those wondering what I'm doing if I'm working full time XPlane....then the Mu2 is the answer. Getting the MU2 update out of the way (being long overdue as a 13 year old product) will allow me to resume the 733 work in earnest. A lot of good things have come out of my work for Laminar and the MU2 work that will allow us to improve the 733 in lots of ways, not only the FMS, but also targeting -400 / -500 variants, wing flex and simply improving the product all around. The 733 will not be abandonware...no more so than the MU2, which I've maintained for nearly 15+ years. When it gets in turn in rotation after the MU2 release later this year, it will be front and center for me for quite some time after. -tkyler

as far as "what to look forward to", my response is "what are we still inspired to do"...and subsequently...will want to try to get to. The answer to that is a lot actually. Certainly the VNAV/FMC is highest on our plate. After that, the 3D cabin/doors wrap up, etc. After that, wing-flex.....after that, 400/500 variants, etc. Those of us who are a bit older knows how fast life moves and things can get in the way. For years, I've been working towards the goal of Xplane being the only thing I have to do to get by and I can honestly say that as of last month, that has finally happened. (Thank you low interest rates, appreciation, cough *refi). It is my sincere desire to only work on xplane and in addition, limit my work to only about 3-4 aircraft max for the remainder of my life, such that they could be properly maintained. Being an engineer, my work tends to be "by project" and after every project, I'm effectively unemployed. Its the nature of my job that every project has a dedicated timeline, duration and end...and once a project begins, the timelines are such that it demands all my time until my role is completed. My work on the IXEG has always been between projects and in the evenings/weekends. With independence from having to take projects to survive, it opens up new windows for us to commit to the IXEG. I do have to wrap up some contract work with Laminar for XP12 stuffs, so another month or two and I'll be going full time on my xplane projects only. tkyler

Quick update: We are deep into the VNAV rewrite. Not just poking around and tweaking....we're cutting out huge swaths of inefficient code....and I have to say, its going really well so far. I believe this will make the VNAV calculations an order of magnitude easier to perform.....and if there are any issues during testing, at least I don't believe it will be "whack-a-mole" where one bug creates another. We'll keep you posted. We are working on this regularly at this juncture. -tkyler

we may have to move this one "up the chain" to Laminar. I know I haven't touched this particular object and even on my end the "triangles" just appeared at some point. That being said, it is probably something we can fix on our end...this is typical of Laminar tightening up their graphics code that exposes some weakness that wasn't exposed before... It is only on this one object on my end. We'll dig into it for sure. -TomK

Holds / VNAV are in our current sights. What kind of progress we make remains to be seen, but we are actively focusing on it now. -tkyler

I really couldn't say. Are you using "Dataref Tool" as your inspector? I will say I recall some "absentee datarefs" when I tried it, that I couldn't explain (and could plainly see with DRE)...which is why I went back to DRE for dataref work. I use DRE for dataref feedback and DRT for working with commands. DRE supports the pipe symbol for "OR", which makes it useful enough for me to isolate whatever datarefs I need. -TomK

perhaps VS mode wasn't activated? Were you trying it while sitting on the ground? Works on this end.

rgr, I was responding to your question about how to actuate VVI above. For the levers, we have the following datarefs to reflect throttle lever angle when in autothrottle: ixeg/733/engine/eng1_thro_angle / ixeg/733/engine/eng2_thro_angle ...FWIW, we also have for the reversers: ixeg/733/engine/eng1_rev_angle / ixeg/733/engine/eng2_rev_angle Regarding the default 737...as one who used to work for Laminar developing aircraft, they keep their customization to a minimum and develop their models to use the default datarefs. If some significant functionality were to be missing...we'd just go tell Austin and he'd customize stuff and give us new datarefs....but now that I'm "on the outside", we don't quite have that luxury and so have to go custom and abandon default datarefs when they don't suite our purpose. ....and finally, the dataref for the VS annunciator is: ixeg/733/MCP/mcp_vs_dial_ann Hope this helps. -TomK

VVI wheel dataref actuator is: ixeg/733/MCP/mcp_vs_target_act Regarding autothrottle servo, we don't currently have a dataref for that, but we should be able to add one. I'll have to get with Jan to go over the current functionality and see how we can weave it in. -TomK

Actually I've been rethinking the 'complete rewrite'....but I should mention there there are two significant rewrites planned. 1). the VNAV algorithms and 2) the XP1100 Navdata integration. Originally, the idea was the XP1100 navdata is of a format that would make LNAV route building a bit less painful (being only one format instead of 2, i.e. Navigraph and Aerosoft)....and a reliable lateral route is required for a successful vnav calculation.....hence combining both heavy rewrite tasks into one activity; however, we've seen enough success with the recent LNAV route building....that we feel it will serve as a sound basis for moving forward with the VNAV rewrite now. So we are moving forward with the VNAV work, and will get to the XP1100 navadata some time in the future. Both Navigraph and Aerosoft formats are not going anywhere, even into X-Plane 12. Our internal format for handling route calculations is independent of any datasource...so when we do get around to working with the XP1100 data exclusively, we'll still be coercing that data into our own internal format. -tkyler

Also, a clarification between depicting the published restrictions vs. honoring those in our VNAV calculations is warranted. Previously, we did not even show the restrictions correctly on the LEGS page....and that is a separate issue from a VNAV calculation where you have to assess those restrictions with other paramaters and ultimately calculate the altitude for a waypoint. As Jan says, the VNAV rewrite we're doing will address the issue. -tkyler

There is no power button on the copilot side Avitab. Since the avitab screen is shared between both, and 99%+ of users fly from the pilot side, we didn't want a copilot actuation of a power button to shut down the pilots side (in the case of a shared cockpit). Are you encountering the same issue with the power button on the pilot side Avitab? -tkyler

Thx Tim....we've seen one code break already and I'm already looking into that fix. I am quite driven to make this very reliable and accurate and user tests/inputs such as yours are. a great help. I'm committed to hunting these down as soon as they're found! -TomK

In order to build the thing in 3D, I created some drawings of my own that I could probably develop a bit further for you (and corroborate with Rob Archer) and send you a DXF or DWG. It may take a week or two as I'm traveling about for the next 10 days. Alternatively, I can get you a really high rez orthographic rendering of both our panel layouts when you can probably scale the dimensions off of somehow knowing a reference dim. That I could get to you pretty quick. -tkyler

Another weekly update. The rather rigorous testing of route editing over the last week had brough forth a few more issues, not unexpected during such a substantial rewrite though... but without a doubt, there are substantially less issues with route editing. Jan's last round of route testing, he was unable to get a gizmo crash when changing procedures aggressively and could swap any procedure at any time. Our goal here is for folks to not be scared of to push any buttons on the procedures page during descent / approach for fear of a gizmo crash, and be confident they'll get the route they expect. So, for example, you can select a STAR and transition.....and fly that without knowing your arrival... and then select your arrival later and it'll just get "added" to your routing. I know I say this every time, we have not begun the VNAV rewrite though....so we can't say how the VNAV predictions will turn out just yet. We have a very small list of issues to wrap up, which I will be trying to tend to this weekend so we can get this patch out asap. After, I will examine the waypoint restrictions and then finally analyze the VNAV and set upon improving that feature. -tkyler

Ok..another week gone by. 60 more hours of rewrite on the FMS route editing and guess what, we're still easily 95% of the way done Seriously, we are into the more hardcore route editing features now, the really fringe type of data entry patterns...changing your mind "mid transition" selection for example, or selecting a STAR, then approach, going to other pages, then coming back to select another STAR, then TRANS, then swap to a runway with an extension, then shortcut points, etc. Testing earlier in the week had us redesign some other algorithms and we figured we should just power through the work now so it gets done right and we can move on to VNAV without worrying about fragile route editing. With the algorithm structure in place, what remains is simply comprehensive testing/debugging of those algorithms via diverse route entry patterns until the route builds as expected in all cases, for both Navigraph and Aersoft datasets. As soon as that happens, we'll get the patch out. We're working on it daily. -tkyler

how repeatable is the event. Does it happen at exactly the same time? or about the same time? etc. Also, if you can repeat it and then post the X-Plane log file (Log.txt in the X-Plane root folder) that would be a good data point also. -tkyler

Hello all. What started out as a 'quick bug fix" for our annoying gizmo '470' error has, over the last 80 hours in one week..... turned into a very significant rewrite of our route procedures editing code. I was hoping to have it done by this weekend, but we are not quite ready. We are easily 95% of the way though and will continue to push to get this rather significant FMS update out asap. Depending on the routes you enter, some may not notice much difference, but for others, the difference will be quite noticable with the "routes editing as expected". Of course there is no way we can try all the routes that all the user can. In one 14 hour day, I may enter 100 test routes, all at the same airport, so feedback after release will be much welcome. We have refactored our editing code to be much more maintainable and 'debuggable'. That being said, we are pushing the CDU entries pretty hard at lots of locations and will continue to do so right up until release. I MUST re-iterate...this is LNAV editing code, not the VNAV. VNAV calculations are built upon the LNAV route and so this is a major foundational step towards improving the VNAV. I suspect many routes will improve though with this update. After this route editing effort is stabilized, I will go over the waypoint restrictions and then the VNAV. Holds will come after. -tkyler

Many procedures are "mated" to runways. On the Beoing 737 NG, if you select a runway that is not mated to a currently selected SID, you will get a message "RUNWAY N/A FOR SID:" The FMC will then make that runway the selection, delete your SID waypoints and filter the SIDs list for you to select a 'matching' SID. Conversely if you select a procedure that is not mated to the currently selected runway, the message then reads: "DEP N/A FOR RUNWAY" ...and the FMS again selected the SID, dumps any previous procedures and filters the runway list for you to select a mating runway, We now simulate this behavior, as opposed to the "RUNWAY REQUIRED" message. This situation can still exist with XP1100 data, depending on the procedures; however, it will be less common. -tkyler

Jan is right, we have not touched the AP or VNAV code at all since 1.21, so if something is worse, we need to know exactly what it is that "makes it worse". Debugging is quite tough business, not so much the fix, but the amount of diligence it takes to quantify what the issue is and put it into words. Good VNAV starts with good routes to make calculations from, and that is where we currently are as of this instant, fixing the STAR / APP route building code as these procedures are selected...since they are clearly resulting in 'funny routes' where VNAV calculations make no sense. That '470' bug is a pain for all of us and I'm super sorry about that one, but its fixed for the upcoming update and we are also now trying as many route editing combinations as we reasonbly can to test the robustness of entries. We will have an update in relatively short order with several fixes for sure and I for one, will be interested in seeing how the FMS handles "in air edits on descent" for all the situations folks will try that we did not get to. VNAV complaints are heavily biased toward the descent calcs and revisiting my code, its not hard to see why....which is a good thing...as it paints a clearer path for repairing the code. We are now working on FMS code and VNAV with priority, so any patience / feedback as these updates come out will be appreciated and help us improve. Bug reports regarding VNAV after this next update will be quite valuable as we are focused on that work at this time. -tkyler