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.

Jumped right in after the update, on my route ENBR-EKCH right now. Many thanks for the update. Very well appreciated, since she was collecting dust bc of the (noe hopefully fixed) FMS issues. Grüße aus dem Taubertal Oliver

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

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!

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!

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

Thanks Guys! Was having an issue entering a route from KORD to KPIT, which I have flown many times. Was getting a crash entering waypoint ANEWA into the box, couldn't figure it out even after reading the causes here in the forums. But it's working well now! Good Job!!

Always "on", please. (There is not a huge difference, but you can notice the perf numbers being slightly off if you don´t enable it). Once 11.50 is out of beta we will "force" the EFM to always on in our .acf file. Viele Grüße nach Kölle, Jan

Just run the installer, it will overwrite the necessary files! Cheers, Jan

Thats the spirit!

Thanks guys, updating as I type this! Also trying the Gizmo beta version now. Using XP11.50 beta 14, LiveTraffic beta 2.06, Gizmo beta... What could possibly go wrong?!

Thanks for the hard work guys.

Hmm, ok - may be an initialization thing...maybe its a five-minute fix, I can always slip these on Tom´s list if he doesn´t watch. Just gotta be careful, last time I did this we ended up with 3 weeks of rewriting the FMS procedure loader!

Yes, cargo doesn´t complain...but there is still a lot that can go wrong, especially when carrying lifestock... Cheers, Jan

Thanks! I'll be watching to see if you come up with an answer. X-Enviro is OK but I really like SkyMaxx better. BTW, I tried the latest SkyMaxx (4.9.5) and it does the same thing... Russ

Hi Sebastian, I think X-Plane captures the high-altitude aspect fairly well. It does not calculate the changing of true altitude with different temperatures, that is probably the biggest thing missing in mountain flying (remember the old saying "In the winter the mountains are higher"). The main aspects of high altitude operations is higher true airspeed (needs longer runways and wider turn radii in flight), and also less engine thrust and higher N1s than at "lower" airports. This is both modeled well. The autopilots landing performance is tuned to sea-level airports and while it will land "safely" at higher altitudes, it may not land gracefully. Of course our autoland code is not as refined as the one in the real aircraft, but I can tell you that the real airplane doesn´t land beautifully with autoland quite often, either (both Airbus and Boeing). Its not like some super-pilot is kissing it at 1000 feet. Its more of a "playing it safe" landing... Another aspect is starting the engines, you will see that the APU puts out less pressure at high altitudes, so reaching the desired N2 for fuel introduction takes a bit longer. In the 747 at Mexico City we could "only" start one engine at a time and not run a pack at the same time due to this effect. Also do not forget to set up your landing elevation in the cabin pressure controller correctly. If you forget this, the plane will land pressurized (not allowed) and when moving the FLT/GRD switch to GRD after landing the pressure will be dumped immediately, creating a very high rate-of-climb in the cabin. Also remember that on longer flights TO a high-alt elevation you want to set the landing elevation to 6000 feet until starting the descent - that way the cabin altitude is not really high during the whole flight (may cause medical problems with the passengers). Yes, they will have to suffer the same thin air after they get out and have medical problems then - but then its not your problem anymore . Cheers, Jan

Another weekly update. The rather rigorous testing of route editing over the last week had brough forth a few more issues, not unexpected during such a substantial rewrite though... but without a doubt, there are substantially less issues with route editing. Jan's last round of route testing, he was unable to get a gizmo crash when changing procedures aggressively and could swap any procedure at any time. Our goal here is for folks to not be scared of to push any buttons on the procedures page during descent / approach for fear of a gizmo crash, and be confident they'll get the route they expect. So, for example, you can select a STAR and transition.....and fly that without knowing your arrival... and then select your arrival later and it'll just get "added" to your routing. I know I say this every time, we have not begun the VNAV rewrite though....so we can't say how the VNAV predictions will turn out just yet. We have a very small list of issues to wrap up, which I will be trying to tend to this weekend so we can get this patch out asap. After, I will examine the waypoint restrictions and then finally analyze the VNAV and set upon improving that feature. -tkyler

No, there is not. The dome lights are true "spill" lights, there are no _LIT textures associated with them. Your apartment is not a simulation. Lighting (especially shadows in daytime) is particularly difficult to simulate. The "map" lights (overhead) should work. I will take a look at what we can do for the next update but this may need to wait until v2.0.