Litjan

Well, you are the Captain. Just tell them to get the *** out of your airplane! ;-) Increasing the numbers is - as unfortunately we now experience at my airline - not quite so easy. Cheers, Jan

Hi, yes, this sounds familiar - it is quite the logical challenge to determine what part of a procedure a waypoint belongs to when one procedure joins the other one. In this case the problem is that we do not allow (yet) assigning a restriction to the enroute part. So if you enter the enroute first, RIPAM is considered part of it and the FMC will attach the rest of the STAR after RIPAM. And you can´t enter the restriction now, because RIPAM is part of the enroute section, not the STAR. This whole thing is very complex from a procedural point of view - I never thought about it when flying the aircraft. But it gets even worse - lets say we allow changing the restriction at RIPAM - but now you enter the STAR again. What should we do? Keep the restriction you entered, or overwrite it again with the "official" restriction? The real FMGS in the Airbus I fly now has a similiar problem. If you enter a cruising altitude that is below the restrictions on the STAR, it will erase those restrictions. But if you later decide to fly at a higher cruising level again, the restrictions are still gone and you might bust them if you don´t check your charts carefully... So yeah, the old rule applies: Fly the airplane where you need it to go, don´t rely on the FMS to do it for you. Cheers, Jan

Hi netwalker, hmm - it looks like you tried to enter the runway/intersection into the LSK 5L? I have to try this myself, maybe there is a bug lurking. For what it is worth, we never entered that value on the real 737 because performance was calculated with an external method (first runway-weight-charts, later with the EFB), so it may have slipped our quality control. More so there is no functionality attached to that field in our 737, so entering anything there will likely have no effect. Another thing I noticed is the incredibly high takeoff speeds the FMS calculates for you - this leads me to believe that you have set the preference for lbs/kgs units to kgs, but are entering weights as pounds? Cheers, Jan Edit: I tried to recreate your error on the Takeoff page but was not successful - can you give me exact steps to get it? Thanks!

I certainly think so! As a matter of fact I am already running an advanced Gizmo version that cures it. We just need to test it some more...

Well, here is the walkthrough: Open Planemaker Load the B733.acf Go to the tab "Standard" - pick option "Viewpoint" Stay in the tab "General", look at the "Cockpit" section (top right) Locate the fields that say long, lat, vert arm pilots viewpoint. Change the numbers in those fields to shift the viewpoint long(itudinally), lat(erally) and vert(ically). Click on the little "x" in the bar above when done. Choose "File", then "Save" then "Exit". Now reload the 737 in X-Plane from the developers menu, otherwise you won´t see the change. Cheers, Jan

Thanks for letting us know, ktomais. From my point of view there is nothing that would speak against replacing sounds in the IXEG sound folder, they are just .mp3 sounds. Of course you would do this at your own risk, but technically I couldn´t think of anything that could go wrong with it ;-) Cheers, Jan

Thanks for letting us know - happy you got it fixed!

I have no idea - if you delete your aircraft and reinstall it that should fix it. Unless you have copied the files into X-Plane itself, then you would need to run the X-Plane installer and let that find your altered sounds and overwrite them. Normally you can not hear your APU in the cockpit at all. You may be hearing the airconditioning flow, you can make that sound more quiet in the preferences menu (pop out). Cheers, Jan

There is no sound pack for the IXEG 737 to my knowledge. So this is probably where things got messed up on your end. Cheers, Jan

Hi Aaron, I have not been able to reproduce this behaviour - it is perfectly normal for the aircraft to dive quite steeply in FL CHG when goverened by Mach speed in the descent, the real plane does it, too - thats why many like to enter the descent more gradually with V/S. The reason is that to fly constant Mach you need to fly with increasing IAS when descending, so the plane needs to accelerate while going down - often leading to descent rates in excess of 5000 feet per minute. You will notice though that the plane is trying to fly a constant Mach (as indicated on the MCP) and you as the pilot have every right and authority to dial that one down a notch or two to avoid the dive becoming excessive. Also note that passengers have no ability to feel vertical speeds - they can only feel vertical acceleration. A steady 20.000 feet/minute would feel totally fine to passengers. Even body pitch angle is something they can not determine without looking out of the side windows - the feeling of "pitch" is goverened by longitudinal acceleration - accelerating feels like "pitching up" so that the nose-down attitude combined with the acceleration of the plane trying to fly constant Mach somewhat cancels out. Cheers, Jan

Great to hear that and thanks for letting us know! Happy flights, Jan

Hi, make sure that you have enough fuel - the fuel state is saved between sessions, so if you run out of fuel and then load the 737 again it will flame out the engines immediately. Cheers, Jan

Hi, this is a known bug with a "timer" in Gizmo, it should get fixed with the next Gizmo version (I am already running a test version that fixes it). Indeed you can not power the left GEN BUS with the GPU anymore after it has been powered by the APU or engine generators. The current workaround is to either accept that (no electrical users that you need during turnaround are on the left GEN BUS), or reboot gizmo once you are parked. The view (W) was intentionally moved over so you can see more of the important stuff (like the landing gear lights)...you can freely adjust it in planemaker (viewpoint) or set up a "saved view" with the CTRL-NumPad keys (you can bind recalling those views to a joystick button, too). Cheers, Jan

It is turned on by default if you use the "ready to fly" scenario. I would not assume that plugins aren´t a problem - if would still suggest moving them out of your plugin folder just as a test.

I am not sure if the manipulator framework logic for X-Plane supports this functionality - but I have added this as a feature request and we will see what we can do. Here is a post from another user that might help you (from the VR feedback thread): Cheers, Jan

The switch for the WXR SYSTEM is located between the two CDUs (where you enter info for the FMS). It powers the weather radar and the EGPWS system which is responsible for drawing the terrain on the EHSI. Picture:

Hi, the thrustreversers are pretty much straight X-Plane logic. You need to have the forward thrust at zero to engage reverse thrust, just like in the real aircraft. You can bind keys (like toggle reverse, full reverse) to the reverse thrust function or assign a joystick axis, it should all work. You can not "click and drag" the reverse thrust with the mouse or a VR wand...but you can assign a button or key to "toggle reverse" and then push the forward thrust lever forward with the mouse and it will actually pull open the reverse thrust lever. Cheers, Jan

There could be a few reasons for this, we are running some advanced code to operate the systems of this aircraft that can be causing this. Try to switch OFF the WXR SYS switch and see if that helps? Some third-party scenery has a very detailed terrain mesh that causes these lags when the terrain gets polled. Another option is to try the new Gizmo Beta version (run the Gizmo installer to get it), this also helps with framerate fluctuation. Also try if this happens at other places (try airport TXKF, Bermuda Islands) to narrow down the cause. Finally it could be an interaction with another plugin or third-party program causing this, you can try to follow the standard troubleshooting protocol to narrow down on it: Cheers, Jan

Hi Hugo, the green arrows on the EHSI show the position of the ADF 1 (thin) and ADF 2 (thick) direction. Bear in mind that a needle pointing to the 3 o´clock position can also mean "no reception", it is basically the default direction for the pointer to move to if no signal is received. The VOR bearing direction can only be indicated by turning the CRS selector until the magenta deviation bar centers. The RMI indicates correctly, you can switch it´s needles to also indicate the ADF bearings, though. So be careful what you select, default is VOR 1 (thin) and VOR 2 (thick). Cheers, Jan

Hello Sergei, yes, of course you can enter the coordinated to align the IRS to manually on the POS INIT page. The first few years I flew on the 737s we did not have GPS at all. The IRS would update on DMEs and VORs while in flight. We will look into modeling further "secondary" CDU pages as well after getting the more important ones still missing done. Cheers, Jan

I would not be opposed to the idea - the question is how easy it is to implement - if there is a way for us to tell X-Plane to "pause", it would be easy. I have added the request and we will look at it in our future enhancements to this plane. Cheers, Jan

...but why not shut down your computer while at work (works great for the electricity bill and the environment, too ;-)) and then when you are ready to play again you can spawn the aircraft at an airport "near" the ToD and then use the map view (key m) to place the aircraft at the correct altitude and speed and then "resume" your flight? Cheers, Jan

Hi, this is a current limitation of the manipulator we use for the V/S wheel. I explained it in another post recently, it basically works like this: In the real 737, the "wheel" for the V/S can spin without limit. X-Plane does not allow that, it needs a certain "limit" for maximum revolutions. Normally a value is tied to these revolutions - like on a thermostat. 20 degrees is always at X degrees manipulator turns. Unfortunately the "0" point for the vertical speed wheel "resets" every time you pick another pitch mode...but the wheel does not reset. So now the new "0" is not in the "center" of the revolutions anymore. So if you keep using the V/S wheel to descend - picking another pitch mode in between frequently - you will eventually run out of V/S downward travel. To "cure" this (until we find a fix) you can turn the V/S wheel "upward" again while NOT in V/S mode (you could just go to CWS P for a second) - then reengage V/S. Now you have the "full travel range" available again. Cheers, Jan