Rodeo

Oh I think I see what you're doing, OK.

I don't fly online, but I've never heard of anyone having to do this; can you be more specific of how you're flying online and why this is necessary?

No. AirFMC is just an interface to other control display units, but iFMS is an FMS in its own right, and AFAIK it only works with planes that use the default X-Plane navigation API (which the IXEG doesn't). I submitted a feature request to have AirFMC run on newer iPhones (6 and later), if you want you can go to the Haversine.com forum and add your +1

Or use any of your X-Plane quick look presets… Shift-9 might also work in some cases?

Right, but I mean, can you really be a full-time pilot and do all the other stuff you work on (also, aren't you married, too?), or are you on some kind of part-time deal with your airline?

Wait, you still (find time to) fly professionally? I was under the impression that between IXEG development, IXEG support and X-Plane gateway airport design, you were basically fully booked…

Interim hotfix should install version 1.0.7 - if the menu is showing 1.0.6, the hotfix is not properly installed.

The installer should automatically grab the latest hotfix for you, if you install from scratch, no?

Where are your logs, please?

I guess the issue here was simply that the format used by IXEG could represent "fix to <something>" so the runway threshold was incorrectly included as a normal waypoint instead…

I guess Aerosoft doesn't include "fix to <something>" as the first leg of a SID procedure in the IXEG database, only the GNS430 (Airbus X Extended) one.

That's only for Navigraph. I know Aerosoft includes many legs of the type "fix to an altitude" in their data for the X-Plane GNS430 GPS (e.g. LSGG SID procedures); not sure about their IXEG data. That being said, "fix to <something>" where the first fix is the runway threshold is really not much different than a "course to <same something as before>" and the legs should contain enough information to magically convert it internally should the IXEG code require it.

In version 1.0.5 it uses the values found in the preference file, any reason why it would have to be hardcoded in the future? Generally speaking, I have a "master" IXEG prefs file which I like to copy before each X-Plane start so that my flights start in the same configuration (heading, course, altitude, speed, com & nav frequencies, volume levels), and having these values ignored kind of defeats the purpose of having preference fields for them in the first place

While many improvements came in updated 1.0.6/1.0.7, the PROF page should probably still be considered a work in progress… Either way, one of the developers said somewhere that this is normal, as he didn't have the time to implement accurate fuel at destination for this update.

Is it me or do neither of those logs show the IXEG version number? Seems like quite the oversight (though for all I know there's a commit hash somewhere I didn't know to look for)…

This is not a bug, on the 737-300 logo lights are mounted on the wingtips; winglet-equipped models simply don't have logo lights, because you can't mount both on the same plane.

Navigraph customers can also check out https://www.navigraph.com/forum/viewtopic.php?f=30&t=2869

This specific SID is a bit shitty, because he intercept before WAMMY is nearly impossible. Basically, you fly over waypoint SENZY, then turn left to heading 203 until you intercept radial 151 from PYE. The problem being, in order for the intercept to occur before WAMMY, you need to be on heading 203 no earlier than 5 nautical miles past SENZY ; even with a generous overfly margin and a very low rate of turn, it remain incredibly hard to achieve. FWIW, the NavDataPro coding doesn't include WAMMY at all, it's SENZY, heading 203, intercept PYE R-151 (which mathematically happens after WAMMY), then SEGUL and so on. I also find noteworthy that while the FAA chart's illustration does display WAMMY, the text description (which, unless I am mistaken, is the binding part, not the picture) does NOT mention WAMMY either, only SEGUL… Anyway, my point is, this departure will cause just about every X-Plane addon to barf, and should not be taken as an example of "this plane's LNAV is broken". My personal assessment of it is "Jeppesen and/or Navigraph's coding of this procedure is quite optimistic and possibly broken".

This is more of a feature request, but a second turnaround-like state where the plane is powered by ground would be welcome

Yes, it's the same software as the U.S. nuclear missile systems.

Maybe they're just daredevil pilots…

A/T will advance the throttle to full forward, when you disconnect it, your thrust lever and the in-sim levers will be out of sync. You need to advance your lever to full forward until they match in in-sim levers (there's a visual aid in the lower-right portion of the screen), and then you'll regain manual thrust control.

Known limitation, will be improved in the future. Also do make sure to avoid the PROG page as much as possible (like, entirely), it's still the most crash-prone page on the FMS… I believe PROG may be improved upon significantly in 1.0.6, but don't quote me on that.

The guard/cover for the battery on/off switch definitely is open, else how come we can see the switch? Oh nevermind, I see I missed several posts…