daemotron

Thanks, I have to keep an eye on that. When I took the screenshot, I was about one hour into the flight. However I started at LEMD, and I have a screenshot proving OAT was at around 27°C there, so yes that could be plausible. I had the feeling seeing the fuel temp increase in cruise, but I have no screenshots or any evidence. I'll watch that (and eventually document if anything odd happens).

I have noticed that APU's EGT does raise when bleed air consumers get connected (engine starter valve most prominently): However, when hooking up electric consumers to the APU generator (or hooking the whole busses to the APU gen), the EGT doesn't flinch: I have no real aircraft at hand to verify, but from experience with other aircrafts I would have expected to see the EGT react also on electrical load changes. I couldn't find any videos for the real thing where the EGT display is fully visible on generator hook-up (in most videos it's just covered by the pilot's or FO's hand grabbing the APU GEN connector switches...). But again I don't know how it would work exactly in a 733, so probably someone can enlighten me wethere this is the typical behaviour, of if it's still on IXEG's todo list

Does this happen on VNAV only, or also when using N1 plus LVL CHG for climbing?

The version number is shown on the PREFERENCES menu, I think, or the PREFLIGHT - not 100% sure which one, but one definitely shows it. Indeed, there are some issues with (INTC) waypoints. Most of them are marked as Fly-by in the navigation data, while they should be Fly-over. You can test this by editing the SID with a text editor; if it displays correctly afterwards, you have the culprit (a known one in this case). NB: IXEG or X-Plane itself (not sure which component's responsible here) seems to cache nav data, so for me it only worked after restarting X-Plane and re-loading the B733. If what I stated above doesn't help, you could produce a debug log - after completing pre-flight for the FMS, key in four dots ("....") into the FMS scratchpad. This leaves a file called IXEG_debug_xy.txt in the IXEG 737 Classic folder (xy being a two digit index incremented by one for each debug output).

I experienced the following when flying LEMD/GCXO with this routing: VTB1S VTB UN10 HIJ UN857 TERTO TERT3L using the ILS Z 30 IAP via TFN, Departure at LEMD RWY 14R, Cruise at FL370. Issue: The DES and the CRZ page show different estimates until ToD: The plausible one is the one from the DES page (but not drawn on the HSI), whereas the one from the CRZ page is further than the destination airport: NB when I took those two screenshots, I was already descending manually, thus N1 being limited to R-CLB instead of CRZ - when reaching the actual ToC, N1 limit switched to CRZ and the CDU switched automatically from the CLB page to the CRZ page, so I assume the aircraft configured correctly for cruise. Plus, the two different ToDs were already displayed at cruise before I started descending. When I noticed the tow different displays (no sooner than already far into cruise), I tried exporting a debug output, which was responded by a Gizmo soft crash: However, a debug file was produced nevertheless (cf. attached IXEG_debug_05.txt).

Nothing that would impact functionality, just an oddity I noticed: Flying at FL370 with an OAT of -24°C, the FUEL TEMP indicator on the OHP indicated a fuel temperature of +20°C - not sure that this could not happen in RL, it just seems improbable...

Just a tiny one, I noticed that apparently the Ground Service menu and the Takeoff page use either not the same calculation for T/O trim, or there's a rounding somewhere (really just a minor difference, no impact on functionality):

For me, it's the whole package offered by IXEG that makes it outstanding beyond anything I experienced in nearly 25 years of flight simming (yes, I started with FS3 ). Giving all those insights into the development process and progress, all those great videos done by Jan (including, but not only the tutorial ones) teaching me a lot about the B733 and airmanship in general, of course the great flight model - never enjoyed hand-flying a tubeliner so much as with the B733, it's just marvellous how precisely it follows control & trim inputs. Not speaking of the modelling detail for systems - not focusing so much on the FMS only, but also on pneumatics, hydraulics (never had another model that showed hydraulics quanitity impacts by actuators filling up), ... Plus a super-immersive cockpit - visually and audibly (I love the background sounds like cooling, pack flow, woodpecker plus the variety of sounds all those knobs and dials are causing). And last but certainly not least the dedication of the IXEG team, producing hotfix after hotfix, patiently digesting everything we throw at them in the bug reports section, looking even into seemingly absurd reports where other developers would long have declined it could be related to their add-on. This really deserves recognition, so a big big Thank You to the whole IXEG team!

No, they aren't. The lateral navigation mode only determines what the flight director bar indicates. It's up to the pilot to either have the autopilot follow the flight director automatically, or follow the FD by manual control inputs. Of course you can also ignore the FD or switch it off. <nitpick> The B733 doesn't use GPS directly for navigation. You're probably referring to RNAV (which I agree is not appropriate since the procedure sampled by Tchou is not an RNAV one. RNAV uses the two inertial navigation systems as primary source, updating/correcting the position by GPS and radio navigation inputs </nitpick> But I don't get yet what you're up to, nobody suggested flying this procedure under RNAV conditions so far... Again, the AP (if engaged) will simply follow FD guidance, independently of whatever lateral navigation mode the FD is using. I agree that a procedure beginning with a 270° turn below acceleration altitude is something that would normally be flown with manual control inputs. Nobody disputed this. Just consider what Jan said: With a loaded aircraft just after takeoff, your minimum maneuvering speed will most probably not allow you to catch the relatively narrow radius drawn on the chart, but will force you to fly a circle that will have you intercept R241 MNS not exactly at MNS, but further south-west of the VOR. This has nothing to do with lateral navigation mode or autopilot engagement, but simply with physics. You probably want to read Tchou's and my previous post again - we were both referring to a whole bunch of reported LNAV issues, among them some referring to RNAV procedures, and not just the example given above. In reality, navigation data sets used in aircrafts are double- and triple-checked to ensure that data flaws don't mess with the FMS. However this quality doesn't sell for less than 40 US-$ per 12 cycles. So even this is not in line with reality, in virtual aviation the aircraft developers are left to deal with that problem. This doesn't mean one needs to program around any eventual problem with nav data. Capturing most common flaws however is something you want to take into consideration. Hm, that's again a question of philosophy - seeking perfection in one feature and tackling others afterwards, or try reaching an acceptable level (whatever that means) for all features concurrently. And btw. since IXEG is a team seeking realism at a really great level, it's up to them to stop discussion about LNAV inaccuracies the moment they want it.

Well, yes and no. There are several cases where procedures won't draw correctly by the FMS, some of them a general problem with more or less all X-Plane aircrafts, some specific to one or another model, some even specific to the IXEG B733. Let's have a look at those: Freaky (i. e. not flyable in accordance with the chart) procedures just like the one you dug up. This is indeed a very rare case, but with great potential of hitting a lot of aircraft models. Real world limitations. If creators of a model did a good job (and IXEG did!), you will probably hit some limits with procedures you wouldn't be allowed flying with a B733 in real world. This applies mostly to procedures marked as "TURBOPROP ONLY", or RNAV with RNP limits (ok those will work since X-Plane doesn't simulate RNP, you are always on spot where you are...). Procedures where nav data do not properly describe the procedure as per chart. In my flight sim beginnings they were quite common since procedural data quality then was not at the level it is today. Today you encounter this with rather esoteric procedures; I just caught one yesterday, seeing that the LOWS RWY 33 RNAV-V procedure data (at least with NDP) are missing the two final waypoints (ok that one's not sooo esoteric, but also not that frequently used). Programmers stand no chance capturing these errors, even with a sophisticated plausibility test (which would probably deliver more false positives than real issues). Blotted or imprecise nav data. This again is a quite common issue; for instance I would categorize all those virtual waypoints with imprecise fly-by / fly-over tags under this umbrella. Here the nav data allows the programmer to interpret what could be meant. Most issues I dug up with the B733 belong into this category; for comparison I usually check also with the FF B763 - simply because they seemingly coded around this issue and determine correct turn direction in most cases where IXEG doesn't (yet). Incomplete FMS implementation - just have a look at all the payware aircrafts with a FMS out there and count how many of them correctly deal with radial or alt interception, bearing/distance or bearing/bearing intersections, etc. There are more than just a couple only understanding FIX, VOR and NDB waypoints. OK this one doesn't touch IXEG so much; they announced the FIX page will be delivered somewhat later, so no limits on procedure oddities from their side Implementation bugs. Yes, they exist, too. Usually they're hard to find and prove, since you first have to understand the nav data and their correct interpretation. IXEG has made this a lot easier by moving to a very explicit nav data format. Trade-off: you have to scroll a lot in those XML files, but the readability is much better than any other format I came across so far. I only spotted on potential candidate for this category with IXEG yet, where the draft route shows correct routing, but EXEC blows the thing... So for me this boils down to three simple things: Yes, IXEG has done an exceptionally good job on LNAV so far. Nav data for simming purpose will most probably never reach the perfection they would need, so as an aircraft developer, you will hardly be able to avoid implementing some work-arounds for the most common flaws (e. g. the fly-by / fly-over tag issue) For the same reason, as a pilot you have to check what the FMS draws before EXECing it or even (auto)-flying it. When in doubt, fly the procedure as per chart by hand or using other modes (i. e. HDG and/or LOC) for lateral navigation.

I noticed one thing where I'm not sure if it's a "works as intended": I mostly use LVL CHG in conjunction with N1 for climbing and descending instead of VNAV. This implies that at one point one has to switch between IAS and Mach. Now what I didn't expect: The B733 does this on its own (on the MCP), but not in sync with indications on the FMS CLB page. When climbing with 284 KT IAS (corresponds to a CI of 40), the automatic cut-over to Mach happens at ~FL260+, resulting in a Mach target of 0.70. At the same time, the CLB page still highlights the IAS speed of 284 KT and switches to Mach no sooner than ~FL295 with a Mach target of 0.73 (as indicated after route and perf are entered and EXECed). On descend, a similar behaviour can be noticed: An automatic switch back to KT IAS happens also too early with ~260 KT instead of some 280ish speed as indicated on the DESC page. Now on one hand it seems logical that LVL CHG ignores what is set in the FMS (it's not VNAV after all...), but I couldn't find anything about an automatic switching between IAS and Mach...

Reference: IXEG B733 version 1.0.3, NDP AIRAC 1605 Another STAR that does not draw correctly. First I thought it's along the same book as and there are certainly some similarities; the wrong turn direction is again linked to a "virtual" waypoint with a fly-by tag (cf. attached nav data extract file). However, one thing intrigued me about this one, and it was the fact that I thought I remembered the route had looked correctly when checking in draft mode (the dashed blue line before EXEC). So I simply chose the STAR again, and yes, I was right about that one: Also true if the STAR is re-selected on the DEP APP page: So in draft mode, the STAR is drawn correctly with a left turn, but after EXEC the turn is reversed (cf attached IXEG_debug_03.txt). Again, setting the questionable waypoint (WP ID 3 "(INTC)") to Fly-over fixes the whole story (cf attached IXEG_debug_04.txt) : I'm currently trying to find a rule when a virtual WP needs to be considered Fly-over, so I can automatically create a list of procedures that require updating. Before, my guess was that only ConstHdgToAlt WPs at the beginning of a STAR were concerned, now I think it's rather: Any virtual WP of the type ConstHdgToAlt or Intc But only if the subsequent WP is of type Normal No matter if there's a Normal or virtual WP predecessing the questionable WP Can anyone confirm?

Got this one for Jan - and guess where? At Airbus capital LFBO [emoji1] Sorry it's a bit blurry but that window of the A319 didn't want to open[emoji12] Gesendet von meinem SM-G920F mit Tapatalk

Hm, if that's the intended behaviour, it should work when overwriting the fuel prefs during initialisation is deactivated - then the preflight menu alone will set the prefs, and they're not changed through anything else.

When loading the aircraft initially (through X-Plane quickstart after opening X-Plane), the primary altimeters do not show the correct altitude: On captain's side, the thousands digits keeps set to zero, on the FO's side, both, the thousands and hundreds digits remain set to zero (standby altimeter displaying correctly): Rebooting Gizmo, opening the aircraft throught Aircraft - Open dialog or simply clicking APPLY in the preflight menu fix this: Not 100% sure if there's a link to but to me it somehow looks as if aircraft initialisation is maybe not 100% completed when loading through the X-Plane quickstart dialog, while Aircraft - Open doesn't show the same behaviour...

Don't know if I understood the RA correctly, but I thought the actual fuel that was in the tanks at the end of last flight (when unloading the B733 or X-Plane) would be stored: However, I now get strange fuel values each time I load the B733 - no longer the standard 7,500 kgs from previous versions, but also neither the fuel I had in the tanks at end of last flight, nor the fuel I loaded for last flight. It seems to be 2268 kgs for the wing tanks each and 3506 kgs for the center tank now. I played a bit with monitoring IXEG_user_prefs.txt, to narrow it down. Here's what I found: When loading the 737 (quick start on x-plane launch), the fuel_amt_[1,2,3] variables are overwritten with the above given values (with 1 and 3 kept in sync). When doing a Gizmo reboot after having loaded the aircraft, fuel variables are re-set to the value stored in the last X-Plane session (maybe the amount that's really in the tanks? don't know where it takes this info from, could be read from IXEG_user_prefs.txt before overwriting it with the defaults given above). IXEG_user_prefs.txt is updated accordingly. Opening one of the IXEG dialogs directly after loading the aircraft (without reboot) shows correct values, but does not write them back to IXEG_user_prefs.txt NB: the PREFLIGHT menu sometimes also shows the above given values from the file, but I couldn't figure out the conditions when it does so When changing the fuel via PREFLIGHT menu, the fuel variables are re-set to the new values and IXEG_user_prefs.txt is updated When changing the fuel via GROUND SERVICE menu, the fuel variables are not changed (i. e. IXEG_user_prefs.txt is not updated) Shutting down the APU (as probably the last fuel consumer being turned off in a flight cycle) does not trigger an update to IXEG_user_prefs.txt Shutting down an engine does not trigger an update to IXEG_user_prefs.txt Unloading the aircraft (by closing X-Plane) does not trigger an update to IXEG_user_prefs.txt In consequence, when re-loading the B733 next time, the IXEG_user_prefs.txt either contains the fuel set through the PREFLIGHT menu (if done so after the last loading of the aircraft) or the seemingly random values posted above (since the IXEG_user_prefs.txt file is overwritten with them on each loading and the GND SERVICE menu doesn't trigger IXEG_user_prefs.txt to be updated). Therefore I'd recommend to update the fuel_amt variables in IXEG_user_prefs.txt also on those events: PREFLIGHT MENU on close (even if fuel was not updated - say I just opened to check and was happy with the values there, then I still have 2268/3506/2268 in IXEG_user_prefs.txt and a bad surprise next time I load the aircraft) GND SERVICE MENU end of refuelling GND SERVICE MENU on close (same rationale as for PREFLIGHT MENU) on engine shutdown (taking the values in the tanks) on APU shutdown (usually the last fuel consumer being shut down on a normal flight cycle) [EDIT] P. S: I somehow forgot the scenario "open X-Plane with the B733 and close it again without doing anything" - that would again write 2268/3506/2268 into IXEG_user_prefs.txt, so bad luck on next start. Not sure how to catch this one (I'm no expert, but most probably there isn't an "on_exit" event - and for sure non for a hard CTD), so probably the best solution would be to enhance initialisation routines to write back the actually correct fuel setting into IXEG_user_prefs.txt before taking any other action.

I stumbled across this one on a turn-around (without rebooting Gizmo since I didn't need VNAV for that leg), and I'm not 100% sure this is really a bug or intended behaviour: After updating RTE, PERF and N1 LIMIT pages (and executing everything of course), I had correct QRHs displayed, but I could not confirm them by clicking the RK 1/2/3. I had this already before, sometimes I could, sometimes not. Now this time I noticed I still had the APPROACH REF page open on the FO's CDU from the previous flight, and voila, as soon as I select any other page on the FO's CDU, I can set and confirm V1, VR and V2 (plus: re-selecting the APPROACH REF page on the FO's CDU will instantly clear the V1/VR/V2 selected): I know this is sort of weird; normally it doesn't make sense to have VREF for approach set and V1/VR/V2 at the same time. Now the question is, what would the real aircraft do in such a situation?

What works (at least with 1.0.2): Enter new ORIGIN and DEST on the RTE page, then select at least the new departure at DEP/ARR page. This clears the old route. However, you need to be aware that VNAV will not properly work on subsequent legs without having Gizmo rebootet on turn-around. If you don't use VNAV, it works as described.

My primary and standby altimeter are diverting . I was doing a series of flights without reloading the aircraft, and I don't know if it happened already on the first fligh, or just on subsequent flights after a couple of baro adustments for departure and arrival (always done for all three altimeters). It's pretty much aligned on ground even on the last flown leg (given I use correct pressure setting for both, of course): But with increasing altitude, diversion between both instruments becomes more outspoken (same pressure setting, of course): At cruise I experienced more than 300ft divergence, which is pretty much for that... I was first asking myself if this could be one of the features (to have instruments not always perfectly aligned, just as in real life), but given the magnitude of the diversion I think it's rather inadvertent (in an airspace with 1,000ft layers a diversion by 300 ft would be quite dangerous - having it in two aircrafts would bring them as close as 400 ft vertical...).

Thanks. Btw. this post above is automatic; the file manager is generating it

Air-Child is available:

Air-Child IXEG 737 Classic Livery View File Initial version of my Air-Child VA livery. This livery models the only 737-300 on the ACH fleet, SE-JOK "Johann Olav Koss". Please note: I consider this livery as a rather basic version, I just threw the ACH colors, logo and decals at the paint kit provided by IXEG (with some minor adjustments). There are still a few rough edges (e. g. the struts on the radome, rudder leading edge etc.). For me this will do, however if somebody with better PhotoShop skills would like to have a go, drop me a PM and I fill find a way to share the PSD files. Submitter daemotron Submitted 05/03/2016 Category IXEG 737 Classic Livery For Click Here For Aircraft X-Plane Version(s)

Btw. did anyone consider making a Kulula "flying 101" livery? I know this one is a NG, but the livery would be funny enough for the CL, too

Air Child is currently in WIP status (will be released this week, depending on how much time I take for it to complete): P. S. this is a shot from Plane-Maker, so of course the gridlines will not be in the final livery (currently only the left side is painted...)