Leaderboard

Captains, Mark your calendars! This Friday, September 15th, we're releasing the IXEG 737 Classic Plus! This is a next era re-brand for what the IXEG 737 Classic has become after many months of labor. The primary goal in this endeavor was to bring full X-Plane 12 compatibility to this amazing aircraft, squeeze in a few new features, and set the stage for improvements in the future. To us, it's a rebirth of a classic, tailored for X-Plane 12. Truly, stepping into the cockpit feels so good in the new X-Plane 12 environment! A Special Note on Pricing: For our customers who acquired the IXEG 737 Classic on or after February 7th, 2022, this update is for free for you to honor our promise of a free update at the time you made the purchase. As for our dedicated pilots who've been with us since the beginning and purchased the IXEG 737 Classic on or before February 6th, 2022, the upgrade to the Classic Plus version will be available at a nominal fee of $14.95 USD. We believe this price point offers tremendous value, and you'll have 60 days to take advantage of this upgrade offer once the product is released. The IXEG 737 Classic Plus doesn't just bring new features; it rejuvenates the entire flying experience, making this aircraft feel brand new. Here's a quick rundown of what's been brewing over the past 9 months: Fixes & Enhancements (from the XP11 version): Engine Bleed Configuration: Now accurately impacts Takeoff N1. FMS PERF Page: Resets to blank entries post-landing and deceleration below 60kts. Code Optimization: Streamlined and revamped for quicker future updates. Brand New Features for the XP12 Version: Wingflex: Experience the subtle flex of the 737's sturdy wing in our 3D model. 3D Cabin: Dive into a fully detailed cabin, complete with operational galleys (Fancy a cup of coffee?). Moving Cabin Doors: Open and close each cabin door, influencing differential pressure just like the cockpit windows. Loading Stations Concept: Assign weights to specific seat rows and cargo holds for accurate physical effects on the aircraft. Cockpit & Cabin Lighting: Updated for XP12's lighting engine, including interactive cabin lights. X-Plane GUI Integration: Set up your load and fuel seamlessly. GUI Enhancements: A fresh look for the IXEG interface, now VR-accessible. Hide Yoke: With default XP12 key assignment. FOV Slider: Added to preferences for a tailored viewing experience. Cockpit Windows: Upgraded to XP12 tech, showcasing rain and ice effects. Outside Lighting: Balanced for an immersive XP12 photometric experience. Aerodynamics & Engine Tuning: Optimized for XP12's advanced modeling. To our loyal customers transitioning from the X-Plane 11 version, we've poured countless hours into this upgrade, ensuring it's worth every penny. We're confident you'll find the enhancements enjoyable, and with the help of full X-Plane 12 compatibility, transformative! We can't wait for you to take to the skies with the IXEG 737 Classic Plus this Friday. Clear skies and happy flying! IXEG and X-Aviation

Captains, It's with a lot of excitement and appreciated patience that we are ready to announce what's to come for IXEG's future! The team chose to let the dust settle a bit and not have too wide of a moving target in the early days of X-Plane 12 so as to not waste development time. The following will serve as a brief summary of what's to come, as well as a bit of a roadmap on where things will go. Things have changed a lot since the last X-Plane 11 update, one of them being that @tkyler is now full time in add-on development instead of juggling between real life jobs and that of our virtual world. This has given us the ability to focus on where we want the 737 to go into the future, and we hope you'll like what you initially see! Cost Back on February 7th, 2022, a little after Laminar Research announced X-Plane 12 was coming, we published on the IXEG 737 product page that purchasing customers would receive a free product update to the X-Plane 12 version. Per that statement, we are honoring this free update for customers who purchased the IXEG 737 on or after February 7th, 2022. For customers having purchased the IXEG 737 on or before February 6th, 2022, the upgrade will be a paid upgrade of $14.95 USD. Why this pricing structure? Our goal is to keep the upgrade pricing within reach of all customers at a fair price, and will ensure continued development of the IXEG 737 into the future. This all said, we also want to provide existing customers with additional value for the upgrade cost, above and beyond just the 'porting' work required to gain Version 12 compatibility. So in order to provide additional value, we decided to develop an all-new 3D cabin, working cabin doors and wing-flex to include in the update and gain momentum towards overhauling the 733 to modern 3D standards. This work has been ongoing for the previous months and is responsible for most of the development time by @tkyler thus far. We've included some pics / links of the interior work in progress below. Background on why this news is only just coming out… Flight testing was delayed slightly while Laminar made alterations that affect certain areas of our models, but also because @Litjan, who handles the flight model, was working towards his 747 Captain rating (now since completed....congratulations Jan!). With the pesky 747 certification process out of the way, Jan has actively resumed flight testing / tweaking things, and if anybody is curious, the team does NOT plan to develop a 747 product . What's to come prior to the initial v12 release? Items to be included in the initial v12 release: All-new, high resolution 3D cabin interior Animated doors Wing flex Ensure satisfactory flight and systems performance Rework our GUI interface to a more flexible, imGUI based infrastructure Once these are complete, we will release the update. A good portion of this has already been completed, and other bits are still in the works. We believe we can do this work before the fall in the USA, and have a solid platform to continue improvements. Once released and stabilized after addressing any bugs or issues, we will immediately continue the work of improving the 733 in several areas. Some items we will be addressing and improving are: FMS VNAV Prediction / Performance Holds Performance / Progress predictions. Swap to XP11 NavData format. FMOD Sound Implementation, allowing us to more easily expand our sound set. New exterior 3D and high-resolution textures Enhanced GUI for accommodating more robust interactions with operations. So that's where we are in the development. The IXEG 733 is being worked on continuously and we're excited about evolving the product as both X-Plane and computer technology / performance evolves, chasing immersion as far as we possibly can. We want to thank you all for being customers and hope we can deliver satisfying experiences through this iterative journey that is flight simulation development. On behalf of the IXEG team, especially @tkyler and @Litjan, we thank all of your for your excitement and patience that has so far driven us to this point. Enjoy the previews! Please Note: All images are showcasing continued work in progress and things, including texture work, are subject to change.

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

First off, on behalf of the teams at Hot Start and X-Aviation, Merry Christmas and Happy Holidays! The following is a little gift to you from our teams. As many of you may know, Hot Start has been hard at work on a new X-Plane 11 add-on aircraft for the past 3 years, the Hot Start Challenger 650. As with the TBM 900, this aircraft will be released under the Take Command! series, as the simulation merits the label. In fact, the simulation you will experience with this product is to a level of realism never seen before in a consumer based flight simulator, so get ready for some fun! The project is nearing completion and we’re ready to start showing you some of the features you can look forward to in the near future. Hot Start designs products with the goal of making them feel like living, breathing machines, without obscuring the finer details of what goes on “behind the scenes” of the simulation. They're all about learning new things, while having fun at the same time. The Take Command!: Challenger 650 will embody this concept even more than our previous project, the Take Command!: Hot Start TBM 900. Nearly every part of the Challenger 650 simulation has been designed from first principles. Basic laws of physics, such as conservation of energy, momentum, the laws of thermodynamics and much more. Every system is recreated from the ground up in custom code, completely independent of X-Plane’s own platform. But before we get into the convoluted details of systems, let’s first start out with visuals. After all, while the systems and aerodynamics make a simulation enjoyable in the long term, it is the visuals which catch your attention. Now, while the exterior model is quite simply stunning to look at, let me give you some numbers to give context to these images. We have pulled out all the stops on this one and decided to place our minimum supported GPU configuration at a still relatively decent Nvidia GTX 970 or Radeon RX 570. This allowed us to up the detail level quite considerably. All in all, the entire visual model contains over 6.2 million triangles and texture detail that is designed to look great even if you were to walk up close to the fuselage. Click on the image below to see it in all its 4k glory. 3D geometry was used to recreate details such as the downlock assist springs, and even the split pins used to secure safety-critical fasteners in place. This level of detail isn’t achieved at the cost of performance. We make extensive use of the “object-kill” functionality in X-Plane, where we eliminate objects that would otherwise be invisible. For example, when you are inside of the aircraft, we eliminate most of the exterior objects entirely, avoiding the GPU rendering toll, as well as the CPU cost associated with sending out the draw calls for these objects. The theme of exquisite visual detail carries on into the interior of the aircraft. After all, that is where you will be spending the majority of your time. The cockpit, as well as the cabin, have the appearance of a premium luxury product, because that is exactly what business jets are. Copious use of double-stitched leather, soft-touch upholstery and fine wood veneers and finishes. Since business jets get relatively little use (only around 200-300 hours per year), they’re not nearly as scuffed and worn out as a typical airliner. Carrying over the theme of simulating everything down to the finest detail, the night lighting is refined to an insane degree. We’ve simulated every lamp individually in the aircraft. Not just every light in the cockpit panels. Everything, including flood lights, exterior service lights, cabin lights. In all, there are over 330 individual lamps simulated and over 500 dynamic light sources placed throughout the aircraft. Every one of the individual lamps contributes to electrical load on the aircraft’s electrical buses, and then gets summed up in the electrical load on generators and power sources. The avionics are of course an extremely faithful custom recreation of the Collins Pro Line 21 Advanced suite. Taking advantage of modern graphical horsepower, we’ve decided to reproduce the visuals down to being able to discern individual pixels on the screens. One important detail to keep in mind is that these are not just skin-deep fakes, where all we care about is that they look believable on the surface. The avionics are actually separated out into individual computers, each running independent of each other. Each computer runs in its isolated thread and can only exchange data with other computers via simulated serial data buses. When an avionics component wants to communicate, there needs to be a real data bus connecting the two (possibly by traversing over multiple hops on the internal data network), and data needs to be serialized and deserialized from the data bus. So there really are 3 independent FMCs, communicating in real time with each other, sending screen outputs to the separate CDUs, and a myriad of other simulated computers. There are probably well over 50 independent computers running, each handling one aspect of the aircraft’s operation (to tell you the truth, @skiselkov lost count). They only learn of the outside world through simulated sensor inputs (each of which has simulated noise and errors), and then they must make sense and make decisions as best they can from those inputs. None of the computers has access to “hidden knowledge.” As far as they’re concerned, they’re really flying an aircraft and they simply try to do the best job they can. Oh and of course, you can fail each individual component on the aircraft, down to cutting interlink data buses between computers. In all, there are over 1,400 individually programmable failures, which can also be saved into pre-made scenarios and reloaded at will (or shared with others for extra fun!). Yes, you read all of that right. Yes, as stated at the beginning of this announcement, this simulation is that crazy in-depth. Now this writeup is getting a little bit long, so we'll just finish on one more feature set. While we take pride in creating fun and entertaining simulations, another of our key goals is to help users expand their knowledge and appreciation of how real aircraft actually work. To that end, rather than hiding all the systems complexity behind a pretty-looking instrument panel, we take the opposite approach. We want you to see how the “sausage is made.” This is why the aircraft includes lots of “study” displays that show you exactly what the internal state of each system is and most also include thousands of lines of tooltip hints which you can bring up by simply hovering your mouse over a data field. The goal of these displays is to show you how a system works internally, and how it responds when you perform an action as a pilot. Rest assured, we’ve barely scratched the surface here. There’s lots more juicy stuff awaiting exploration in the Take Command!: Hot Start Challenger 650 and we can’t wait to show it all off in the very near future. And now for the most important part... The question that’s probably on everyone’s mind at this point: when can we get our hands on it? Well, at the moment we expect to have you able to fly and experience this amazing Challenger 650 experience on Jan 7, 2022. If for some reason this changes we will give you a heads up, but for now you can go with the assumption this will be the day. We will also be doing daily preview streams like we did with the TBM-900 starting Jan 3, with each stream going for 1 to 1.5 hours. We will send daily reminders to our newsletter list prior to each stream. Each day, we’ll focus on one particular area of the feature set. As complex as this add-on is, we highly suggest you to watch these streams to get a good understanding of what's to come. We're excited. Three years comes down to this, and we can't wait for you all to experience what's been created here. Get ready, and we'll see you on the streams very soon!

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

Hi everyone, starting today I will aim to make a video every week for your viewing pleasure...talking about IXEG development, flying our aircraft, showing you procedures, techniques and various other stuff. Stay tuned to this channel!

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

I foresee two 'events' with regards to the 733. Event 1 is "port to XP12 'as is'. Event 2 is 'upgrades beyond the port'. The goal of event 1 is to get it to work in XP12 the way it does in XP11 given XPlane changes. Those who have made 733 purchases since early this year will certainly get the XP12 port version for free as stated on the XA product page. Beyond that XP12 port though, we have not made any determinations about what may or may not constitute a 'paid upgrade' beyond the fact that it shouldn't be egregious or outlandish. Regarding features 'beyond the xp12 port'... we have and hear arugments all the time for/against variants, cargo versions, etc and have not made up our minds yet about what may be next. The obvious things todo are the FMS work and upgrading all the 3D/textures/animations. As far as MSFS, a lot of us developers have kept an eye out on the whole market/dev process and a port is not a trivial thing, regardless of what Fenix / inisim is doing. We're talking multiple 1000s of man hours easily, and at my age and road traveled, that's a tall order.....regardless of the money potential. I rather enjoy my little world in X-Plane and those users who also see the same value in it. Perhaps Fenix, iniSim or someone else can do a 737-300. I can't speak for any other devs in the X-Aviation ecosystem, but for our part, we'll probably stick to X-plane with the 733...best I can tell from today. -TomK

Hello all. Those who have followed know that the IXEG 737 develoment has been stagnant for a long time while I've worked on my MU-2 project and stabilize it after the release. That stabilization phase is nearly done. XP12 is imminent and I'll be porting the MU2 to XP12 beginning next week...and it should not be terribly long (I hope). After that, the 733 will move back into rotation as the primary focus of development with the port to v12 being the first priority. The IXEG is minimally operable in V12, but that's all we can say. We obviously had to make it baseline flyable in order to test/develop it with all the XP12 changes, which have yet to be addressed. As such, our official position for those who wish to try the V11 IXEG in V12 is "VFR joyriding only". I expect we'll set up a 'volunteer forum' where folks can give feedback as to their V12 observations as its better to have more eyes on this stuff; however, we request that nobody report any shortcomings of the V11 733 in V12. We are keenly aware of a lot of things that have to be changed....so we'll want to wait until we believe we've caught all we can find before other folks chime in; otherwise we'll end up with a massive stack of the same reports. So, certainly keep XP11 around if you wish to fly the IXEG seriously until we get it ported over. I've always kept "old version / new versions" side by side on my computer for these transitions. Long-time XP users know that after a major release to X-Plane, there is an inevitable debug period that goes on for some time, though many other devs have begun already, we're behind. ....but nice to have the process underway.....Below screenshot shows what the cockpit looks like in V12 daytime. -TomK

Documents last updated 20th December 2022 IMPORTANT: you must be signed in to download the PDFs below. Not a user yet? Head over to Sign Up. 1128340285_CL650FMSPrimer.pdf CL650 Operations Reference.pdf 1323904309_CL650ExpandedNormalProcedures.pdf CL650 Checklists.pdf CL650 Checklists - Printable.pdf CL650 Flexible Take-Off.pdf CL650 Shared Cockpit Quick Start Guide.pdf

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

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

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

I do Seriously. still going every single day...we'll be making an announcement/report about whats going on here within the next few days. I'm trying to get to a specific point before we give a more formal update and I don't want to rush it....I'm as picky as most of you folks, so I'm steadily laboring away towards that point. -tkyler

...AND....as before. still going full bore. More than a week, but (hopefully) less than a month. Hope I don't eat those words, but if so, it won't be by much. My point is we're still moving along towards our goals according to the plan. A significant portion of 2023 will be spent on the IXEG, so we're just making sure we get off to a solid footing to continue on with further improvements. -tkyler

And initial testing is promising... IXEG XP12 initial testing.mp4

Captains, It's with a lot of excitement that I get to announce this product officially now! Back in 2008 we started X-Aviation with the MU-2 as our first product for sale, and now we're re-inventing it with this beautiful new version. Many people in the X-Plane community found the original v1 we sold as one of their very first payware aircraft back in the day. Today will be the first of a series of progress updates leading up to the forthcoming release of the Mitsubishi MU-2B-60 Marquise 2.0 simulation for X-Plane. Since its beginnings in 2005, the MU2 has been a labor of love by @tkyler and has been nursed for 13 years and for the upcoming 2.0 release, has incorporated the latest X-Plane features. The MU2 is poised to last for many more years to come and certainly through future versions of X-Plane. We are also pleased to announce all previous owners of v1 will be receiving an upgrade discount to v2! The MU-2 is a perfect GA airplane to have in your hangar and get you around X-Plane quickly when you need to feed your flight simulation addiction and actually cover some ground but don't feel like flying tube-liners. With its distinctive profile, engine sound and a cruise speed of 270+ knots, it can cover a lot of X-Plane scenery in a simulator session and have you off the computer before dinner time. In this first report, we'll discuss the most obvious improvement in version 2.0, the visual 3D model and textures. When looking at the MU2 Version 1.0 series 3D, it it quite apparent that there was major room for improvement (mind you this was X-Plane 9 days). As it turned out, trying to remodel the existing 3D was not a viable option and the 2.0 version had to be completely redone from scratch. There are a few noteworthy factors that have enabled the improvements to the 3D detail. Major advancements in Blender 3D, the modeling tool used as well as advancements to the exporter by Laminar, have facilitated a painless workflow between Blender and X-Plane, allowing focus on the geometric detail. In addition, the capability of today's graphic cards to handle fantastic numbers of polygons and high-resolution texture sets have really taken the visual aspect of flight-simming to a level barely imaginable a decade ago. The first order of business was to increase the geometric fidelity of the model and get the challenging shapes and curves more accurate. It is a difficult aircraft to get to look right. Increased geometric fidelity results in much sharper and crisper detail at close camera angles and generally a more natural look all-around. The two images below shows the Version 1.0 3D model against the Version 2.0 3D model. Version 1.x Wireframe Version 2.0 Wireframe If you study the two images above, you will see version 2.0 has a higher density 3D model all around; however, note the darker areas of the 3D wireframe mesh. These are areas where higher 3D detail has been applied in order to achieve sharper visual results that reflect light more realistically as you move the camera around. The traditional way such details are added is through the use of higher resolution texture "decals", much like the decals on plastic models. While decals are a great technique and absolutely useful, they do lack the accuracy of subtle light interaction around geometric edges at closer camera angles. Lighting details on 3D edges have always been one of those areas that make the difference between a fake looking 3D model and one that comes alive. The image below shows a few areas where the 3D detail makes a difference to the lighting. Though higher detail is applied where it counts, it wasn't added where not needed, yielding an efficient 3D model that is very performant in X-Plane. With the 3D detail in place, you have to bring it alive with texturing. X-Plane's PBR (Physically Based Rendering) has always yielded a wonderfully crisp and beautiful color palette when taken to its limits, and X-Plane 12 looks to improve that even more when it arrives. One critical component of believable texturing is a solid implementation of what is known as 'ambient occlusion', or AO as 3D artists like to say. AO is a phenomenon where light loses energy as it bounces around into corners, resulting in darker corners and recesses. Below is a comparison of a 3D model with and without ambient occlusion. The results are quite stark! AO in real time for lots of 3D polygons is still quite performance heavy. X-Plane actually has a small bit of real time AO between the ground and airplane when in HDR mode. You may note the subtle darkening of the ground around the landing gear tires sometime as aircraft taxi; however, X-plane provides no AO effects for aircraft. We obtain this AO effect by "painting" the shadowing into our textures. This is a process known as "baking" in the 3D community and our 3D software tools actually do most of the painting work for us. By baking AO effects into our textures, we can achieve a much more realistic lighting look throughout the 3D model. Baking AO lighting though is a bit of an art and can be a bit time consuming but when done well, the results are quite immersive! AO really shines when applied to interior spaces, giving lots of visual depth and avoiding that flat, cartoony look. When all of the 3D elements come together: the geometric 3D detail, attentive ambient occlusion effects, PBR texturing and X-Plane's great PBR engine, the results are exactly what we've been waiting for 13 years! A SPECIAL NOTE is warranted about this last screenshot. We include it because it shows the 3D detail and texturing in the cockpit at its best! However, the G500/600 GLASS display shown will NOT be included with the MU2 purchase. It is a separate product available by Real Sim Gear through X-Aviation, but for those folks who wish to have some glass in their MU-2, then you'll be happy to know that we support it fully and it will be available straightaway when the MU2 is release for owners of the Real Sim Gear G500! In our next progress update, we'll talk about the cockpit variants, controls and animations and how they play a major role in our immersion! Until next report, Blue Skies and tailwinds!

So we finally have something visual to show for the next update. With our 3D toolchain in place, we are able to make 3D updates reasonably quick... thoughit still takes time to add in the detail. This is a screenshot showing a typical mesh refinment before/after. Whereas when we started the 737 10 years ago, we had to be conscious of our polygon count, its not as bad as it was and X-Plane and modern hardware can suppport more detail. So as we move forward with our updates, we will be making these kinds of refinements around the airplane...moreso out of the cockpit than in, because the cockpit was done pretty darn well the first time IMO. We'll show more sneak peeks as we have stuff to show. -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

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

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

FYI.....still full time on it. still on schedule...still have our same 'target date' not too far on the horizon. Again, more than a few weeks, but less than several months ( minus the weeks since last report) . TK

The Challenger can be hard work on the approach and landing, but when it all comes together it's very rewarding. All the beta testers had difficulty learning how to land, it's all part of the fun. On approach be aware that unlike aircraft like the 737, the pitch response to power is reversed, that means a power increase will see the aircraft pitch down for a moment. This can lead to an oscillation developing, so be sure to fly the pitch attitude accurately. If you find you're wobbling up and down, aim to make smooth power changes, and remember the HUD flight path vector is useful tool, but can get you into trouble too. A useful check is 0.6 on the AoA index on approach. If it's higher than that, you're too slow. Remember Vref +5, and check your weights on the approach ref page. For the landing flare, lift the nose to to arrest the rate of descent, starting at just below 40 ft. Make a smooth power reduction and fly the aircraft onto the runway. The pitch attitude in the flare is around 3 degrees, but look at the end of the runway, not the HUD! You'll have plenty of time for butter later, so for now put the aircraft down positively in the touchdown zone. If you go butter hunting, you'll only find little bounces - ask me how I know! Once you've landed, extend the flight spoilers (the ground spoilers are automatic, but the flight spoilers need to be raised by pulling the lever), use the reversers and you're down. And stay away from that HLIS button, it'll trick you into making your landings worse!

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

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

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

Reference material - https://www.smartcockpit.com/docs/CL605-FUEL_SYSTEM.pdf Page: 16 Fuel tanks are expected to be within 400 lbs / 181 kgs of each other on taxi / takeoff / landing OR 800 lbs / 362 kgs during flight, to avoid Fuel Imbalance EICAS message. First, orient yourself on the overhead panel, we'll be working in the 2nd row (or middle row) of the FUEL panel area. (Fuel.PNG) All three of these buttons should be extinguished under normal operations. Gravity XFLOW Press to begin the process, there's a 1 second delay after pushing the button for it to illuminate OPEN. This will allow fuel to flow freely between both main (wing-based) tanks. There is no EICAS notification that this is open/occurring. (gravity.png) To observe what's happening in the sim. You can go to the Challenger 650 menu -> Study -> Engines -> Fuel System... You'll notice that whatever Main Tank (either Left or Right) has more fuel that this will continue to consume, whereas the side with less fuel will not. Thus balancing the tanks. L (R) to AUX XFLOW Press the appropriate button to begin the process, there's a 1 second delay after pushing the button for it to illuminate ON. This will remove fuel from whatever side is select and transfer it to the auxiliary tank. Determine which tank has more weight in fuel Left side? Choose L to AUX (L to AUX.png) Right side? Choose R to AUX (R to AUX.png) There is a lock out mechanism that does not allow you to press the opposite button when one is already selected. Pressing L to AUX, for example, then pressing R to AUX, will no longer illuminate the L to AUX button. Pressing the R to AUX button again will resume the L to AUX transfer and the button will illuminate ON again. Once you're done balancing the tank, make sure to deselect the previously selected L (R) to AUX button. The aircraft will now suspend fuel consumption from the two main tanks and pull from the AUX tank until depleted. *Edit* Thanks! @airforce2 As long as a main tank is below 93% full, the aux tank feeds the main tank to maintain the level at 93%. Once a main drops to 93%, the main quantity will remain constant and the aux level will drop. It will appear that the engines are burning from the aux tank, but in reality the engines are burning from the mains and that fuel is being simultaneously replaced in the main tank from the aux tank ejector xfer pumps. To observe what's happening in the sim. You can go to the Challenger 650 menu -> Study -> Engines -> Fuel System... Note: The plane will display an EICAS warning message: FUEL XFLOW SOV OPEN if either button is ON for more than 50 seconds and the tanks are balanced within 100 lbs.

With modern tools, comes modern features.

Another update. Though its been quiet here, it is still very much full speed on my end. There simply is a lot of infrastructure work and double-checks to get ready for release. One of the things I'm doing is moving the documentation to be browser based. That was a bit of a last minute decision but one I think will pay dividends moving forward. This makes the documentation searchable and navigated much more quickly and in addition, much easier to update and read IMO. I also forsee the need to facilitate tutorials and such and this format will allow the addition of such material to be added more quickly and presented more effectively. This infrastructure will also serve as a foundation for similar documentation efforts we plan to bring to the ixeg 737. We should be able to publish the docs to PDF also for those that desire such. The paint kit is also complete, which required its fair share of prep and documentation also. The documentation will probably drag on another day or two. At this stage, its looking like early June release. I will say I'm disappointed its not in the 3 week time span I had hoped and predicted, but not disappointed with why...because I simply want to refine lots of little things to ensure its a first class simming experience and its coming along very well. -tkyler

In addition to the VNAV work we have also these fixes lined up for the next update: Improvements * Added switch in aircraft file to always force experimental flight model on * Improved tracking ability of nosewheel in tight turns (less skidding) * A "direct to" turn will not attempt to re-intercept the line between current aircraft position and the waypoint * Yoke checklist can now be flipped up and down and yellow bug goes all the way to top again * Added a dataref to indicate if autothrottle is active or not * Added a preference to "pause on Top of Descent" Bug fixes * Fixed right-hand windshield wiper 3D * Fixed fuel gauge testcycle * Fixed leading-edge devices lighttest button * Fixed EGT needle on steam gauges not going higher than 800C * Fixed hydraulic accumulator pressure on modern gauges always showing full pressure * Autopilot trim cutout switches will now also stop the speed trim * Scavange pump will not trigger unless a center-tank pumpswitch has been turned on then off * Animated stopwatch buttons * Vertical speed scrollwheel can now turn "infinitely" (instead of running against an invisible turn limit) Cheers, Jan

you and me both. Still working on it every day (except weekends...really need my mental breaks)....there's just tons of little details to tend to, especially with lighting control and tweaks. I just finished swapping out all the old exterior lighting with the new V12 lighting yesteday, so that's the latest thing I worked on. Still moving down the punchlist. -tk

Hello All, This will serve as a formal forum announcement that we have released the version 1.6.1 update for the CL650. All customers who have purchased the CL650 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 CL650 from today forward, your purchased download will already be updated to version 1.6.1 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 Challenger 650 download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: What's New / Changed: ************************************************* Please carefully review the following section about the V1.6.1 release highlights. These point out particular "gotcha" changes that might surprise you if you didn't expect them. Also, be aware that trying to reload an in-flight state from a previous version might not work very well. There were numerous internal changes to the avionics which will cause many of the computers to perform a cold reboot. When using a different version, please only try to load a previous state that was cold-and-dark. ************************************************* Release Highlights: 2988: Elevator control system is missing gain change mechanism from control column, causing over-controlling at higher speeds 3121: Implement variable pitch feel based on stabilizer trim position We've reworked the pitch feel to replicate the variable-rate pitch feel of the real aircraft. Unlike other aircraft where the pitch feel is based on airspeed, the Challenger uses the stabilizer trim position as a stand-in for airspeed. The pitch response near the center gets more desensitized the more nose-down elevator trim is applied (implying flight at a higher speed). There is also a fixed "curve" that gets applied near the neutral point. This comes from a mechanical part of the elevator mechanization called the gain-change mechanism. This is more-or-less fixed and is always applied on top of the variable pitch feel from the stabilizer trim. We recommend removing any kind of curves you have applied to your joystick or yoke and try to get used to the new out-of-the-box feel. If you have a force-feedback yoke with controllable force intensity (such as a Brunner FFB yoke), you can disable the trim-dependent pitch feel in the User Settings under the User Interface tab. You can then replicate it in a proper FFB way by gradually increasing the force needed to move the elevator as elevator trim goes from 5.0 to 1.25 (5=lighest, 1.25=heaviest). Outside of this range, the force should be constant, as the real pitch feel mechanism doesn't change force intensity outside of these ranges either. 2866: Implement dynamic GPS jamming simulation The CL650 now simulates dynamic, unannounced GPS jamming that happens in certain regions in the world, especially near disputed areas and active conflict zones. The locations of these areas are usually not NOTAM'ed, so you are encouraged to be on the lookout for potential issues with GPS reception in areas such as: - the Middle East - Eastern Europe - South China Sea - parts of Mexico Please note that these locations aren't hard-coded into the simulation. They dynamically change over time and needn't be active at all times. We can also add new areas post-release, and already have plans to add NOTAM'ed (scheduled and published) GPS outages. The simulation works by performing radio signal propagation modeling (including terrain masking) between the aircraft and every jamming station. If the signal levels of the jammer overpower the GPS satellite signals at the aircraft's position, the GPS position integrity will gradually degrade, until it is completely lost. You will then need to revert to inertial navigation and utilize radio or manual position updating. For now, we have chosen to avoid simulating GPS position spoofing, however. Please note that not all approach procedures can be flown without GPS available. Consult the approach procedure charts for required navigational sensors, as well as required navigational performance (RNP). This can then be cross-checked against the EPU value (Estimated Position Uncertainty) on the PFD as well as on the FMS PROG 2/2 page. Without GPS available, the FMC will attempt to use any enabled radio sensors (VOR/DME or DME/DME) as a source of position updates. Thus, flying an RNP 1.0 or sometimes even an RNP 0.3 approach might still be possible, provided that the approaches do not hard-require a GPS or GNSS sensor be available, and that a suitable position-updating navaid is available within range. For study purposes, the status of the jammer stations can be seen in the Study > GPS > GPS Jamming Stations window. 2927: Implement manual FMC position updating Dovetailing with the above GPS jamming functionality, the FMC now fully implements manual position updating. It is, admittedly, a very rarely used feature with GPS available, however, it does manifest in one useful way when in a GPS-denied environment. On departure, you will now have a "RWY UPDATE" prompt available on the ACT LEGS page on LSK 6L while the aircraft is on the ground. This can be used to manually update the FMC position to the runway threshold prior to takeoff, thus nulling out any positional drift due to purely inertial operation. 2963: Add ADG and nose gear door pins The aircraft now contains a beautiful 3D model of the air-driven generator (ADG, aka RAT on other aircraft), and together with that it brings an additional set of ground pins in the nose gear bay that must be manipulated by the pilot prior to and after a flight. The ADG pin is located on the right-hand wall of the nose gear bay, in the forward section. This pin locks the ADG in the stowed position, to prevent inadvertent ADG deployment while on the ground (restowing the ADG requires qualified maintenance personnel be called in). The second new ground pin is for the nose door and is located on the same right-hand wall of the nose gear bay, but more towards the aft section. For personal safety of ground crew while in the nose gear bay, the nose door is pinned, thus preventing any chance of the door closing and injuring personnel working there. This pin is typically installed after a flight and removed before a flight. These two additions complete the full set of 5 ground pins that are used in day-to-day operations. 2910: Refactor NAV-to-NAV transfer to avoid LNAV capture when APPR LOC is armed The NAV-to-NAV transfer system behavior was changed to behave more like the real airplane. When the aircraft is being vectored and utilizing HDG lateral mode, pushing APPR with a NAV-to-NAV approach loaded (e.g. an ILS) will no longer capture the LNAV path if the airplane happens to come close to the FMS path. Instead, *only* the armed APPR LOC mode will capture when the localizer begins to center. This helps prevent an inadvertent capture of the FMS path that might no longer be applicable. On the flip side, this means you will not be able to perform high-angle LOC captures (>45 degrees) by first capturing the FMS path in APPR LNV and then transitioning to APPR LOC. To perform a high-angle intercept with an intermediate step through the LNV mode, first push "NAV" on the FCP to arm the regular LNV mode for capture. Wait until the mode captures the FMS path and only then push the APPR FCP button to arm NAV-to-NAV transfer onto the localizer. 3036: Remove landing data that doesn’t exist in real box and add supplemental data message We've made fixes to the APPROACH REF computer to bring it in line with the quirks that the real avionics has. One of those particular gotchas is that you will no longer be able to compute an Actual Landing Distance (ALD) value when the runway condition is set to WET on page 1/4. Instead, the box will simply post an amber '?' for the ALD value and you will get an amber PERF OUT OF RANGE message. For regulatory reasons, when the runway is wet, the only value to be used is the factored Landing Field Length (LFL). You can switch the ALD display to LFL by typing 'L' on the scratchpad and pushing LSK 4L on APPROACH REF page 2/4. This will remove the caution message and the FMS will show the factored (1.15x) landing field length instead. However, on the flip side, when the runway condition is set to any of the other contaminated settings (i.e. SLUSH-WATER, LSNOW, CSNOW or ICE), LFL becomes unavailable (and will post a PERF OUT OF RANGE message), and you will need to use ALD instead (place an 'A' on LSK 4L to switch to ALD display). The reason here is that there is no landing distance correction factor published for these contaminated runway conditions, so you will want to enter your own into LAND FACT on LSK 2L. An additional gotcha is that when the runway condition is set to anything other than DRY, the FMS will post a white SUPPLEMENTAL DATA message. This message cannot be avoided, and is intended to emphasize that the FMS isn't using data from AFM Section 6 (Performance), but instead from AFM Supplement 2 (Operation on Wet and Contaminated Runways). 2848: Implement route names and loading of routes by name You can now save and load pilot routes by name. This is done either by entering the name on LSK 2L of page 1 of the FPLN page, or by entering a custom name in PILOT ROUTE LIST on LSK 6L or LSK 6R. When a name is entered on FPLN page 1 LSK 2L, if the route doesn't already exist in the PILOT ROUTE LIST, the name is simply assigned to the current flight plan. This name can then be used as the route name in PILOT ROUTE LIST by pushing LSK 6L or LSK 6R. If a route with the same name already exists in PILOT ROUTE LIST, the user is prompted if they would like to load that route instead. Loading a pilot route into the active flight plan is not permitted while the aircraft is in the air. 2849: Support new VATSIM departure/arrival ATISes Some VATSIM regions have started publishing separate departure and arrival ATISes, just like some real airports do. Thus, the ATIS type selection on DATALINK > AOC CORP > ATIS now correctly attempts to pick the type-specific ATIS first, before reverting to the generalized one. 2860: Add volume control for FO audio You can now control the automatic first officer's audio volume when reading checklists. The setting is located in User Settings under F/O Assists. New Features: 2823: Add IVAO Altitude client detection 2824: Add IVAO SELCAL integration 2825: Add support for showing COM TX flag on IVAO 2848: Implement route names and loading of routes by name 2849: Support new VATSIM departure/arrival ATISes 2860: Add volume control for FO audio 2866: Implement dynamic GPS jamming simulation 2869: Implement TOC and TOD display on MFD data window 2927: Implement manual FMC position updating 2953: Add search function to failure manager 2954: Add tooltips with descriptions to the Bleed study screen 2955: Add ASU engine parameters to the Bleed study screen 2963: Add ADG and nose gear door pins 2988: Elevator control system is missing gain change mechanism from control column, causing over-controlling at higher speeds 3121: Implement variable pitch feel based on stabilizer trim position 2995: Need to implement ADG ADCU failures in the failure manager 2996: Implement missing stall protection system failures 3002: Add datarefs to expose the internal CL650 atmospheric model 3006: Implement a dataref interface to wire and ARINC-429 abus data 3116: Need a ground service menu option to fix a rotor lock Improvements: 2816: MFD radio controls should have a test function on the NAV radio 2847: PROG page should show MANUAL or MEASURED in title when using the respective FUEL MGMT mode 2858: Update windshield heating auto-checklist to select either LOW or HI before takeoff 2778: Selecting SID/STAR does not narrow down runways 2435: Rudder needs more effectiveness to cope with V1 cut 2872: Make circuit breakers require a long click to pull to help avoid accidentally pulling breakers by randomly misclicking 2885: Show airframe manager when aircraft is repositioned using X-Plane flight setup screen 2898: Refine VOR/DME and DME/DME tuning when in the approach phase 2707: Need to show a magenta "FROM" flag next to the PFD horizontal deviation bar when flying from an FMS waypoint 2902: Refactor RNP APPR and RNP AR APPR determination to follow proper ICAO PBN rules 2908: Adjust electrical loads of components to be slightly more realistic 2910: Refactor NAV-to-NAV transfer to avoid LNAV capture when APPR LOC is armed 2912: Refactor autopilot and IRS code for more stable operation in ATT mode 2914: 10th stage bleed study screen needs to color in the vacuum ejector line using the temperature of the vacuum line 2915: Refactor tooltip system to use cairo rendering and XP11 modern windows for proper scaling 2918: Readjust tire drag down a bit to roll more easily on idle thrust 2944: Hoppie ACARS DEPART CLX system needs to handle clearance confirmation and error messages 2966: Add documentation link to the Study menu 2983: Allow user to specify a custom OCEANIC CLX facility in user settings 2985: Implement engine fuel feed lines as having a volume of fuel for delayed fire shutoff valve reaction 2991: Default the nose door to open on new persistent airframes 2696: During SPS test needle should go past red zone due to rate-advance mechanism 3036: Remove landing data that doesn’t exist in real box and add supplemental data message 3061: Redesign TUNE page parsing to be much more strict 3063: Selecting TO or GA should always activate the TO thrust limit 3117: When an in-flight state is repositioned back to the ground, reset core temps to allow immediate shutdown without core lock Bugfixes: 861: TUNE page should not allow entry of 4 letter LOC idents 2808: Leftover experimental GS steering code is causing pitch oscillations 2807: Squawk code transmission is broken in ARINC622 format 2806: UM74 and UM75 direct-to interoperability with Hoppie CPDLC broke prior to 1.5 release 2809: Maximum distance for DIS CROSS on FIX INFO should be 500 miles, not 200 2810: Galley normal map has excessive gloss 2811: Crash when airplane is dragged up into the air in turn estimation code 2813: Crash when selecting direct-to the last waypoint on an airway if followed by a discontinuity 2815: NAV radio test wasn't generating the correct test data out of the NAV-4000 and DME-4000 radios 2817: When an intercept leg his an IF-TF target, it incorrectly marks the intercept leg as virtual, instead of the IF leg 2821: PAX hurry up call option is broken 2802: APU GEN off caused CTD, broke airframe file 2768: Changing NAV SRC while OEI causes CTD 2803: Crash due to dangling airway-to-waypoint mapping table left over after a navigational database swap 2822: MFD Nav Radio Missing Auto Label 2828: Closing a disco in front of a VECTORS transition isn't generating a TF leg segment properly 2440: When a NAV radio is set to auto tuning, manual tuning via MFD doesn't work 2801: CTD when using DTO history 2829: ETA column on FPLN PROG MFD DATA page is computed incorrectly on TOD when TOD is on current leg 2830: DIR-TO page isn't showing required path angle and VS on page 1 2832: Alternate cruise altitude isn't being used in alternate fuel use calculation 2833: ROSE mode TO-FROM flag should be drawn with a black outline, not black-filled 2834: FPLN sequences prematurely when crossing 180 degrees of longitude 2835: IRS hybrid position solution needs to handle GPS position wrapping 2837: Add Altitude and POSCON to list of supported networks/clients in user settings 2819: CTD crossing 54N040W 2838: Mandatory turn direction can be mishandled by LNAV in certain corner cases 2839: Pilot oxygen mask blockage failure condition inverted, resulting in zero oxygen consumption 2841: Limit CPC auto valve rate to prevent oscillations when high cabin altitude condition is encountered 2840: Implement explicit versioning of serialized data sets to avoid persistent breakage of state files 2842: Entering a single-digit or two-digit radio frequency should tune the matching frequency preset slot 2843: Entering more than an 8-character frequency slot name in TUNE page crashes 2844: Moving VS/Pitch wheel should revert to Pitch mode unless the active vertical mode is VS or GS capture 2846: TO and GA vertical modes should be cleared by AP engagement or pushing the FD SYNC button 2850: Rounding of coordinates can cause a copy-back of 60 minutes out of a fix definition 2851: Geographic coordinate entry must allow entering 180 degrees of longitude 2852: When going direct-to the first waypoint on an airway, the direct-to path construction goes haywire 2854: Don't allow editing VNAV data on FA legs 2855: Inserting PDW at end of FPLN while in the air causes the FPLN to go direct-to the PDW instead 2857: Using FLEX takeoff results in spurious VSPEEDS DESELECTED when changing altitude in flight 2859: Update 3rd party docs to latest state 2861: Always clamp FD pitch command to allowable range 2862: Don't do terrain auto-popup on the PFD during a TAWS test, only during a genuine TAWS caution or warning 2863: When a CPDLC direct-to targets a navaid or airport as a FIXNAME, INSERT MOD into the FPLN fails 2864: When an FC leg occurs on a 5-character waypoint, the length field gets truncated to show only the leading zero 2556: Clock Local time is non-functional 2875: Pitch servo mistuning during G/S approaches was causing divergent oscillation at lower framerate 2876: Missing altitude in POSITION REPORT message human-readable format just before the "NEXT" word 2878: RNP approach handling without GNSS is producing spurious FMS messages 2879: Hoppie CPDLC interface needs to support climb and descent rate messages 2882: Boost pump INOP light and CAS messages should come on when on ground and the pump switch deselected 2883: Don't post ATS FAIL when no ATS mode is active and T/Rs are selected 2877: Secondary motive flow supply line occurs after the main ejector check valve, not before it 2884: Don't compute CLB, CRZ and MCT N1 targets when engine bleeds are off 2881: BACK ON ROUTE triggering too early, while still very far cross-track 2880: Waypoint ETA time computation unstable due to floating point rounding 2886: libcpdlc - deleted some dead code from ARINC 622 refactor 2887: libcpdlc - POS REPORT FANS page isn't automatically picking up FMS-supplied waypoint name data 2888: libcpdlc - altitude and speed display is doing incorrect rounding 2889: IRS study window wind component needs to be reversed and have proper alignment and units displayed 2890: TOC data shouldn't show on VNAV window 2891: TOD shouldn't show on VNAV window unless we're close to it 2893: Don't show TOC and TOD lines on FPLN PROG MFD DATA page when they're no longer relevant vertically 2894: Don't produce a vertical track alert when we're already below the TOD 2897: NRST APTS map symbols on AFDs need to respect the minimum runway length limit set in DEFAULTS 2900: Spurious APPR NOT AVAILABLE when an approach is marked for RNAV-any-sensor even though IRS is available 2901: Don't flash waypoint name on PFD when approaching it if FPLN sequencing is inhibited 2904: THRUST LIMIT page should show VERC label, not VFTO, during single-engine enroute climb or driftdown 2907: LPV approaches flown as RNP aren't bringing up the RNP ARM and RNP APPR messages 2913: Procedures with legs whose course is referenced to a LOC or ILS emitter's magvar are having the airport's magvar applied instead 2903: Non-applicable "Sit in Seat" menu items will now be disabled based on user location 2916: Add animation datarefs for ADG 2917: ADG drop at high speed stalls the turbine blades and doesn't come up to full speed 2920: Rename CL650/adg/phi dataref to CL650/adg/pitch 2922: Reacquisition of nav radio corrections after long period of no corrections doesn't wash out accumulated variance quickly enough 2923: FMS-FMS DISAGREE message mustn't compare the position of the non-active FMS 2921: FPLN with DEST only crashes when a departure runway is selected from arrival airport while on the ground 2924: LOC and VOR steering is too lethargic at larger distances 2925: Don't drop EPU when doing navaid retuning 2926: New tooltip system needs support for custom fonts with unicode characters 2928: Don't dump TACAN-colocated DMEs from the radio simulation 2929: Entering PAX/WT in one go doesn't correct convert LBS passenger weights, resulting in spurious INVALID ENTRY 2932: TERM WX VIEW page has carets on the wrong side when available airports overflow to the right-hand side 2933: Vertical prediction gives incorrect climb path for simple flight plan 2936: PL21 FMS FPL test program doesn't resolve airport and runway arguments to the "pos" command correctly 2937: Move climb mode variable into tighter scope in solve_vnav_clb_misap 2938: Don't hard-assert that we need elevation in FPL path solver 2939: Automatic VOR/DME updating facility shouldn't try to tune in TACANs 2941: Don't attempt radio corrections if the station is more than 45 degrees slant angle 2942: Don't post FMS DR and LOW POSITION ACCURACY messages when on the ground 2943: Radio correction distance misestimation due to altimetry errors and slant angle needs to be taken into account 2945: Manually setting position on the ground should set all FMCs at the same time 2946: In certain cases, going direct-to can cause the VNAV to enter descent mode prematurely 2947: When shortening procedures, update the TO side of the procedure line to reflect the new termination waypoint 2948: Doing a vertical direct-to to a CF leg that is also a lateral direct-to results in incorrect VDEV computation 2949: Disable IRS soft realign in preflight phase to avoid generating bogus alignments if the airplane starts moving 2950: Add extra FSCU table data for estimating very low AUX tank levels and aircraft is in an on-ground attitude 2951: Desensitize amber GNSS NOT AVAILABLE message so it doesn't always come up on the ground when powering up 2957: Creating or deleting custom states doesn't immediately sync the airframe database to persistent storage 2958: HUD rendering isn't stopping when the HUD combiner is stowed 2960: Refueling on uneven terrain can fail to hit the HL switch on the higher wing 2962: Add special case for abbreviated 833 frequency entry for 16xxx to 19xxx 2964: Reduced half bank isn't being used when it should 2961: Restore XP squawk code datarefs explicitly during a state restore 2968: ATS PIDs need to be reloaded from master config even on a state reload so we don't keep reusing old PID params 2970: Relax FPL deserialization when loading persistent disk FPLs in case the NAV DB has been changed or corrupted 2972: Optimize ARINC 429 code to avoid using avl_walk wherever possible 2973: Expose runpool profiling datarefs in non-debug builds 2974: Don't redraw cabin info screen when camera is far away from the airplane 2845: Chart zoom commands’ description is backwards 2980: Optimize PFD ADI drawing by removing explicit black outlining of certain text elements that aren't outlined on the real avionics 2979: EPU shouldn't be being drawn on compressed PFD 2978: Bearing display on compressed PFD doesn't fit vertically into the PFD 2981: Reduce Hoppie polling interval to 1 minute 2982: When DTG is unavailable on PFD, show it as 4 dashes, not dash-period-dash 2986: Show white NO APPR if a loc-check occurs during NAV-to-NAV setup 2997: Backup low speed cue in absence of Aux AOA signal should show enhanced red band instead of plain solid 3001: Refine autopilot pitch steering to get rid of "shaking" of yoke when AP is making large inputs 3005: LNV steering mode is prone to some oscillation at higher speed 3007: Bleed flow system mis-accounts bleed mass-flow demands, resulting in too high running ITTs 3011: Don't compute a TO N1 limit with 10th stage bleeds and anti-ice selected on 3008: Automatically check the respective minimums box when the DCP DATA knob is spun while setting REFS 3012: When baro minimums are selected, ALT SEL should snap to the baro mins value when rolled through it 3018: Update GPS Almanac URLs to new ones 3025: Implement variable rate trim commands from FCC as they should be PWM, not constant 3033: Extended no-manip section of cabin and fuselage to avoid clicking through to outside manipulators 3027: Pin missing on Nose Gear torque links (scissor links) 3030: Autopilot should be available when on EMER POWER ONLY 3021: Flying the KLEW ILS 04 from ENE w/HILPT causes a CTD when turning inbound 3029: At airport 3J7, the fueler is asking for liters when it should be asking for gallons 3037: Reduce min volts for most avionics modules to avoid a reset during a hard generator under-power trip 3042: VNAV direct-to shouldn't clear constraint class on intermediate legs if there is still a speed constraint on the leg 3043: VNAV phase can revert to CLB if TOD is constructed based off a descent constraint on an enroute leg 3045: "Requires Better Pushback" note on handling request form is misplaced vertically 3047: Hoppie """CPDLC""" likes to send lowercase in messages, so auto-uppercase everything 3048: Don't round BOW and AVG PASS WT values in defaults 3050: When left collector is nearly empty, ejector pump incorrectly over-calculates delivery pressure, causing APU cutout 3051: Arc legs can turn the wrong way if the aircraft intercepts at a steep angle and is outside of the arc start/end radial 3055: Entering wind component on TAKEOFF REF or APPROACH REF shouldn't zero the value if no H/T/P/M is given 3056: Permit fly-by of fix terminations if followed by intercept legs which would trigger before the fix termination 3057: Distance and radial terminated legs need to allow for fly-by unless explicitly tagged as overfly 3062: Don't allow fuel truck hookup with beacon light on 3064: Refine steering around tight arcs for RNP-AR approaches 3039: GPS doesn't correctly compensate for time-acceleration on velocity trends 3066: When an intercept leg overshoots an arc due to turn radii, prevent an intercept from happening on the far side of the arc 3067: Don't do direct-to joins on the next leg when a DF is followed by a TF 3072: Need support for RF legs with more than 270 degrees of arc 3071: LNAV should use rough altitude estimation to correct groundspeed and do turn prediction further down the FPL 3070: V-MDA PATH guidance isn't aiming at the runway or airport, but instead at the MAP 3073: AC ELEC page line from APU gen to APU data box should be filled green when APU gen is available and selected on 3074: Use previous pass VNAV altitudes for turn estimation during the LNAV construction pass 2190: Don't allow entering 3-digit abbreviated frequencies into COM tuning field 3076: Show INVALID CHANNEL instead of INVALID FREQUENCY on incorrect channel entry into COM tuning fields 3079: Vatsim """CPDLC""" sometimes uses CONTACT messages with reversed arguments 3078: SBAS integrity check should only be performed in LPV approach mode or on approaches where SBAS is mandatory 3082: Redesign VNAV phase determination to be much simpler and more reliable 3083: FMC2 checks the wrong GNSS side for disable status before using it 3085: VNAV SETUP transition alt/level entries should reflect the same value as used for the FL ALERT 3087: Hoppie """CPDLC""" messages can sometimes include a trailing " FT" part in altitude arguments 3089: Add additional detection of Hoppie logon rejections 3090: Reduce the engine vertical cant slightly to line up closer to technical docs 3093: AFD heading and engine data isn't being properly cleared out when the system is powered off 3094: Disabling FD should disable VNAV mode 3096: Need to handle Hoppie "MESSAGE NOT SUPPORTED BY THIS ATS UNIT" message 3099: Performing T/R check on the ground shouldn't cause the ATS to go FAIL, and only DISENG'D if active 3098: Deselecting TO mode on the ground should kill N1 TO ATS arming 3101: When ATS disengages automatically in landing mode, don't flash amber DISENG'D on the MSD 3104: Reduced bank angle heading control is unstable 3108: Refine GP mode steering when large trim changes are required due to flaps deployment and speed changes 3109: Don't attempt to process gear-related CAS messages from bad data when both PSEUs fail 3110: Parking brake config warning must come on when in the air or PSEU is failed 3106: ATS MSD should go blank after 7 seconds of SERVOTST 3112: Prevent removing a ground pin when the PSEU is attempting to move the corresponding actuator 3115: Refactor final VNAV path construction to start at the runway, not the FAF, except in case of V-MDA approaches 3122: Fix gap between top edge of overhead base and ceiling 3123: Arrivals with STAR terminating in vectors without a bottom altitude will fail to capture PATH mode 3124: VNAV doesn't stop on a level segment if the subsequent leg's altitude constraint is lower 3125: Entering a nonexistent airport into ORIGIN with no flight plan will crash 3126: Implement more route name entry validation 3127: Cruise speed determination is incorrectly converting m/s to knots and resulting in bad estimation when cruising below Mach 3128: Fixed gap between meshes in vertical stabilizer 3032: Fuel cap and forward equipment bay doors are missing lock/unlock decals 3015: 3 screws on radalt antenna on tail of aircraft are doubled-up and z-fighting 3133: Fixed gaps on rough section of power lever handles Normal Map. 3132: Don't allow loading pilot route directly into ACT FPLN while in the air 3134: If FMC groundspeed is momentarily invalid, it can cause FMC3 to crash Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.

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

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.

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

Sneak peek for the regulars....and a form of update I guess. All the cabin/galley 3D geometry is done...I'm working my way through the cabin currently, adding / texturing the smaller details and tweaking the lighting. A few more days of this I suspect, then I'll hit the final punchlist and tests with Jan. An unknown....XP12 b06 is hitting us devs shortly with some rendering changes...hopefully it won't affect us too much, if at all. Fingers crossed. -tk

The Challenger has very good takeoff performance, so everything happens quickly. For the first few flights a heavier weight can help keep things in check. One of the key differences between A320/737 aircraft and the Challenger is there is no speed reference system on the Challenger. Instead the flight directors will give a fixed pitch target when pressing the TOGA buttons. Following the guidance from our subject matter experts, and adapting it for use in the simulation, we've got two easy ways to manage the initial climb, which can be remember as Pitch/Sync and FLC. Try both and see what works for you. Pitch / Sync: Takeoff and follow the initial flight director pitch target. Accelerate in the initial climb maintaining that pitch, retract the flaps at VFTO+5 then at a safe altitude hold the “Sync” button and lower the nose to about 10 degrees to start accelerating. If using autothrust it can be set to maintain a suitable speed, but your primary control is pitch, which can be adjusted easily by holding sync and flying the aircraft to the new pitch attitude. FLC: Takeoff and aim for the initial pitch target before selecting FLC mode to capture a speed of roughly V2 +20. At most weights this will result in a very steep climbout. At a safe altitude, increase the speed to lower the nose then retract the flaps at VFTO+5 A hybrid approach may be useful - remember unlike an airliner the Challenger has seats facing sideways - so while a space rocket climb profile can be fun, it’s unlikely to get repeat business for your VIP transport business.

LINK HERE Note: aircraft name is clipped to 12 characters for custom airframes, sadly (limit does not apply to default profiles). Fixed by SimBrief Based on the already-accurate default CL60, with the following adjustments: equipment codes and extra flight plan remarks kindly provided by Graeme_77 here: OEW/BOW updated to match the Hot Start airframe without passengers (12,315 -> 12,556kg, includes two pilots) passenger weights updated to somewhat more closely match the randomized weights as simulated, going with 74+15kg so you can still carry 5 passengers+luggage and full fuel at MTOW if you are flying Kim Dotcom around (supposedly ~141kg or thereabouts), sorry, you will have to make adjustments, or just count him as two passengers see below for more information: Don't forget to add extra crew (anything above the two included in OEW) as passengers when planning your flight! Cheers, Tim

I would like to chime in here - I have worked with Tom on this over the last week intensively - previously I had test flown the 737 in XP12 (after we fixed the major roadblocks of even getting if flyable, like making the flaps work, etc.) and I had tuned the flight model. Tom worked hard on 3D modeling over the last months with little for me to do (I am too stupid for blender and those things) and now with him approaching the end of that work, I dove back into flight and system testing. The more I test, the more stuff shows up that does not work anymore, because Laminar changed things - and these changes are all improvements in modeling systems, yet they still leave our "old" way of doing/overriding them unusable. So in a very real way we have to redo a lot of the things we already did for XP11, it is not a quick conversion at all - and this is something we definitely underestimated when we initially said to "upgrade to XP12 for free". The move from XP11 to XP12 is not an upgrade, it is in many areas a repeat of the dev work work we already did for XP11. And I am thankful for most of our customers to be very understanding of the fact that we charge a small price to compensate us for this! I think the old 737-300 still has a lot of life in her, I thoroughly enjoy my "test flights" and find myself again and again to "just finish this approach" even though I was just testing some autopilot PID constant ... simply because it is fun to fly and looks great in XP12 . Cheers, Jan

Every operation will be somewhat different of course.... Once we complete the last leg of the day and the shutdown check is complete, one of us is immediately getting up out of the seat to open the cabin door and go verify chocks are in place, the nose doors are opened, and 5 pins are inserted. Of course if our last leg is a passenger leg - they are disembarked first. One pilot typically stays with them for the walk to the vehicles or the FBO - while the other pilot heads to the interior of the baggage compartment to pass the bags to line crew. That pilot then comes through the cabin to check for forgotten personal items - concluding with a thumbs up to the pilot adjacent the vehicles. If they walked inside - typically a text is sent between pilots that the cabin is clear (or isn't). At this point the pilot with the airplane will coordinate with the line crew re: required services - verifying chocks are in place - then retrieving the pins and inserting them. Different operations have different philosophies/standards regarding nose doors opened or closed. At our home base - we will always open the doors and insert 5 pins. Away from home while on the road we can exercise discretion to leave them closed. In a location with security concerns, or if there are any concerns regarding tugs, line crew, etc - we may elect to go with 3 pins and leave the doors closed. I'd say in our operation the doors are left open with 5 pins the majority of the time. Under no circumstance will we leave the nose doors open without inserting the 2 additional pins. Once pins are inserted and we're both back on the jet - it's time to start cleaning up and preparing for the next flight. Garbage is gathered, old coffee is dumped, drinks in the drawer with paper labels are removed from the ice bins - leftover catering is emptied from the chiller and either given to line crew as trash, as a gift, or to be stored in the FBO fridge. If the cabin needs to be vacuumed - we vacuum while power is still on. Tables and surfaces are cleaned at this point, seatbelts are cleaned and put back into presentation , the sinks and lav are cleaned and while this is happening - line crew is probably performing the lav service. Dishes and linens are given to line service as well. We like to keep power on until all of that is finished so we can check the lav - that enough (hopefully clean) water has been put back in and its back to smelling/looking fresh. We also have to restock from the storage drawers in back. Things like snacks, drinks, chips etc - all have to be replenished. If 15 minutes has gone by - one pilot is checking/servicing the oils in the utility bay. If temps will dip towards or below freezing - we purge the potable water system. This is often done at TOD depending on circumstances to avoid dumping 10 gallons of potable water on an FBO ramp which will turn into an iceberg. Water lines must be purged on the ground which is similar to prepping a recreational vehicle or boat for winter storage , minus the antifreeze, although there's different techniques there too. Sometimes during all of this we may also fuel for the next day's flight - circumstances of course dictate when we would do this as there are considerations to keep in mind leaving the jet with a lot of fuel. We also will consolidate crew baggage and put it in the baggage door opening in preps for offloading. We ensure the garbage, catering, fridge items, etc - are indeed all off. The parking brake at this point has probably long been released since chocks were verified - and the signs put in the cockpit windows indicating the jet is safe to tow. We verify one of us has recorded the 'numbers' from the FMS for the trip paperwork. (OFF/ON/FLIGHT times and OUT/IN Fuel) Suction cupped iPad mounts are removed from the windows, the Sentry is verified as off and packed up so it can be charged at the hotel if needed. If it was a night flight and next flight is day, and we're about to secure the airplane - lights will be brought back to a daytime config (full bright). If it's a hot and sunny location - cabin window shades are closed and cockpit reflective covers are put in place. We also have a pin to secure the emergency exit in the cabin that gets inserted. At this point we verify requested services have been received/completed and we check with the other crewmember or crewmembers that they are done with cabin power. From here one of us typically runs the securing checklist and shuts down the APU. But we aren't done yet. Our bags get unloaded at this point and we build our 'pile'. All external panels are locked. A thorough post flight walk-around is completed, typically by both of us. Covers are put on all 3 pitots, both ice detectors, the AOA cone and both AOA vanes. Both batteries are disconnected. Whichever pilot didn't do the cockpit securing - must 'check switches' to make sure all is where it should be. Now it is finally time to make sure everyone is 'done inside' and the door gets closed/locked - and now - we can walk into the FBO, or to our rental car which has been brought planeside. We check in at the CSR desk regardless - providing contact info, verifying the schedule and services requested. This is a great time to make sure we go over the 'stuff in the fridge, the lav service, hangar arrangements, etc etc'. Only after this is all done do we leave the airport and head to the hotel where the trip PIC does 'the paperwork' which in our operation is electronic and must be submitted in a reasonable amount of time after the flight. At home base our operation has a cleaning service that will take care of many of the above tasks, and since another leg often isn't happening the next day - we're off the airplane pretty quickly. Hope this helps understand some of the things that go into this side of the business. On an international arrival after a long day mid-trip- it wouldn't be uncommon for the crew to take 30-45 minutes to do all of the above correctly.

I don't think I'm going to make it in April Marco.....though I am very close to wrapping things up. Targeting first half of May it looks like now. Right now there is a lot of quality control checks being done. With 3 variants it is quite a lot of flight testing. The last week has been compatiblity work with all the probable hardware configurations and setting up the preferences etc. All the lighting / night lighting is done and the only thing that remains is a punchlist of small items, a few more liveries to do and the last thing will be the sound. This certainly won't drag out, there is nothing else on my plate and this work is all day every day for me until release. -Tom

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

We have been very clear and forthcoming about our lack of updates and the reasonings behind, as well as stating the nature of this 1.3 update, so if you had high hopes, then you simply didn't come across our postings on the nature of the update before it was released...perhaps we should come up with more formal press release mechanism for IXEG....anyhow, whether or not any of us likes the situation or fallout thereof is irrelevant to the time still required to do the work. If given the choice to lament and say, "yea, its lacking, lets just stop working on it, or "keep going", I'll choose the latter, and once chosen, refrain from bitching about the past and keep pressing. I know folks need to vent their frustration, heck I do it all the time, so vent away, but it won't change our development process, only instantiate contention...its a predictable human thing. Re the cargo doors, they were implemented because they're easier and faster to model. You said the IXEG is (was) one of your favorites...this is because we obsess over details that take a long time to develop, and why we have a reputation as one of the most immersive environments ....and I have yet to see cabin doors that are really accurate and detailed as I know they can be, cause the shapes are so darn tough, and we have a few cool ideas we also want to implement that nobody else is doing...again taking time....but IXEG wants to do it right for that immersion factor. I can't do cabin doors and VNAV and holds at the same time, nor pay for a army of folks to do it (who still may not do it right)...so if I take a month to work on vnav and holds, someone will inevitably come back with, "what...you couldn't get the cabin doors done in a month"?" To be fair, we expect huffing and puffing, you sign up for that when you make products for the public.....but we have not abandoned it, despite appearances. We're back and bringing our attention to detail to the very things that made you like it in the first place. You can choose to be happy we're doing that and encourge the efforts, or keep venting. I myself am happy we've landed on the conditions that allow to work on it full time again and finish what we started. My hope is you can find that also. -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

Hello All, This will serve as an official announcement that we have released update version 1.7 for the CL650. All customers who have purchased the CL650 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 CL650 from today forward, your purchased download will already be updated to version 1.7 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 Challenger 650 download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: === Release highlights & New features === Implemented two-pilot shared cockpit Please review the included CL650 Shared Cockpit Quick Start Guide PDF Added support for X-Plane 12 for all platforms VHF COM frequency formats shouldn't allow omitting leading '1' digit You will now need to enter the leading '1' digit in radio frequency entries on the TUNE page. Leaving out the decimal point is still allowed though. DES ADVISORY If the flight plan doesn't contain any suitable descent constraints from which the FMS could anchor a descent, it will no longer give you a "TOD" point. It will instead give you a green "DES" circle on the flight plan, with a green "DES ADVISORY" in the MFD VNAV window. This is just the FMS taking a rough stab at guessing approximately where you should start your descent, so that you end up 1,500 ft AGL at 10nm from the destination airport. It will not: give you a vertical deviation from this path, capture VPATH give you a TOD indication, or aural vertical track alert This is it basically taking a guess, in absence of more accurate data Remove custom atmospheric model on XP12 On X-Plane 12, the custom CL650 atmospheric model has been removed, since X-Plane 12 now implements temperature effects on altimetry natively. Consequently, there is no option to disable temperature effects in X-Plane 12 when flying online anymore. These effects are always on. Be sure to use the latest xPilot betas when flying XP12 on Vatsim to make sure your altimeter is being reported correctly. MIC selector should enable audio even if monitoring pushbutton is deselected Even when you didn't push in the volume control knob on a radio, if your MIC selector is set to that radio, you will still hear the audio. HUD shouldn’t show selected speed in FLC or FPM in VS The HUD FMAs will no longer show the speed target for FLC or the FPM target for VS. The real HUD doesn't show them, so we removed them. Don't show ACT FPLN on EFIS when CDU is on SEC FPLN pages When SEC FPLN, SEC LEGS or any secondary flight plan-related path is displayed on the CDU, the on-side PFD & MFD will show the secondary flight plan on their map displays only. === 3D model fixes & improvements === 3D & texturing: Fixed texture issues on all liveries present with the updated mesh for the ADG door. Made some adjustments to other areas with substance painters new and extra bake maps Fixed gear bay texture issues Nose Gear Bay - Fixed incorrectly mapped object and fixed textures Fixed visible window shade behind wall light mounts Fixed incorrect mapping on DC Power door. Fixed one antenna not joining onto fuselage. Added indicator line to HUD knob. Added bumps to EVS knob. Fixes to LIT texture. Added missing “LIGHTING” text to lower lighting panels Glareshield: Moved object centre to 0, 0, 0 to fix mirrored object that was nudged to the left Cockpit Object: Plugged hole in main entry door manipulator Cockpit Interior: Closed gap behind circuit breakers on left side Shuttle: Low poly version and textures Fixed excessive shine on decals Fixed glareshield artifacts in textures. Increased width of windshield centre pillar. Fixed ATS DISC button parenting problem on left thrust lever New sun visors, textures and new visor animations. Exterior Fuelling Panel - Fixed LITs and test button manipulator. Wing Textures - Fixed ambient occlusion issues under wings Wing Textures - Fixed ambient occlusion issue on fore flaps Fixed weird ambient occlusion on 4 of the flap tracks. === Bugfixes === 3137: Overshoot arrows on secondary flight plans should be drawn blue, not white 3150: ILS approaches with magvar to the west and CF legs have their leg courses incorrectly computed 3183: Editing airframe registration in initial startup screen trips an assertion check for a bad airframe index 3185: Hydraulic actuator drag simulation was buggy, causing pulsing of nose gear door when depressurized and commanded to move 3187: Implement configurable network proxying for users with VPNs 3199: Nose door opening/closing sounds were reversed after nose door hydraulics refactor 3208: Netlink round-trip calculation overflows after 71.5 minutes 2335: VNAV CRUISE LRC is producing bunk speed values 3161: Only generate random MSNs starting at 6050 3209: Add datarefs for reading the current airframe regmark, selcal, MSN and UUID 3211: CTD when activating the approach while already on the approach leg 3216: Add extra assertion information into libswitch 3218: APU hobbs display isn't being synced over to guest 3210: CTD when entering LGKR as departure airport on macOS 3233: APUFAULT panel hobbs counter is incorrectly being reset to 0 when the ECU is depowered 3234: In case Navigraph chart subscription is renewed while MFD charts are displayed, the MFD will crash 3240: Implement fallback FCC VOR, LOC and GS mode reference distances for gain scheduling in case DME hold is set 3253: If libswitch didn't yet record a replay frame at the current time, don't assert fail 3257: Engine thermalization can run away into negative infinity if a non-zero shaft load is used during thermalization 3258: MIC selector should enable audio even if monitoring pushbutton is deselected 3221: Populate more PERF data from SimBrief during FPLN RECALL 3263: Reverse idle shouldn't spool throttle up by 6% 3262: DF leg sequences too early on ILS26 Missed Approach at EIKY 3222: Short circuit DC BUS 2 via failures menu CTDs 3264: FPLN RECALL is using too tight timeout for simbrief XML fetch 3265: Add options to customize payload, fuel and avionics in non-persistent mode 3267: CPDLC assertion logger isn't being properly set up 3268: libcpdlc crashes if multiple ATC messages pulled in one fetch contain a END SERVICE followed by more invalid messages 3269: Flap motor 2 failure is mislabeled as "overheat" 3270: Weird phrasing for collector tank in fuel system visualizer tooltip 3271: FMS should auto-switch to true heading when magnetic heading from IRSes becomes unavailable 3272: TAWS terrain rendering can induce periodic sim stutter when rendering large numbers of tiles are being drawn 3273: Automatic F/O volume isn't being restore from saved user settings 3274: Flight plan ETD edit wasn't being properly finalized with fmc_fpl_done_edit 3275: Typo in failure manager spelling for "cockpit floor" 3276: Use armed/active checkboxes in failure manager as logical AND with the name search, not logical OR 3278: ALT_DESC_AT_GS_FAF is using the wrong altitude field for drawing the constraint on the MFD 3279: Don't allow APU ECU to introduce fuel before at least 13% NG is achieved 3280: Inserting mod from a CPDLC UM80 message while in the air causes a crash 3293: Switch to double-precision floating point math for XP12 compatibiity 3294: XP12 requires adjustment to gear leg length to make the airplane look correct 3295: Implement XP12 rain effect 3149: TO waypoint should blink on PPOS map when we're getting close to sequencing 3303: XP12 fuselage drag is too high 3305: DataRefTool seems to attempt to read CL650/glass/heat_on array with bad length and crashes 3304: HUD shouldn’t show selected speed in FLC or FPM in VS 3306: 1/2BNK and DR lettering on HUD must use the same large font size as the active lateral mode FMA 3308: HUD glass could use a bit of darkening on XP12 3319: Add uncommanded flap motion failures 3281: Takeoff Reference Indicator Line should appear at rotation not 50 ft 3312: Flap limiting speed should be derived from handle position, not actual flap position 3322: Entering random stuff into FMS STATUS ACTIVE DATA BASE line when no SEC DATA BASE is installed crashes 3314: XP12 cloud layers can have equal base & tops, leading to an iter_fract assertion failure 3324: Implement APPR FOR REF ONLY FMS message 3329: Remove custom atmospheric model on XP12 3330: Retune X-Plane 12 drag model 3325: PATH mode shouldn't be available outside of FMS NAV SRC 3327: Spurious CHK SBAS SVC PVRDR message due to X-Plane nav data format change 3334: Remove altimetry temperature compensation UI elements from X-Plane 12 build 3335: Use global X-Plane 12 airspace files in IFIS airspace when available 3336: Failed TRUs shouldn't be colored on the Electrical Network screen as an active source anymore 3337: CTD due to assertion idx < fpl_get_num_rt_lines(fpl) failed in insert_via 3339: Clamp stall IAS computation at 40 knots 3310: Don't show ACT FPLN on EFIS when CDU is on SEC FPLN pages 3341: Clamp FSCU computation outputs 3338: Make ACARS network provider configurable per airframe 3342: APU negative G fuel path misaccounts fuel feeding when left collector is empty 3344: Avoid showing ATS N1 TO together with FAIL if reloading into an avionics-on state 3345: FMS-FMS N1 DISAGREE message should only show on active FMCs and cross-compare between active FMCs 3346: MACH failbox isn't showing up properly when Mach data from ADC isn't available 3348: Lock out GPS position when traveling significantly over M1.0 3350: Don't cross-compare vspeeds to standby FMS 3355: Inserting a direct-to doesn't perform proper flight plan post-processing 3356: Direct-to should construct a minimum leg length of 5 miles 3359: Current-leg TTG algorithm should simply use linear distance to the terminating fix, instead of along-track distance 3360: Implement special FAF sequencing criteria 3361: Implement UNABLE RNP FAF MAP message 3357: Approaches should draw a 15 NM line from the runway along the runway extended centerline 3365: Pushing TOGA should clear VNAV submode 3367: Runway waypoint should flash when we're about to sequence through them OpenGPWS#4: X-Plane 12 includes 1-bit earth orbit normal maps, generating nuisance warnings 3368: ALTS should recapture immediately when altitude pre-select hasn't been moved and a vertical mode is selected 3363: Popups don't match cockpit brightness in XP12 3362: Auto brightness in XP12 for iPad at night 3354: CTD when selecting option 76 TAWS 3373: Implement automatic cruise altitude determination from ALT SEL value 3144: Activating DME HOLD should force nav tuning mode to MAN and lock out AUTO 3372: X-Plane 12 apt.dat introduced a change to row code 1302 country to include the 3-letter country code in the data 3375: MFD TAKEOFF & APPROACH REFERENCE data window should automatically select based on on-ground/in-air state 3376: HUD should show AT FAIL instead of the second MSD line when MSD is showing a failure flag 3379: Don't block deicing when there's ice on the wings, regardless of outside temperature 3380: NAV CONTROL page didn't check for DME hold before toggling auto tuning 3382: FMC on-ground state should be toggled by WoW first, airspeed second 3383: Thrust modes APR, CLB, CRZ and MCT shouldn't be selectable while on the ground 3385: Refactor FMC key handling to only emit KEY NOT ACTIVE when there's an explicit reason for it 3384: Standby FMC determination doesn't work correctly when nav source isn't any FMS 3387: Cabin display system needs to be using buses LB/RB-IOC-7 not LB/RB-IOC-1 3381: Radio CONTROL toggles should be cyan, not green 3369: Nav radios start up in manual tuning regardless of previous state 3389: NRST APTS should be drawn in magenta, not cyan 3392: PPOS map should draw line of FROM leg, not just its terminator symbol 3391: Refactor FPL drawing for proper vertical stacking of elements and runway extended centerline 3395: Leg constraint type auto-picker algorithm needs to be changed and user prompting implemented 3394: Refactor CL650 menu to use bindable commands for popup windows, instead of custom menu handling 3398: Vertical mode should stay in TO after LNAV becomes active 3399: SELCAL gets stuck in cleared state once xpilot or ivao keyline-out is triggered once 3378: RA appears on HUD when on ground 3400: FPL shouldn't draw preceding leg if it was constructed 3402: Coded turn direction can get ignored when doing nearly a 180 degree turnaround and crosswind present 3401: FPL drawing can show turnaround flag in blue instead of the correct color 3403: Pushing AP ENG button when AP is on is causing a disengage and immediate reengage of the AP 3406: CMU DSP and roaming configuration is incorrectly being applied to the currently loaded airframe 3408: RNAV 24 at EDNY is causing the FMC to not transition into the LPV APPR mode correctly 3397: APTS map symbols should display "all" airports in range 3404: NEAREST APTS map symbols should be limited to 5 closest airports 3409: DIRECT-TO NEAREST AIRPORTS page needs minor layout tweaks 3410: Change byte-array word layout can cause crash when reloading an old state file with the old word layout 3411: NRST APTS must change DEST airport and for runways insert a RWY approach with a 5 mile extension 3405: Dual-generator loss causes monitored AP disconnect because the SSM momentarily isn't receiving power 3412: Passing the last waypoint on the flightplan doesn't clear the TTG value and the TO waypoint continues flashing 3413: The TO waypoint of a MOD FPLN shouldn't flash during sequencing 3418: Default state for APTS map symbols should be “OFF” 3415: DIRECT TO NEAREST AIRPORTS page title should be moved one column to the right 3148: 8.33 kHz channels should not require trailing zero to be entered into COM fields 3419: Context-sensitive ACT/SEC FPLN selection isn't correctly following the relevancy of the currently displayed FMS page 3420: PPOS map should show SEC FPLN 3421: MFD window isn't showing decimals when distances are <100NM 3422: PPOS wheel 5-degree increment ticks need to be shorter by 2 pixels 3416: Adding an origin to flight plan causes a duplicate entry on DIRECT TO NEAREST AIRPORTS page 3428: Refactor MFD ADV functionality to more closely follow real avionics 3430: Tech specs IRS gyro random noise walk seems overestimated compared to real world IRS performance 3432: Stock training scenarios are incorrectly using absolute altitude instead of height above ground for triggers 3414: DIRECT-TO NEAREST AIRPORTS's MIN RWY doesn't reset to default on FMS cold start 3424: Vertical constraints above transition should show as FLxxx on map 3434: Fallback LOC distance estimation isn't using RA and is set too low, resulting in lethargic steering 3283: PPOS PFD should be replaced by CDI when using VOR/LOC nav source 3437: CTD due to assertion "item_ref != NULL" when clicking the parent of any submenu in the Challenger menu 3440: LNAV turn prediction at high altitude ignores half-bank limits 3439: When in a hold, a coded VNAV speed constraint should be applied at all times, not just when inbound to the hold fix 3441: Implement UNABLE FPLN ALT cautions and VNAV constraint reachability checks 3438: RWY UPDATE should be present on LEGS page when on the ground 3442: DESCENT INFO page needs multiple formatting fixes since manual references were inaccurate 3443: MFD VNAV window should show amber constraints when UNABLE FPLN ALT is shown for the associated leg 3318: Crash when LWR MENU is showing MAP SYMBOLS and LWR FRMT is cycled to TCAS map while we are shared cockpit host 3152: Failures.txt: ATS servo description incorrect 3151: VFLC doesn't auto-initiate at BOC in missed approach when no more at-or-below constraints exist 3446: Reduce the missed approach target height to 1500ft and refine the missed approach leg search algorithm 3143: Inputing DELETE to COM/PRESET LSKs on TUNE page should give INVALID CHANNEL 3450: V-speeds deselected on takeoff 3458: VNAV path constructed to be too shallow on long flight plans 3460: Approach is showing RWY vertical constraint for the missed approach start leg 3454: MFD quick access memories should store map symbol selections 3452: WINDS ALOFT VIEW page right-hand lines have their caret pointing to the wrong side 3451: RA on HUD should be in fixed position when on ground 3461: HUD should show TCAS OFF 3463: EGKK DISI1G->ILS26L sequence causes spurious CRS REVERS IN FPLN message 3284: Missing GEAR DISAGREE CAS caution when trying to retract the gear with hydraulic system 3 leak 3464: Dropping a new leg onto a procedure with an IF should implicitly connect to the procedure and convert the IF->TF 3465: Performing a leg shorten to the initial fix of a (VECTORS) transition approach doesn't clear the direct-to state of the IAF 3466: Add Marshall Islands as well as Midway and Wake Island to list of territories using gallons as fuel quantities 3468: Use-after-free bug causes crash when inserting a leg before a discontinuity 3469: RWY UPDATE should be shown even when the FPLN only contains the origin runway and nothing else 3470: Single press of DEP/ARR should show DEPARTURE page when on the ground, regardless if DEST is entered 3474: GCU 2 is miswired to use GEN 1 current measurement 3476: Implement missing NO VPATH-PILOT CMD system 3478: Intercept fly-by check shouldn't produce UNABLE TO SEQ FPLN message 3480: APPR FOR REF ONLY shouldn't be shown when flying the missed approach 3481: LSK 6R on LEG DATA should go to LEG WIND, not LEGS 3475: GCU tie bus overcurrent protection is broken 3477: V-MDA approaches should stop constructing VPATH after FAF and AFCS should drop to VPTCH 3483: Need support for detecting XP AIRAC cycle on XP12 versions of navdata 3486: Offset leg segments linger behind on FROM leg even after OFFSET is changed or terminated 3487: LEGS page should show (DIR) for DF legs even when not encoding any mandatory turn direction 3491: Per-leg VPA entry should only be applied to that leg and not uptrack ones 3492: Uptrack coded leg VPA should be ignored when determining VPA limits for the current leg 3498: Attempting TOC construction on V-MDA final leg crashes 3499: FAF station passage altitude criterion was missing 3000 ft buffer 3500: Intercept sequencing can fail if the intercept overshoots the target leg before meeting track alignment criterion 3490: LP approaches shouldn't be flown angular since the avionics doesn't support them and they're marked as RNP in ARR DATA 3505: NO VPATH-VECTORS doesn't get cleared once the vectoring leg is passed 3506: VNAV path constructor needs to consider holds a discontinuity 3512: DC GPU cannot be manipulated using hand signals menu or removed when FBO SVC is in enroute state 3508: Implement missing transponder CAS messages 3516: Transponder failures missing in failure manager under 23-Comm 3517: Amber DC ESS BUS message shouldn't show on the ground 3518: Add the white DATALINK FAIL CAS message 3519: OUTBD and INBD BRAKE PRESS CAS shouldn't appear when DC BUS 2 is unpowered 3520: MFD radio control block needs to show cached tuning data in amber when radios are unavailable 3522: HF radio channel NVRAM saving and loading was completely broken 3521: CDU TUNE page data shouldn't be removed when radios become unavailable, only change color to amber 3523: XPDR 2 failure was actually failing XPDR 1 3524: NAV radio needs an outright failure that will simply make it go amber on the tuning panels 3525: When DME radio is failed, show its frequency in small amber font even when last state was in hold 3526: Normalize heading datarefs on XP12 on the front-end to work around X-Plane 12 giving negative heading values 3528: FANS UM80 shouldn't clear out PERF INIT data 3527: FANS direct-to doesn't arm the direct-to auto-update system to recompute the turn intercept at EXEC 3529: Refactor PPOS hold recompute algorithm to remove the need for explicit arming 3530: Refactor VNAV constraint determination code to get rid of broken constraint corner cases 3531: Long press on oil servicing panel test button should turn FULL lights off while held down for more than 2 seconds 3532: Regression - gear animations broken in replay 3533: FSCU channel 2 data wasn't being routed to the EFIS and FDCU 3514: Implement custom Rosen sunvisor animations and interaction 3472: Landing, taxi, strobe and nav light cores, flares and LIT textures appear too dim in XP12 3540: Don't perform UNABLE FPLN ALT checks on vectoring legs 3534: Refactor vertical direct-to functionality to match the real avionics 3539: HUD should show RNP value next to ldev scale just like the PFD 3509: Rename CAS message: DATALINK to DATALINK ACARS 3425: CTD due to EXCEPTION_ACCESS_VIOLATION in chart_download_multi 3542: FSU isn't correctly using the user's proxy settings for chart downloads 3543: Don't allow GP without VNAV being active 3544: Drop PATH and GP if VNAV is removed 3286: ATS shouldn't engage if the throttles are set above the current N1 limit 3545: TCAS is incorrectly entering SL4 due to slightly negative RA reading 3546: Inhibit beacon flashing animation when view is inside cabin to avoid beacon light from cutting through fuselage in XP12 3548: Add native ARM64 build to macOS port 3554: Implement retrieval of the alternate airport from simbrief flight plans during FPLN RECALL 3555: Refactor autopilot "holding" CAS messages to make it possible to detect persistent user inputs 3549: Magenta altitude constraint display on PFD & HUD should show nearest constraint, not the path BOD 2653: ATS indicator lights not responding correctly to bright/dim switch. 3558: Implement workaround for XP12 bug where radalt will fail if the terrain height probe is at >0 elevation 3562: FD 1/2 FAIL CAS messages weren't triggering on FCC failure 3561: XP11 model is missing HUD glass 3564: Refine in-range checklist tooltip and procedure to clarify that the TGT limit needs to be activated, not just set 3565: Add a supplement to CL650 Operations Reference describing how to conduct steep approaches 3566: Make deicing fluid color more vivid to be closer to reality 3567: Don't perform UNABLE FPLN ALT check on final approach segment 568: At-or-below climb constraint in missed approach can lead to spurious UNABLE FPLN ALT due to path construction quantization 3569: Brake energy MTOW limit table is incorrectly truncated at -25C 3570: Descent vpath construction climbs too high when there's a hold in the arrival or approach 3572: AFCS 1/2 INOP and FD 1/2 FAIL CAS messages weren't implemented properly 3560: Attempting to enter OFFSET when the FROM leg is preceded by a discontinuity crashes 3574: L/R FUEL LO TEMP CAS messages should only come on in the air 3429: (Re-)Connecting guest to shared cockpit overrides radio freqs including squawk 3575: Remove superfluous wind_turbulence_percent dataref lookup to silence XP12 warnings about is deprecation 3576: DIFF PRESS CAS message should trigger at 9.07 PSID, not 9.0 PSID 3578: DCU CAS triggers for ATA-27 should use canned bus power check macros 3579: Refine DCU CAS triggers for ATA-28 3580: Refine DCU CAS triggers for ATA-29 3581: Window heat test implementation was being too smart and wouldn't fail when tested on LOW or in hot weather 3582: Refine DCU CAS triggers for ATA-30 3586: Netlink keeps counting TCP link RTT up 3587: Refine A/SKID CAS message triggers to trip in the air, even when parking brake is set 3588: IRS POWER FAULT CAS messages need to trigger even when primary power input fails 3589: L|R FUEL LO PRESS cAS should be triggerable on the ground after all 3590: Add binds to PilotEdge, xPilot and Ivao client network transmit commands to operate the yoke-mounted PTT R/T switch 3591: Deicer should respond even if ACP receive button isn't pushed, if the mic position is matched to the radio on the ACP 3593: Race condition in replay worker accessing non-lock-protected global variable, resulting in potential crash during replay 3594: When current leg is a PPOS hold or direct-to, don't rebuild the leg after the initial edit is completed 3597: TAKEOFF and APPROACH REF entries on standby FMS should yield KEY NOT ACTIVE 3596: Do not recompute VSPDs after they have been sent 3598: Add simulation of pitot probe turbulence near the ground 3595: OpenWXR shouldn't attempt to look up temperature_tropo_c in XP12 3602: Active fpln offset should draw as dashed line on map (same as mod fpln) 3603: Offset entry field should support more formats as per manual 3604: Offset entry text should always show one decimal place 3605: OFFSET WILL END message shown on non-nav source CDU(s) 3606: OFFSET TERMINATED should not show when offset manually cancelled 3608: Offset should be removed from SEC FPLN when an active-sec swap is performed 3611: OFFSET CDU message flag should be able to coexist with MSG line 3613: DCU dual power supply implementation was broken 3614: DC ESS BUS power line "hockey stick" from APU BATT DIR BUS isn't shown correctly due to bad DC ESS SS CTCR state acquisition 3496: Stock failure scenario 1 - triggers are incorrect 3497: Stock failure scenario 5 - incorrect event triggers 3615: Stock failure scenario 2 - incorrect event triggers 3616: Stock failure scenario 4 - incorrect event triggers Fixed texturing issues on wing tips and strobe light mount 3617: Disable custom ground effect tweaks on XP12 3618: Refactor aileron PCU jam indication on the MFD FLT synoptic to avoid spurious jam indications 3619: Shorten ELEVATOR SPLIT trip delay to 1 second 3620: libacfutils - Don't stop reading chart PDF to PNG data on non-Windows when partial read is done. 3627: Do not generate UNABLE FPLN ALT on altitude-terminated legs 3625: HA legs should immediately sequence through if they become active and the altitude constraint is met 3629: FMS SEC FPLN data routing rework broke pause-at-TOD 3631: AFCS 2 pops CB1-M2 when FCC 1B is attempting to actively steer 3632: Negative d_alt in VOR slant angle computation can result in arithmetic error in distance computation 3633: Toggling FDs when very near the capture altitude can crash due to timing issue in FD pitch target not being initialized yet 3634: PI legs start course is computed incorrectly, leading to VNAV constraint picking issues 3635: Descent VNAV path shouldn't be capped by descent legs that were duplicated due to reselecting a STAR or IAP 3636: Allow PATH capture from the VNAV CLB phase 3637: Remove C-chord and flashing altitude constraint when going to level at it - doesn't happen in the real plane 3638: Gear horn trigger conditions when ROD: any should only sound when VS<0 fpm 3639: AIRAC cycle validity end date should show last valid day, not first invalid day 3081: DES ADVISORY missing from VNAV window and DES point from MFD PPOS MAP 3641: Lateral path constructor wasn't applying implict overfly rule to CD, CR, FD, VD and VR legs 3643: Deleting the leg preceding a (VECT) leg should generate a non-clearable discontinuity 3644: fpl_ser has superfluous assertion check which can crash if the leg preceding a TOD/DES has no vnav crossing alt 3107: MFD navigation data progress window should not show (DIR) as last waypoint passed 3646: Add data mode toggle to COM CONTROL page for data-enabled COM radios 3647: Oat on thrust limit page should change to n1 sat in air 3649: Shorten post-takeoff measured OAT switch delay from 45 seconds to 25 seconds 3648: CDU tune and control pages should show com frequencies to 1khz precision regardless of tuning mode 3650: DES ADVISORY doesn't change to TOD when the final leg of a flight plan is not a MAP but has a hard constraint suitable for VPATH 3651: VNAV direct-to doesn't correctly assign a DES constraint class if the target leg doesn't have a constraint class already 3652: FCC should allow VPATH capture in any lateral mode not just NAV 3653: LPV GP shouldn't be being blended into baro VPATH if we're coming in on a mode other than VPATH 3654: VHF COM frequency formats shouldn't allow omitting leading '1' digit 3658: Description code 2 "B" wasn't being checked everywhere for fly-over conditions 3659: Added new anti-icing procedures on descent to the operations reference manual 3661: Allow up to 45 degree angle-of-divergence on hold entries to better fit within the allotted hold size 3662: Zero-length hold leg crashes when attempting to fly the outbound leg 3664: Add "CLEARED TO" variant of ACARS PDCs from Hoppie 3669: Flaps underdriven to slight negative angles causes relative AoA computation to use max flaps setting notch, not min 3675: Increase assumed VOR angular standard deviation in position sensor fusion to 1.4 deg to match RTCA DO-180A section 1.4.1.1 3676: Reduce DME FOM to 0.1NM and maximum distances to 140NM to comply with RTCA DO-236C appendix C-3 3681: Do not auto-connect procedures even with matching waypoints if they have non-matching constraints 3679: Do not round speed constraint entries to the nearest 5 knots 3683: Do not perform turn anticipation onto CF legs with course reversal to avoid invalid early sequencing 3684: Clamp turn midpoint angle determination to a maximum of 160 degrees to avoid incorrect triggering on course reversals 3687: Retune autopilot flap deployment pitch preload to better match attitude changes in Ops reference 3688: Update CL650 Operations Reference manual to latest state 3690: Release ADG uplock even when handle is pulled only 3/4 of the way 3694: ATS engage lamps appear blown out when tested at night even when set to DIM 3678: Editing altitude constraints on final approach legs should be allowed 3702: Holds need to use a manually entered leg constraint as the speed target for sizing if one is present 3703: FCC should give the active vertical mode a brief grace period of 0.25s to regain valid input data before dropping the mode 3704: Disarm APR mode when a thrust mode other than TO or FLX is selected 3709: Coded turn completion needs a wider angle to allow for steep intercept of the turn target leg 3706: ISI spill light isn't being updated when the ISI is off 3715: Changing NAV freq via CCP flip-flop doesn't erase the CDU tune-by-ID Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.

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