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

I absolutely understand the anticipation you must be feeling as you wait for this release! It's a thrilling time for all of us, and I can assure you that our team is diligently working away to bring it to you. We're following the latest update from Tom just last week, so everything is still on track. Please keep an eye on our announcements, and we'll make sure to keep you informed as soon as there's news to share. Your patience and excitement mean a lot to us, and we're eager to deliver something fantastic for you!

slow but steady on the lighting...this is cabin emergency lighting. XP12 has really opened up new opportunities with its lighting engine, though a learning process. Trying to balance lighting effects for a natural look across multiple x-plane 3D objects with multiple light sources is an exercise is patience for sure, but as a simmer since 1981, I can't say I mind. It fascinates me how far these graphics have evolved. -tkyler