Leaderboard

Hello All, This will serve as a formal forum announcement that we have released the version 1.32 update for the Take Command! IXEG 737 Classic. All customers who have purchased the IXEG 737 Classic 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 IXEG 737 Classic from today forward, your purchased download will already be updated to version 1.32 for you. It is for X-Plane 11. If you use X-Plane 10, you can still install an old version of the aircraft from the installer, but this update does not otherwise apply to you. Caution: This update is optimized for XP11.41 and newer only! If you run it any previous X-Plane version it will still work, but the aerodynamic model gets changed and will not fly "by the numbers" anymore! Install at your own risk (make a backup of the aircraft folder first, especially if you run XP10)! 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 IXEG 737 Classic download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: Bug fixes: Fixed gizmo crash when entering a waypoint name that contains the letter N or S followed by a letter, W or E downstream. Fixed mousewheel scroll direction for standby attitude indicator level symbol (and increased speed). Fixed coroute loading/saving crashing if user tries to save coroute with pilot created waypoints or partially wrong names. Improvements: FMS: Complete overhaul of departure and arrival procedure selection code, with improved stability and transition selections/loading. FMS: Radial / Circle intersections on the Fix page can now be selected and copied back to the LEGS page as a waypoint. FMS: Pilot created PBD (Place-Bearing_Distance) and LL waypoint types avail. (Examples: JKF350/25, JFK345/2, N45W33, N4533.2W3321.6). FMS: Pilot created waypoints and the loaded route runway can now be copied from the LEGS page to the FIX page. Added coroute folder with sample *.fpl route. Added VR improvement for IRS display mode selector. Increased volume for navaid ident and marker beacons. Prevented cockpit controls from being manipulated through the IXEG pop-out menues. More reliable sequencing of waypoints when flying route in LNAV. Additions: Added custom particle system. As always, thanks for being a customer with X-Aviation. We appreciate your feedback and support! Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.

Although the ‘Gooney Bird’ is not the most complex aircraft in existence, the systems simulation has its own, unique challenges. X-Plane offers a generic way to simulate systems, so most of the times, you have to expand or adapt with the implementation of extra logic(s) via the use of plugins. The developer adds complexity to systems, which most of the times it is about newer automations that does not exist in X-Plane “default logic”. As you might imagined already, here the situation is almost the opposite. The added complexity has as target to reduce automation! Aircrafts from that era, do not enjoy automations we take them for granted in the recent years. One example is the landing gear extension/retraction operation. In a normal aircraft, you manipulate a lever, and in the background, electromechanical components, do the job of extending or retracting the landing gear. In the DC-3, you actually operate the valve that sends hydraulic fluid to the one or the other side of the hydraulic cylinder to retract or extend the landing gear, leaving aside (for now, we will talk about it in the future) that you have to manipulate up to 3 “things” to complete the operation! This leads us to the need to override X-Plane’s behavior with our custom one. Building the proper logic requires knowledge not only of how the systems are operating, but also intricate details, beyond of what is written in the manuals. We are very honored to enjoy the help and advises from a guy that both flew and maintained DC-3s and C-47s! His insights drives us to add a huge amount of extra details in the systems simulation side, way more that we had originally planed. So if you have the question “why the update takes so long?”, now you have your answer. Because examples help understanding, here is another one that might shed light upon the level of detail we are putting in, something we’ve already shared in our discord channel. Those old aircrafts are equipped with some old generators that must come up to temperature to provide the maximum amount of voltage they can. Taking into account various factors (environmental, time in operation, etc) we calculate another factor that plays role in the generator output, and if will connect or not to the main bus (despite if you have put the switch to ON position), as function of the voltage regulator, which we also simulate. That’s all for the introduction of the DC-3 systems. In the next updates we will look closely every system and its operation. While I am trying to post updates as dense as possible, sometimes you have to progress the work first enough, and then talk! Stay safe and enjoy flight simming!

We have not updated the paintkit yet - so if we leave the "very shiny" inlet in the download, everyone (all liveries) have to fly with the very shiny inlet. So we change it back to a moderately shiny one. Later every painter will be able to select the "shinyness" (if I understand that correctly). Cheers, Jan

Patrick, The most typical reason we'd see this error is because the customer is trying to use an old installer. You need to make sure you've downloaded the new 1.32 installer and are using it.

Updated September 2023, Version 1.5 Hi everyone. While it seems to be the economically "smart" thing to do to NOT talk about the shortcomings of your product (and then sometimes to just ignore the complaints after you cash in the money), we are trying to run things a bit differently here at IXEG. I would therefore like to share a list of things that will NOT be in version 1.5, and also give a little background of why, and wether we are planning to add it later. I will try to make this list as encompassing as possible, if I forget something, please don´t sue me! I will add/remove from this list as warranted. Aircraft visual 3D model Ancilliary vehicles (catering, fuel truck, loading crew) - this is now accomplished by using the XP11 native ground vehicles, the docking locations for those are correctly added in planemaker. Cockpit keypad entry mechanism Omitted due to security reasons. Deployable emergency slides.Omitted due to time constraints, planning to add later. Deploying oxygen masks. Omitted due to time constraints, planning to add later. Sound effects/visual model for passengers and their (assumed) behaviour. Too complex a simulation off it´s own, most likely won´t be added for fear of having something repetitive or cheesy. Cabin crew voice interaction. You can communicate via menues that are invoked by pressing the cabin call button, though. FMS Pilot entered HOLDS. While we have database-inherent holds (like at the end of a missed approach), we won´t feature the HOLD page where you could enter all sorts of HOLDS. Omitted due to time constraints, definitely planning to add later. RTA feature. Omitted due to time constraints, planning to add later, but low priority. OFFSET feature. Omitted due to time constraints,planning to add later, but low priority. ABEAM points (after shortcutting route, for example). Omitted due to time constraints, definitely planning to add later. You CAN enter stuff in the FIX page, and "find" a PBD point that way (enter a fix, enter a radial and a distance to see the green radial and distance-circle) Entering descent wind forecast (normal wind entry on PERF INIT page possible). Display of "RTE DATA" on EHSI/map, i.e. showing ETA and restrictions next to waypoint. You can see that on the LEGS page, for now. Omitted due to time constraints, definitely planning to add later. Automatic entry of performance data (weight, etc.). We might include that for the "ready to fly" scenario, not decided yet. For now it must be entered manually, if FMS performance assistance is desired (not mandatory). Fully working PROGRESS page - we started to code it, but much of the things shown are placeholders. We expect this to be one of the first things we will add soon after release. Full VNAV functionality for descents with speed and/or altitude restrictions. The FMS gets confused by changing the cruising altitude while enroute and multiple descent restrictions and restrictions of a certain type. Basic unrestricted descents work, though. GUI Dedicated flight-planning software. We feel that this is not necessarily within the scope of our add-on. We model the plane like you get it after delivery from Seattle (+ free lifetime fuel!). There are plenty of flight-planning solutions out there, we include a basic "ballpark" fuel calculator. Complex and visually appealing load+trim software. We feel that clicking empty seats to fill them and pulling sliders to load cargo is fun for a few times - but really all you get is a weight and a center of gravity. And you might just as well set those directly in the gui. We have simple sliders and click-buttons for that (or you can use the default X-Plane menus). No way to output any CDU, EADI or EHSI onto an external device like iPad or such. Would like to have that (especially for cockpit builders), though. Exception: it is possible to use AirFMC, available at the Apple App Store. No pop-out 2D displays of flight instruments/CDU/EFIS to make reading or entering stuff easier, no hiding of yoke to not obscure view. We feel that the ergonomics (or lack of) an airliner cockpit is an important part of the experience, so we don´t want to "help" too much. We have "preview pop-ups" of the EHSI when making changes on the EFIS control panel to help you see if you have the right setup. Other systems Wxr radar returns can only be displayed on the left EHSI/map. Omitted due to time constraints, definitely planning to add later. Terrain colour display can only be shown on the left EHSI(map. Omitted due to time constraints, definitely planning to add later. Operating circuit breaker (CB). We decided that most CBs will never be moved in normal operation. We will add moveable CBs with the yellow collar later (to be used in abnormal situations), and possibly some others as well (standby altimeter vibrator!). Automatic startup/shutdown "macros". Won´t add that. This plane is about realistic operation (it´s not hard!). If not desired, just select "ready to fly" or "turnaround-state". IRS using "false" position. It is not possible to deliberately enter a "false" position and have the IRS align to that. The entry will be rejected unless reasonably close to the real position. In the real plane the GPS would also "correct" your wrong entry (if close enough) or warn you. A position far from the old "shutdown" position would be rejected once. A wrong latitude would be detected during the alignment process...It would be a lot of coding effort to maintain a "wrong" position with the corresponding effects (map-shift, etc.) A dedicated way to fly the same plane together in multiplayer. Note that SmartCopilot has made great progress in making our plane flyable with a crew of 2, and while not perfect yet, it is working very well, going by user reports: http://forums.x-pilot.com/forums/topic/9714-smartcopilot-first-attempt/?page=1 Volume control for radios/navaid ident checking. We have implemented a better volume (more loud), but it can not be adjusted yet. We are trying to be as upfront about the shortcomings of our model as possible. I have myself bought many aircraft for flight-simulations boasting great things, only to be disappointed. I want to avoid that for everyone, so if you find a "must have" feature on this list, I encourage you to hold off on purchase until we added your feature in a later patch. I could make a feature list of things we have that would take you hours to read, but instead you can assume that our plane can do everything that the real one does, except for the things noted above. Cheers, Jan

thank you veeeeeeery much.my dear Mr.great job。and another： 1，"turns right outboard landing light on" not working 2,i wish that altitude axis can respect hold command，if i Fast rotation the hardwere knob to change the ap altitude，these some bug in led display。 3，i wish add a spring switch to turn all landing lights on，like the true,a spring board switch to turn them on.yes 4.....if i check out some problem,i will be back

Thanks for reply. Oddly enough problem disappeared after PC restart! Go figure!

I downloaded the installer from my X-Aviation account. It uninstalled the installed version and installed version 1.32.

Thx Jan I will try again. It might be my internet.

I think building a cockpit would be a great hobby - I have two left hands (with all thumbs), so it isn´t for me... I think, though (apart from the fun of building it) that the future is in VR. I would just build a seat and flightcontrols mimicking the real ones (so you can grab them by reaching for them in VR). Probably a lot cheaper than building the cockpit, a LOT less trouble (getting everything to work) and you also get the benefit of being able to really lean and look out the window like you can in a real airplane (not with just a few screens giving you all sorts of trouble, too). So yeah, my personal opinion - the days of home-cockpit building are counted. At least as far as trying to create a realistic flying experience. It can still be fun if you like tinkering. Cheers, Jan

Dozo, thx for reply Connected are... Saitek Pedals Saitek Yoke Saitek Throttle Quadrant You've put me on the right track. Thank you. In fact, one axis of the Saitek Throttle Quadrant was configured for flaps. For whatever reason. ;-) All is well again! Have a nice day!

Jason if you continue to spam the forums with this issue you will be banned. This is your final warning. I told you in a thread that no one on the forum can help with this. I told you again that no one on the forum can help when you private messaged me. Now this thread. Final. Warning.

@Litjan & everyone, please keep looking. Today with v1.32 I had the same issue with the delayed avionics fan after hitting the APU GEN switches, only this time it never came on despite waiting 3+ minutes. I ended up applying the turn-around state and the fans sounded normal, then on the next cold n dark it worked ok. However the fan delay issue seems to happen every 3 or so flights.

There are already datarefs on the aircraft for the volume of the radios (default X-Plane). You can access them with dataref editor, so I think that should be possible. We will make the little knobs that "turn" for volume also affect that dataref in a future update. Cheers, Jan

In a future update can you add datarefs on the aircraft to make it compatible with xPilot? On X-Pilot (VATSIM) you can manage the volume of COM1 and COM2 on 3d cockpit radios, it is a very usefull feature.

Whatever it did by switching it seemed to have worked - every subsequent flight has been accurate to what I'm seeing in Active Sky and satellite. Maximum accuracy isn't my primary concern, I simply wanted to enjoy one of the few CAVOK days in Northeastern Oregon. Thanks for making an awesome product - it's running so well in Vulkan, even under the crazy overcast conditions the Pacific Northwest can whip up. Enjoy the rest of your weekend.

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