Leaderboard

This is a lengthy post, explaining our VNAV situation, or at the least, how we arrived where we are today, and where we're going from here. This is a tale of how being too ambitious and trying to be all things to all people bit us and our customers. In the beginning was nav data in XML format....whether other formats were avail in the beginning, I don't know, I only know this was my beginning because I inherited the FMS work and this was the dataset that landed on my plate. It was from Navigraph. The first thing I did when I started was to open up a few XML files to get the lay of the land. I noted several differing "types" of data like so: and decided I needed to know every single type in the dataset so I could design algorithms around it. So I wrote a program to go through all the files and log each unique occurence of a data type, i.e. "Star" "Sid". "Sid_Transition", "Approach", etc. After I had that list (because I couldn't find any spec), I set about programming the FMS....for a few years. All was pretty well. THEN....somewhere towards the end, we loaded up the same XML format dataset...but this time by Aerosoft, thinking "hey, lets support both providers, since there are plenty users of each". ...and for a while things were good; however, we started seeing some issues related to the fact that Aerosoft had additional XML types that Navigraph didn't have...and for which I didn't have code to handle. So I started throwing up 'band-aids' to get the Aerosoft dataset integrated....which would lead to some anomalies for Navigraph users...OK...a few more band-aids ought to do it. And this went back and forth until I had all 10 fingers plugging up holes in the dike. But turns out I needed a few more fingers....OR a more robust dike (hint...that's where this is going). Over time, we'd see bug reports for navigraph users that aerosoft users weren't seeing and vice-versa. Without exception though, the most obvious problem spot was in "decent FMS entries", i.e. STARS, Star transitions, etc. Entering these procedures were frought with all sorts of bugs and gizmo crashes. For online users who frequently enter these procedures in the air, as they approach their destinations, this simply was a deal killer. So...fast forward to today when I'm revisiting the FMS code from a much higher level and seeing that these band-aids just didn't cover the wounds well enough. So..case in point. Here is how Aerosoft and Navigraph each represent STARs with runway transitions, specifically KBOS. Aerosoft uses a data type "RwyTransition" to denote a runway transition waypoint, whereas Navigraph does not. This is where things went south originally when we tried to support Aerosoft users late in our development process. Now when a user enteres a STAR, and no arrival runway has been selected, then you'd expect to load those waypoints in the STAR that are not unique to runways, i.e. "common points". If you're using NAVIGRAPH, you will note that each XML "block" is associated with a runway. So if no runway is selected, we have no way of knowing which block of code to load for navigraph users. If you're using Aerosoft, then I can load the STAR waypoints only (and not the transition waypoints)....except all my code was written for the navigraph formats....and trying to make this work "last second" ended up causing more code confusion and debugging difficult. If I had a bigger picture of all these types from day 1, I would have written better structured algorithms. The good news, is I can see it better now and CAN write better structures; however, better than both these XML formats is the XP1100 dataset that we plan to migrate to in the future. But there is still more good news. Looking at the code with clearer eyes and hindsight, I can see a few trouble spots that I can fix that should make this whole VNAV decent business improve significantly. Indeed one or two poor lines of code can bring down the house and does for a few instantces of entering STARS / Transitions. We are going to add a new message to the CDU, which is NOT realistic, but required in our opinion to avoid confusion. If you select a STAR that is associated with a runway, or has runway transitions, we will display a message "RWY SELECTION REQD". While Aerosoft has the necessary common points separated so as to load those without a runway selection, recall my code was not orginally written for it, and so for the moment, I am not going to create a fork to handle it just yet. Knowing we are switching to XP1100 navdata format, I'll have to gauge the effort of accomodating Aerosoft's transition points differently than the Navigraph data vs the effort of just focusing on the XP1100 integration. It could be, that accomodating Aerosoft's transition points is not so difficult...and in this case, a user could select a STAR and STAR transition without having an approach selected; however, Navigraph folks, we simply need to know the arrival runway before we can load up these "runway transition" STAR types. For STARS that are NOT associated with a specific runway, but serve all runways, this arrival runway selection is NOT required before STAR selection. Many times users don't notice that the STAR they are selecting are unique to a runway (and subject to the case described here) and so in the course of their simming would see inconsistent behavior with STAR selection as they flew differing flights around the globe. This "RWY SELECTION REQD" message will let them know. And finally....my code handling STAR transitions for these "runway transition" STARS was completely borked (by a poor band-aid), messing up the waypoint table and rendering any VNAV calcualtions / representation completely useless. This is why some folks see good VNAV behavior and others do not. It is dependent on which route your are flying, which STAR type you select and whether or not you selected a transition. I believe this CDU message will fix a lot in the interim, but ultimately the swap to XP1100 nav data format, with its consistency and basis in ARINC 429, will be our final and most durable solution. Aside from the issue described here, the other glaring issue is the waypoint altitude restrictions. We will be attacking those soon enough and with clearer eyes, I expect to get this cleaned up also. -TomK

Hi Torbinator, I have seen the same (and stranger!) things with VNAV in descent. But I am pleased to report that Tom has implemented some coding changes related to STARs and it´s transitions (as posted above) that also seem to have a very positive effect on VNAV. I have done a few flights with VNAV descents, and I still see some quirky behaviour (mostly not adhering to the first of multiple AT restrictions), but overall the VNAV has become more predictable and more reliable and I am sure we can build on that and improve it further. I am curious what you guys will report when flying the next (1.32) patch. Cheers, Jan

We’ve been hard at work preparing a major update for the Islander since its initial release! Our philosophy at TorqueSim is to make the absolute best product we can, and to that end we’ve taken time and considerable effort to prepare the Islander Version 1.1, which represents a massive improvement over the original in all areas. With this part of the project now on the home stretch, we decided it’s time to share some of the improvements we’ve made with you. First off, we’re very proud to say that we’ve been able to fix or resolve all bugs reported to us so far, and many more that showed up in the course of our own continued work on the project. Thank you so much to everybody who contributed reports, contacted us about issues, and offered solutions! So many of these bugs would’ve just slipped by us if not for our dedicated beta team and all of you, flying the Islander out there in the wild. Probably one of the most anticipated additions to our Islander comes in the form of integration for RXP’s GTN simulations (RXP GNSs were compatible on launch, for anybody wondering). From 1.1 onwards, the Islander can make use of both the GTN750 and the 650, either separately or both at the same time, in both the regular and G5 versions of the aircraft. In addition, we’ve integrated the excellent Avitab plugin, including a way to move it to various locations within the cockpit. It’ll start out hidden on every flight, but a quick click to the center of the glareshield edge should bring it right up when you need it. In our quest to increase the performance of the Islander on all systems, we’ve undertaken some serious texture optimization, which should render the need for a 2K texture pack obsolete. The new textures retain full 4K format where needed, while selectively downsizing performance-intensive normal maps. Heavier reliance on LIT textures also permits night flights and cockpit lighting with little to no performance impact. A total of only 4 HDR lights have been retained in places where they make sense. Following some requests to make the overhead utility lights functional… that’s exactly what we’ve done! The utility lights are now fully operational, with individual HDR lights attached to them. No more searching for those overhead switches in the dark. The other two HDR lights are used in the pilot’s row cabin lights. It made little sense to bake the LIT textures here, as these lights can interact with certain parts of the cockpit, however they should have very little impact on performance. Further optimization could be achieved in the 3d meshes of the Islander. Many parts contained unnecessarily high numbers of polygons contributing nothing to the overall appearance of the aircraft. These have been eliminated, reduced, remodeled, or otherwise repaired. You should see a marked improvement in framerates in certain areas. Thanks to the combination of texture and mesh optimization, we’ve brought the size of the objects folder for the Islander down to just over 500 MB (including all objects and textures), from over 1 GB before. Needless to say, these are techniques we intend to apply to future projects. We could go on and on and on about all the little things we’ve changed and improved for this version, but instead, here’s a quick list of some other improvements: Expanded UI with more options for both the aircraft and the passengers Manuals now contain useful charts for operating the Islander, including gross weight limitations, take off and landing distances, and cruise data Cockpit switches are much more mouse friendly now, and we’ve eliminated the ‘click-and-drag’ style clickspots entirely Addition of a CSL package And last, but not least, a quick reminder that the Islander Screenshot Competition is still going on! We’ve had some excellent submissions so far, and participants have the chance to win their choice of either the TorqueSim Pocket Rocket, AFM M20 Collection, or both of Attitude Simulations “Gate to the Great Lakes” sceneries! There will be three winners. See the competition page for official rules and details. If you haven’t submitted a screenshot yet, now’s your chance, as the contest will end at the end of the month (May 31st)!

OK, so all is as it should be then, great Thanks for the explanation Jan!

And to follow on what Jan said, my bet is still on Xjet. But yes, crucial to REMOVE the plugins, not just untick them in the plugin manager!

Disregard, I had to move eyepoint farther right.

There are many answers to this in the forum already. No, this won't be happening.

Thanks Cameron

Hi, X-Plane Settings - General

Thanks for making the effort to explain current limitations. I do not pretend to understand a single word of it, but I do appreciate your desire to keep us informed. Cheers

It will be next week most likely. We are still working on some final FMOD tweaks to get the sounds just perfect. We will be sending it to the store as soon as we are completely happy with it.

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