IXEG 733 Development Status

[tkyler]

Hello All.   This post will be locked as its only intended for public statement.  While many people are aware of the IXEG Development status, many others will not and so this post is intended to provide clarifying information.

For a while now, IXEG development has sat relatively idle.  The reasons for this are multiple and have been stated in other forums; however, two significant factors contributing to that idleness have since wained and IXEG are looking at how to best move forward with IXEG updates again.    There are two areas we are looking at for updates, 3D cabin/doors/animations and the FMS.

Regarding the FMS, IXEG are looking at transitioning to the XP1100 Navdata format, which is derived from the ARINC 424 standard.   Moving to this dataset format would yield increased accuracy in the representation of procedures and more practical data with which to improve LNAV / VNAV / performance caclulations.   If it turns out that porting our code to the new XP1100 format is too cumbersome in the short term, then we will seek to patch what we have now and transition at a later time.  The important thing is that IXEG are moving again to improve the FMS.

Regarding the 3D,  this will be a bit more of a undertaking.  The development tools IXEG used for 3D development are nearly fully deprecated and there has been a major transition to newer tools and methods.  This necessitates IXEG reconfigure our source material to the new formats and we have a LOT of 3D material to translate.   This means that the 3D updates will be longer in coming than the FMS updates.   Once the 3D is ported to the new tools though, any updates we implement thereafter would come much quicker, simliar to what was done shortly after our release for those that recall.   

We apologize for the idle time and appreciate all our customers and any patience you've exercised.   We are sincerely committed to making the most immersive and accurate simulation of this aircraft as we can and will continue to push towards that goal, no matter where its end may be. 

-Tom Kyler

[tkyler]

Hello again.  I'd like to give another update.    During our investigation into updating our NavData to the XP1100 format, it became apparent that this must be the way to go for long-term future compatibility and more reliable route calculations, including holds, but would require a significant rewrite of the FMS base architecture to do so.    So over the last 4 weeks, we have done exactly that.  We now have the beginnings of a 2nd FMS running in parallel with... but independently of.... our original FMS.  We are running 'newFMS' on CDU1 and 'oldFMS' on CDU2.  We will NOT be simulating dual FMCs though.   This old/new arrangement only exists so we can compare the new with the old while developing the new.  It is much like building a new bridge alongside an old bridge...and when the new one is ready, we will remove the old.   

Much of the challenges we have faced with regards to drawing routes / vnav have been related to the limited nature of the navData format we have used since we began the project.  Moving to a format which have been designed expressly for "navigation processing" will go a long way towards easing our algorithm development.   The image below shows the two CDUs, both on the "IDENT" page, but clearly displaying differing data as they use differing algorithms/databases....and for those curious, the pilot CDU displays 'odd' formatting simply because we were testing our new display drawing code.

We are very excited moving to this new XP1100  format.  We have, in 4 weeks, accomplished what took us over 24 months to accomplish originally.  Of course we have the benefit of experience, but the elegance and efficiency of the new navData format and architecture allow us to focus on the FMS functionality  by orders of magnitude more than before.  With the new infrastructure complete, we will begin working on the route editing.  The current navData set only supports about 8 different waypoint types.  Arcs are not supported, as is common in today's RNAV procedures, but the new format contains all path/terminator types typical in today's procedures.

As usual, we thank you for any patience you have managed to muster as we work to improve the IXEG 733.

P.S.   Jan and myself will be at Flight Sim Expo in Orlando, FL/USA  in a few weeks if anyone wants to talk shop.

-Tom Kyler

 

Edited April 21, 2019 by tkyler

[tkyler]

So its been a while, time for another update.     There was a pause after the rush of FMS work mentioned above.  During this pause, I have finished up my NASA obligations...and demobilized from Houston back to San Antonio, where I live,  and some much needed stability to my schedule.  Last week, I dug back into the FMS code and started coding up the route editing features using the new XP1100 dataset.  This is the backbone of the FMS future with regards to performance.....for VNAV calculations, performance progress and also holds.  Its one of those things that I wanted to be real sure I was ready to dig into before doing so.   This route editing coding will go on for a bit......'route editing' involves building the route data that the FMS will use during lnav and vnav tracking and so is critical to be flexible and correct.  It is my belief that if carefully done now, the FMS will be functional and stable for many years to come, which is the most important thing.

 

-TomK 

Edited October 5, 2019 by tkyler

[tkyler]

another update, for those who may not have seen discussions in other threads.  As much as I've spoken about FMS work...that was mostly because all the other aspects of our project, the 3D, the sounds, etc....were bound up in deprecated technology and tools, making it VERY difficult to update things....whereas the FMS was just code work.  This was not really a lack of foresight on our part regarding the 3D tools, but rather being so far ahead of the game way back when we started, we came up with our own solutions.....that were not quite compatible with the way X-Plane moved with regards to developer tools.   WELL.....thanks to Ted Greene of Laminar.....he has coded up a "converter" between the old toolchain we used and the 'toolchain of today'.    Only in the last week did we work out some critical bugs that allowed us to begin converting all our assets into the modern workflow supported by Laminar.  We are currently in the process of converting all our work to this new toolchain and have converted some of the most complex aspects of it already...so we do not anticpate much resistance converting the rest of the work.  This converter by Laminar is a huge lifeline of sorts and will allow us to again respond quickly to bugs and manage updates once we establish a new baseline with these tools.

-TomK

Edited January 17, 2020 by tkyler

[tkyler]

With modern tools, comes modern features.

 

[tkyler]

So the following screenshot tells two stories.  1). We have almost completed the conversion of all 3D assets to to the new Toolchain.  Two assets remain and I'll probably knock that out over the weekend.   The second story....is that with the upgrading of our assets, we finally have a workflow between 3D and Substance Painter® for texturing....in this screenshot the glare shield has a bit of a texture to it, nothing major, but adds to the immersion that's so important to us.   We'll be able to start sharpening up several 3D elements that are a bit low-res by todays standards.   The roadmap after this 3D conversion is to then convert the sounds to FMOD, upgrade the 3D a bit,  including a revised cabin and working doors and make any adjustments required by the X-Plane flight model itself for stability and we'll probably put out an update then.  Then I'll move back to the FMS to finish up my integration of the XP1100 data format and get the holds integrated, the VNAV cleaned up and several other FMS polish work.

-tkyler

 

[tkyler]

Conversion of all 3D to the new toolchain is complete and we have exported out all of the 737 objects from the new version of Blender.    Jan and I will begin testing the functionality to see what I may have missed in the conversion as I had to hand-edit an enormous volume of elements to prep it for the conversion software.  Next up is converting the sounds.  The attached screenshot shows a "quickie adjustment" I made to test drive the 3D update process......about 15 minutes of fooling around in Blender to see how quick I could make an update to the 3D with the new toolchain.  (I know, the circle isn't perfectly round....but it was only 15 minutes)

-tkyler

Edited January 31, 2020 by tkyler

[tkyler]

So this is a heads up that it might go quiet for a few weeks.  Not because we're not working on it, we definitely are, but the conversion of sounds to FMOD is going to be a very intense task.  We wrote our own sound engine before X-Plane adopted FMOD....and our system is quite versatile and very quick to add sounds in code, but its also based on OpenAL, which is going away in XPlane 12 IIRC.  Now we could probably distribute an openAL DLL as a solution; however, that is probably asking for more trouble trying to play alongside X-Plane's FMOD sandbox....so we might as well tough-it-up and make the change.   We have over 1400 lines of code that control various sounds in the sim...and we have to go through each of these situations, audit the behaviors and then port that behavior to FMOD...probably having to write new code just to drive the FMOD inputs.   In the same way we ported the 3D, we will chip away each day on this task until its done and report back as we progress.

-tkyler

[tkyler]

Hello all.   I have not been able to get onto the FMOD sound conversions as of yet for personal reasons; however, things have transpired during the reorganization process such that we are now maintaining two development branches. A longer term branch which will use the new XP11 navdata I've written about above, with revised FMS and we'll also maintain a "now" branch which we'll use to make compatibility patches and small fixes as able until the major revision comes out.  The 'now' branch is a combination of our current FMS code base, but with the new 3D development pipeline....and juxtaposing those two elements has been the focus over the last few weeks.  As many have noted, this tact will allow us to not have to wait for "big ticket' items like the FMS/FMOD conversions in order to get the smaller improvements to the current product.  Until we finished our "pipeline renovation" though, this wasn't as easy as it sounded.

We have begun flight testing again and making tweaks to the flight model as X-Plane updates come out.  In particular, we are working with the 'experimental' flight model in version 11.41+ as we feel that will become the norm.  In addition, we have  XP 11.5+ test builds so we can test the Vulkan and Metal graphics also.  The plan now is to get a XPlane compatibility update out asap, with scroll wheel support.  This patch will have small fixes for the exterior lighting/MCP issue and flight dynamics etc.  After that,  we'll resume our development in earnest.

-tkyler

[tkyler]

Hi all.  This COVID thing has affected my employment and sent me in a different direction.....full time back on X-Plane!  (note...I work on more than just the 737 though) We are working on the update every day as of late; however, we are still going to wait for some 11.50 stability before we release.  In the meantime, we're cleaning up things we feel we can without putting the plane in the hangar with the major renovations like the FMS/holds/VNAV.  We are back in the FMS code somewhat though and have  made the coroutes loading more robust.  We will be including that folder in our update so as to not cause confusion, but we also now support about 6 flight plan formats,  X-Plane 10/11 (*.fms),   PMDG and Quality Wings (*.rte),  X-FMC (*.fpl),  FSX (*.pln) and AirbusX (*.flp).    Like the real FMS, if a waypoint can't be located because of database incompatibilities with the flight plan, then the FMS loads what it can until encountering such a point and then provides the message, "PARTIAL ROUTE LOADED".   I was testing this code with random format downloads from Flight plan database...and nearly all of those flight plans contain out of date data, so getting the FMS to load a full route was a challenge.  I had to go in and hand edit the flight plan files to 'up-to-date' data.  Once done though, they can be saved through the FMS as before.  These coroute. loaders do not load SIDs/STARS, only the enroute portions, which is typical.   As time goes on, I'll continue to work on improving the route editing, which will have applicability for the holds and eventual "in air" vnav entries.  

More to follow as we get closer to our release point.

-tkyler

[tkyler]

So we have reached the "minimum" of what we need to put out an update.  I want to make sure all understand the nature of this update.  It is NOT a major fix of FMS stuff.  This update has significance to us as developers, which will lead to significance for customers.  From our perspective, its validation of our current toolchain, i.e. we can output code and flight model / 3D changes quickly with modern tools...being that the entire product has been generated from this new toolchain.  From the customer perspective, it is mostly compatibility changes to the flight model given the changes in X-Plane 11.5....with a few visual enhancements added-in as able and tweaks to the coroute loaders, scrollwheel support, etc.  Those visual enhancements, as of this post are simply some "sharpenings" of the engine 3D/animation and a tweak here or there to some textures.   Between now and the update though (occuring soon after 11.50 goes final)....we will try and squeeze in fixes and enhancements as able.  I am currently working on the front galley and main door animation...I'd really like to get that squeezed in to the next update if possible.  If not, then it will be soon thereafter.  We are also perusing some forum posts to see what else we can address in the estimated time-frame before release.  I have also begun refactoring my VNAV code...in anticipation of addressing that (and holds) asap after the release.  So to recap, the priorities after this update will be FMOD sounds, VNAV and holds.  I am optimistic that being back full time on this, we can address the FMS deficiencies in a timely manner and get out some much needed improvements.  Again, I am supremely grateful for our patient supporters and we will continue to work on making the IXEG the most immersive airliner simulation available..

-tkyler

[tkyler]

We squeezed in native AviTab support.  What a great product! We definintely encourage you to get it and support the software author with a donation.  If you have AviTab installed, you should see a new preference checkbox to enable AviTab.  If you do not have AviTab installed, you won't see this preference option available.   The video below shows the implementation, along with a bit of coroute usage.

-tkyler

 

Edited April 29, 2020 by tkyler

[tkyler]

Windmilling Fans added.  This example shows direct headwind and tailwind for simplicity.  The magnitude is obviously diminished off-axis with practical limits..and the rotation speed is asymptotic, so 100 kt winds doesn't create unrealistic rotation animations.  Tail winds are less effective on fan rotation than headwinds, due to wind turbulence through the vanes that saps energy.  Also, alignment with the wind vector has to be closer for tailwinds than headwinds to yield fan rotation.

-tkyler

 

 

[Litjan]

Doing some testing and shakedown flights to make sure all new features and fixes work as planned.

So far things are going really good.

...at least for the passengers on MY aircraft .

[tkyler]

We had a request to resize the 'mini EHSI', and also be able to toggle it on and off.   That is now in for the next update.

 

 

[tkyler]

we reworked the animations during replay so you actually have decent replays to watch/record your landings.  We have too much custom stuff to replay the "cockpit" of course, but all the control surfaces replay as expected.  The video shows the changes.   The landing was pretty bad, but I had a cheap joystick in one hand and was monitoring a bunch of stuff at the same time.    Oh ya....new winglet shapes too.

 

Edited May 6, 2020 by tkyler

[tkyler]

So with the update relatively imminent, I thought I'd go over some things that are on my mind, because I expect many folks will have some expectations of things in this update that are not there and may naturally wonder just what we do and don't care about.  Way back when, we had to be quite conscious of our poly count and texture size, and while that is still true to some degree,, machines can handle a lot more now than they could in our early planning stages.  As we've gone through this update, some of the things we defintely want to improve, and which you can expect us to continue working towards are (in random, brain dump order):  wingflex,  FMS performance (holds, VNAV, progress, etc),  higher density and more regular 3D mesh and more accurate 'penetrations' modeling, i.e. NACA ducts, ports, etc,  higher resolution textures, new paint kit (sorry, liveries will have to be done again for a V2.0), full cabin lighting and control,  high rez cabin model, FMOD sounds,  failure management.  So just because we haven't put something in yet obviously doesn't mean we don't "see it" and know it needs improvement.  We are very happy with how fast and efficient we have been able to move since porting our work to Blender 2.8 and expect to be able to make timlely 3D improvements and updates as we move forward with development.  Improvements will be more regular and systematic rather than some "huge V2.0" type of thing with sweeping visual changes...nowadays release/patch cycles are much shorter and incremental.   I can envision a V2.0 update essentially being the revised FMS using the XP1100 dataset and a higher resolution 3D model/textures with a new paint kit and not much else, maybe the FMOD sounds.  Those are somewhat 'big ticket' redos and will take some time.  Priority after this release will be the FMS work and the FMOD sound conversion.

-tkyler

[Litjan]

+ Vr config file

+ Custom particle effects

[tkyler]

Since the 1.3 update was released, we've been working to fix all the squawks that have been reported since the release.  I want to extend my thanks to all who report items.  While folks may wonder why we do or do not catch things, I can assure you the list is quite long of things we have to check constantly and I'm actually somewhat proud of the effort.  Supporting VR and also integrating the mousewheel involved a little over 300 manipulators, each of which having anywhere between 3-9 parameters to enter/ check....easily over 2500 "fields" to look at when making these conversions, and that's just checking the manipulator interaction, not even checking their usability in VR, with mouse, with hardware, prefs on/off while also catering to cockpit builder needs, etc.    The good news is once configured properly,  things stabilize, so each successive update gets more reliable than the last, but being this is our first relatively big "conversion update" with features sprinkled in, the only way we'll really catch it all is with the community inputs.

So....we are getting close to releasing our 1.31 patch, which definitely includes the reversed scrollwheel fix.  We have several other fixes in addition and much better VR support also though some straggling VR features remain.  After this patch, we will begin working on the FMS also with other items, whereas up till now, it was about just getting all our new workflow and converted stuff back to normal with XP 11.50 and Vulkan/Metal. 

I've seen a few posts facebook posts about the IXEG overshooting flybys.   We do not have wind factors in our FMS code currently,  Turn points are calculated with no wind so any form of tailwind on turns may cause the plane to go wide.  Bankangle for lnav calcs are taken at 25º of bank, leaving a little margin if you have the bank limit set to 30º. We do track the crosstrack deviation from the route though, so if there's roll margin, the plane should track still with some tail/crosswind; however, late entries in higher winds will probably run wide. 

Given the outstanding VNAV work to be done, we did not implement the wind factorization as of yet.  As we begin our FMS work,  we'll focus on the holds and VNAV somewhat simultaneously.  Improved algorithms there will naturally be reflected in the progress page output.  Once we get some traction with our VNAV / holds, we'll start factoring in the wind corrrection to the route calculations, which will hopefully  snap everything into place.  

-TomK

Edited May 29, 2020 by tkyler

[tkyler]

so the 1.31 update has gone out, with the objective being to stabilize our "get back to where we left off with the new toolchain, but conformant to XPlane 11.5" update.  Assuming we don't have really big show-stoppers, it is now time to start moving foward rather than just get stable.  We have a few things we'll be working on simultaneosly from this point on.  With an eye on X-Plane 12, we'll be working on swapping our sounds to the FMOD sound engine.    This is a compatibility move, moreso than changing the way our sounds are played because we quite like our sounds.  In addition, we'll be working on incorporating particle effects in spots.   On the 3D front, the 3D changes will begin with the galleys, cabin and cabin doors and after that wing flex.  On the FMS side, first up will be the remaining user-created waypoints, (PB/PB, ATD, LL), then probably VNAV work, including PROGRESS page predictions..  A better VNAV algorithm will make programming holds a bit more predictable and so HOLDS will be after our VNAV work.  Once all that is working reasonably well, then we'll look at porting our navdata over to the XP1100 navdata format....which will probably be after the XP12 release and be a pretty heavy FMS rewrite.  Thanks for the support and patience, its time to starting improving things again.

-TomK

[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

[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

 

[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

Edited July 4, 2020 by tkyler

[Litjan]

Just so that no one can say I didn´t test 1.32 long enough...

[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