Search the Community
Showing results for tags 'b733'.
-
Version 1.0.0
55 downloads
Modern Logistics is a Brazilian freighter airline based at Viracopos/Campinas (SBKP/VCP) and actually they have a fleet of 737-300 (YBC-YBD)/-400 (YBB)/-800 (YBF). - Windows Cover Mod Required -
Modern Logistics - PP-YBC | PP-YBD View File Modern Logistics is a Brazilian freighter airline based at Viracopos/Campinas (SBKP/VCP) and actually they have a fleet of 737-300 (YBC-YBD)/-400 (YBB)/-800 (YBF). - Windows Cover Mod Required Submitter vinileite Submitted 10/06/2023 Category IXEG 737 Classic Livery For https://www.x-aviation.com/catalog/product_info.php/take-command-ixeg-737-classic-plus-p-243
-
Version 1.0.3
580 downloads
American Airlines Old Livery (N678AA) Simply drop inside the liveries folder Enjoy -
Version 0.2.0
56 downloads
This script duplicates the Captains CDU in a Window. To activate the Window CDU, move your mouse to the far right on your monitor, and press the button. Al normal functions should be available, except the CDU keyboard. If you check "<Use Keyboard for CDU Input" on the Window CDU however, you can use your computer keyboard to enter data. The backspace key functions as a CLR key. PLEASE NOTE: if "<Use Keyboard for CDU Input" is checked, ALL keyboard input is directed to the CDU, and you can't give normal key commands to the simulator. So, you can't change views, lower the gear by pressing g, etc. The ESC key releases CDU keyboard capture as well as unchecking the option. Current limitations; Inverse colored data from the CDU is displayed normally, MSG, FAIL and OFST are not duplicated, but only shown on the normal CDU. In theory the Window CDU should work in VR. You can drag the Window CDU to another monitor. PLEASE LET ME KNOW, if there is anything going wrong. Plugin needed: FlywithLua NG: https://forums.x-plane.org/index.php?/files/file/38445-flywithlua-ng-next-generation-edition-for-x-plane-11-win-lin-mac/ -
Window CDU for IXEG 737-300 View File This script duplicates the Captains CDU in a Window. To activate the Window CDU, move your mouse to the far right on your monitor, and press the button. Al normal functions should be available, except the CDU keyboard. If you check "<Use Keyboard for CDU Input" on the Window CDU however, you can use your computer keyboard to enter data. The backspace key functions as a CLR key. PLEASE NOTE: if "<Use Keyboard for CDU Input" is checked, ALL keyboard input is directed to the CDU, and you can't give normal key commands to the simulator. So, you can't change views, lower the gear by pressing g, etc. The ESC key releases CDU keyboard capture as well as unchecking the option. Current limitations; Inverse colored data from the CDU is displayed normally, MSG, FAIL and OFST are not duplicated, but only shown on the normal CDU. In theory the Window CDU should work in VR. You can drag the Window CDU to another monitor. PLEASE LET ME KNOW, if there is anything going wrong. Plugin needed: FlywithLua NG: https://forums.x-plane.org/index.php?/files/file/38445-flywithlua-ng-next-generation-edition-for-x-plane-11-win-lin-mac/ Submitter TonyVier Submitted 02/03/2019 Category Plugins and Utilities
-
Version 1.0.0
30 downloads
This isa livery for try Take Command IXEG Boeing 733 in Swiss colors. -
Privat Air HB-JJA View File This isa livery for try Take Command IXEG Boeing 733 in Swiss colors. Submitter kickremi Submitted 08/22/2018 Category IXEG 737 Classic Livery For http://www.x-aviation.com/catalog/product_info.php/take-command-ixeg-737-classic-p-122 X-Plane Version(s) X-Plane 10 & 11
-
I'm attempting to paint a cargo version of the B733 for my VA. I am having difficulty with the exterior cabin window frames. I changed the color of the cabin window 'glass' in B733_glass_decals.png. I then changed the color of the cabin window frames in B733_fuselage.png (near center of texture - frame with light inside). Window 'glass' is now fine, but window frame remains as in default passenger aircraft. Is there something else I need to change? Thanks in advance for any assistance!
-
Luxair B737 View File This represents the Luxair livery introduced by their phase-in of their ERJ145 (1998/1999) until the current livery was introduced with the phase-in of their Q400s in 2007/2008. I used LX-LGP (B735) as a template - As Luxair never had the B733 and just B734/B735. Submitter concordeag Submitted 08/04/2017 Category IXEG 737 Classic Livery For Click Here For Aircraft X-Plane Version(s)
-
Version 1.0.0
127 downloads
This represents the Luxair livery introduced by their phase-in of their ERJ145 (1998/1999) until the current livery was introduced with the phase-in of their Q400s in 2007/2008. I used LX-LGP (B735) as a template - As Luxair never had the B733 and just B734/B735. -
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)
-
Version 1.1.0
144 downloads
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. -
Version 1.0.1
487 downloads
My first repaint here, and also for the IXEG 733. It's fictional repaint of new Belavia color scheme, I hope you'll like it -
IXEG 737-300 Belavia - new colors (fictional) View File My first repaint here, and also for the IXEG 733. It's fictional repaint of new Belavia color scheme, I hope you'll like it Submitter iFlyCZ Submitted 02/27/2017 Category IXEG 737 Classic Livery For Click Here For Aircraft X-Plane Version(s)
-
Reference: IXEG 737-300 Classic version 1.0.7 X-Plane 10.50rc1 NDP AIRAC 1608 rev 1 Route flown: LEPA MERO2A.MEROS UN853 LUMAS UM976 SOFFY UQ208 MOBLO UZ662 LAMUR Z67 KORED UN871 DITON T163 ZUE T125 ROMIR UN851 KEMAD P605 AGATI.AGATI2K EDDH Departure: 24R Arrival: ILS 23 Effects observed: The VNAV profile proposes a ToD only 70NM from the runway threshold for a descend from FL360: On a second attempt (the one for which I attached the logs), I modified the ALT Constraint for PISAS from 3000A to 3000 (as 3000ft would be the GS interception altitude at PISAS), but this did not change the VNAV profile. The constraints in the Nav Data (at or above) are OK (apart from PISAS), but the computed VNAV path is way higher (and steeper). At one point, the ND even claims the VNAV path to be at negative altitude (saying I'm 16,600ft above VNAV path while flying at FL125): In real life, the ToD would be somewhere shortly before DLE... Log.txt GizmoLog.txt IXEG_FMS_debug.txt
-
Sorry for the title of this post, I didn't find anything more suitable to describe this experience in just a few words. So here's what happend on my last flight from LEMG to LEPA, using this route: LEMG 13 ROLA1H ROLAS UN851 IZA IZA1P LEPA 24L (IAP: ILS Z 24L, MJV transition) Navigation data used: NDP AIRAC 1605 I started descending some 25NM before the calculated T/D using V/S mode (VNAV mode was not used during whole flight, but the FMS was completely set up so it could have been used, even including ISA and wind). Lateral navigation was done using LNAV mode (engaged shortly after TO and maintained for the whole flight until final). Passing waypoint IZANB (first fix of the STAR, comes after the T/D), the LEGS page got "stuck" on that waypoint - i. e. it continued displaying it as the active waypoint. Also the VNAV path indication showed its deviation based on that waypoint, as if the aircraft had never reached it. At the same time however (remeber I was flying with LNAV) the flight director continued tracking perfectly the magenta line to X232 and SABAS without any issue (despite two HDG changes on these segments). Usually when missing a waypoint, LNAV will make you go round in circles until you alter the routing or properly intercept the missed WP. So to me it seems the VNAV part of the FMS and the CDU "lost" the route progress, while the LNAV part of the FMS correctly followed the route - the HSI consequently however did not highlight the waypoint LNAV was flying me to. Maybe this screenshot helps illustrating the situation: Next thing I tried is recovering VNAV and the legs page. Directly after having passed SABAS, I activated MJV (next waypoint after SABAS) by coyping it to LSK1 and EXEC. The legs page was then updated accordingly, however the VNAV deviation was still stuck at IZANB, and the HSI was still not highlighting MJV as active waypoint (however LNAV was not much impressed by this, it tracked the WP anyway): After the aircraft passed MJV and started tracking MJV11 (next waypoint after MJV), without further intervention from my side, the situation recovered: the LEGS page updated automatically to MJV11 the VNAV path deviation shrunk to something plausible (MJV11 has an at or above restriction on it, so the FMS estimation was not visible at that moment - therefore just "plausible", but correct with high probability) HSI shows MJV11 as active waypoint (magenta highlighting) Attached the log files (Gizmo will show you the mandatory soft crash for me having forced a debug output on this, but since it seems like a VNAV/LNAV story, I thought it could be useful...)
-
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): -
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...
-
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).
-
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?
-
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.
-
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...
-
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?
-
American Airlines Old (N678AA) View File American Airlines Old Livery (N678AA) Simply drop inside the liveries folder Enjoy Submitter scubajuan_new Submitted 05/04/2016 Category IXEG 737 Classic Livery For Click Here For Aircraft X-Plane Version(s)
- 1 reply
-
- 1
-
-
- ixeg
- american airlines
- (and 3 more)
