Leaderboard

This will serve as a formal forum announcement that we have released the version 1.1.0 update for the BN-2 Islander. All customers who have purchased the BN-2 Islander up till now have been sent an e-mail by X-Aviation with complete instructions on how to obtain your update. We have made this a very simple process! For those that purchase the BN-2 Islander from today forward, your purchased download will already be updated to version 1.1.0 for you. This update is a massive revamp of the 3D, textures, sounds, and systems on the Islander! We have integrated customer feedback to perfect the Islander, providing the most realistic X-Plane 11 Islander experience. What if I didn't get the update e-mail? If you did not receive your update e-mail don't fret! X-Aviation has updated our system to allow all customers to update with ease, regardless of whether you received an e-mail for the update! Here's what to do: 1. Login to your X-Aviation account here: https://www.x-aviation.com/catalog/account_history.php 2. Find your original BN-2 Islander download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: Improvements / New Features: RealityXP GTN 750/GTN 650 Integration Revamped FMOD Sound Pack New engine/prop noises Revamped switch and internal noise Custom “headset” simulation with adjustable noise cancellation [IS-351] - Panel Shake/Vibrations [IS-309] - Mechanical Hobbs meter/tacho in 3D [IS-346] - Placard with flaps speeds [IS-332] - Add ability to open plugin menu from plugins bar at top instead of only side tab [IS-295] - Avitab integration Bug Fixes: [IS-241] - Carb Temperature Gauge animation jumping [IS-264] - Gyro CW/CCW switch motor should play until switch is released [IS-265] - Gyro Slave/Free switch has no sound for 'slave' [IS-282] - Landing light fix [IS-285] - Radio channel selector lights fix [IS-286] - Bose A20 Headset improvements [IS-312] - [AFM-114] VOR and HSI behavior [IS-320] - VOR 2 Glideslope reversed [IS-326] - Mags / Door Interlock [IS-327] - BN-2 VR bugs [IS-329] - Stall alarm not audible when the headset is worn [IS-333] - KFC225 ARM and VS buttons correct order [IS-342] - Exterior lights issues [IS-345] - Autopilot working with avionics off [IS-347] - HDG / NAV flags reversed on HSI [IS-352] - o-540-e4c5.obj reduction [IS-353] - furnishings_2.obj reduction [IS-321] - Brake Lines missing proper normal data [IS-331] - Create .snd file changes for new manipulators [IS-343] - Change annunciator brightness to run from 0-1 rather than 0-2 [IS-350] - Add utility light power commands [IS-354] - animated prop governor control arm [IS-361] - Smoothed datarefs for the sunshades on the overhead panel [IS-291] - Add cockpit utility light (moveable) [IS-294] - Update manual with cruise data, fuel flows, etc [IS-306] - Add brightness switch and test button to annunciator panel [IS-322] - Set flight model CHT min/max [IS-323] - Change cowl flap lock [IS-337] - Add persist to Ammeter knob [IS-338] - Hide-able interior glass to remove reflections [IS-357] - Update GUI [IS-289] - Make custom audio panel datarefs [IS-299] - Optimize 3d vertex counts [IS-300] - Optimize textures [IS-315] - Cabin light can turn on without battery power [IS-316] - Pax notices can turn on without battery power [IS-319] - Utility lights [IS-334] - Add Door Interlock Sound [IS-349] - Make avitab datarefs persist [IS-358] - Switch wording for glass reflections As always, thanks for being a customer with X-Aviation. We appreciate your feedback and support! Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.

Downloaded the C+ and all is good now! Thanks guys for all your help!

hey cameron, thanks for the quick and successful help. It works again .... Thanks Regards Christian

Let's start here: If one thing is for certain, TorqueSim does not sit back and relax after releases.

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

Hello All, This will serve as a formal forum announcement that we have released the version 4.9.4 update for SkyMaxx Pro. All customers who have purchased SkyMaxx Pro v4 up till now have been sent an e-mail by X-Aviation with complete instructions on how to obtain your update. We have made this a very simple process! For those that purchase SkyMaxx Pro v4 from today forward, your purchased download will already be updated to version 4.9.4 for you. What if I didn't get the update e-mail? If you did not receive your update e-mail don't fret! X-Aviation has updated our system to allow all customers to update with ease, regardless of whether you received an e-mail for the update! Here's what to do: 1. Login to your X-Aviation account here: https://www.x-aviation.com/catalog/account_history.php 2. Find your original SkyMaxx Pro v4 download and re-download the file. It will download as the latest version! This release has experimental support for Vulkan if you are a Windows user. For Mac users, please be aware Metal is not supported. You may still enjoy this v4.9.4 update when running X-Plane in OpenGL mode. You may read why here. The following is a list of additions/fixes included: What's New / Changed: Improved cumulonimbus and towering cumulus cloud models. Check them out! VR improvements in X-Plane 11.50+ Better random selection of thunderstorm clouds Tightly integrated support for ASXP when RWC in use. Set Real Weather Connector option to "FSGRW / ASXP / External Injector". When using Active Sky XP, be sure to configure X-Plane as described in the ASXP documentation. In the ASXP application, under Options / Simulator Depiction options, you should find a “Use SkyMaxx Pro depiction mode” option in recent versions of ASXP. Be sure this is enabled. Weather in X-Plane should be set to “from custom METAR (rwx) file” pointing to the METAR.rwx file, not “match real world conditions,” when using ASXP. You should not use ASXP’s “global static” mode with SkyMaxx Pro. As always, thanks for purchasing from X-Aviation!

Hi. Just installed and flown the latest version of the BN2- very, very pleased with it and (for my low end graphics card at least) the frame rates are really good now- inside and outside the aircraft. Many thanks! The Carb. heat gauges always read at the top of the range, well out of the green. Is this my engine handling or is there a trick I should be aware of... All the best

If anyone is using the PlaneCommand voice control plugin for their Mooney O2, O3 and Acclaim, I have fixed the profiles required to get PlaneCommand to work better. Since fixing these profiles, I find it a very handy plugin! NOTE: You need to change the file type to json from txt before installing into the profiles folder of PlaneCommand. afm_m20r_o2.txt afm_m20r_o3.txt afm_M20TN.txt

Working. Thanks for the fast fix!!

Got it! No worries tks! ... sure if you buy the wrong car you're not really happy but at the end it's funny I really laught at myself, and the more important is that it doesn't change my point of view of TorqueSim I should had mentionned more accurately in previous message but there you go! As you said wisely yes I take happiness in knowing a great development team is behind this product.... and when I read and see what you guys are able to create (Cirrus or else) I'm happy... Alright so can't wait for future updates about the BN-2 and even if it's not the topic here can't wait for the Cirrus... You guys are very creative and it's great that you make our favorite sim better...

It's a general term. That said, if you purchased the wrong add-on, and still feel that way after the fact, it is a sign of your own dissatisfaction. It's not like I haven't seen your comments for the "other" version to be released and how sad you were about it. Last but not least, just take happiness in knowing a great development team is behind the product. I think you'll come to enjoy it...or so I hope!

Everyone has their own expectations and demands. At the end of the day, we can only promise to improve and fix bugs. Being upset about any of it doesn't help anyone. Hopefully you enjoy the newly released v1.1.0 a little bit more!

Yeah man, Nimbus is supposed to be dropping today. I can't wait! I uninstalled TorqueSim BN2, I just couldn't deal with the lack of realism. Maybe Simcoders can fix it.

Thank you, I have it running now. BTW, I am really enjoying the Islander, it has become my favorite aircraft in Xplane. It is really a tale of contrast between the Islander and this little speed demon of an aircraft. Take care, Jim

Next time, click yes. It will start you off at the closest runway.

I think so - because there is an option to get Navigraph data in the XP1100 format, which forces to have different names for the "same" STAR, if it serves multiple runways (and has a different lateral path for each one). Cheers, Jan

When the battery drains to 0, the temperature indication of the APU becomes dead (stops at last value). The APU will shut down as well (like when you switch of the battery). The generator breakers need electricity to work - so with a totally depleted battery, you can not close the APU, GPU or engine generator breakers to connect them. In this case in real life the following things happen: 1.) The Captain that allowed the battery to drain gets chewed out. 2.) The maintenance brings a mobile battery or connects a cable to the DC external connector 3.) A GPU is connected and brought on-bus (now there is electrical DC power) to charge up the battery through the ground service bus. 4.) The APU can only be started once there is enough charge in the battery - it can not be started on GPU power, for example (too much current). In the IXEG case you can do three things: Either reload the aircraft or reboot gizmo - or use the "failures" window to recharge the battery. Cheers, Jan

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

Thanks for the info Tom, one major issue with the current VNAV profile happens when we have restrictions with below and above altitudes for one fix. It seems to be taking the higher restriction and simply convert it into an above one, ending of course in a very steep descent to catch up. I am sure you are already aware of it. While it forces me to precisely check my fpl against the charts and raises my situation awareness, most users I talk to are not aware and they tend to get frustrated after a while. hope it makes sense cheers Oscar