Litjan

Happy to hear that you got the speedproblem fixed! The fuel quantity test is fully driven by our custom lua code, so it can´t be influenced by planemaker. The fuel gauges work, it is just the test (going through different displays) that doesn´t work. I am pretty sure that the MEL would allow flying without it, but the poor maintenance guys would probably have to pull dripsticks before every flight (and have the fuel run into their sleeves!). Cheers, Jan

Hello Fred, the EFM should be turned on for best performance - but the plane will fly fine with it turned off as well. Your problems have nothing to do with the EFM. We will have it "forced on" by planemaker in the next update. The test button for the fuel meter and the test button for the leading-edge devices do currently not work due to a timer bug which will be fixed with the next Gizmo release. Cheers, Jann

Hi Fred, I would suggest that you watch my tutorial videos and try to mimic (refly) what I show there. Cheers, Jan

Hi Torbinator, in general the first thing we do when we get these report is check the underlying nav data that is being used. We would need to know the provider (Aerosoft or Navigraph) and the navdata cycle. Quite often the data is not correct in the dataset - or the user is looking at outdated charts, or updated charts with outdated navdata ;-) You can often see this yourself if you look for the corresponding .xml file in the navdataset and then do a textsearch for SITEE4. You can probably read the xml and see if the altitude of 230 or above is encoded there. This is what it looks like in Navigraph data: </Star_Waypoint> <Star_Transition Name="GGAPP"> <StarTr_Waypoint ID="1"> <Name>GGAPP</Name> <Type>Normal</Type> <Latitude>37.533222</Latitude> <Longitude>-112.134619</Longitude> <Speed>0</Speed> <Altitude>23000</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>above</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </StarTr_Waypoint> I can see that the 230A is present (also in Aerosoft) and I can confirm that it is not depicted in our FMS when I load the STAR, so it is probably a bug in our software. This will receive close scrutiny in the VNAV rewrite, so it is probably not necessary to report these problems now. The curved approach problem depends on the RNAV capability of the (old) 737-300 Classic. It is not capable of RF approaches (radius-to-fix) - which defines the circle to be flown. Therefore when you see these letters on an approach chart: RNP AR APCH, RF required - it can not be flown with our aircraft- in fact I can not even fly ith with our modern A320s, we can not fly AR (authorization required) approaches, but we can fly RF, of course. I think for now there are normally alternative RNP procedures provided, because many older planes can´t fly RF. I will talk to Tom, maybe we can add that capability to keep our plane abreast of modern development, I am not sure if the real Classics still flying are capable of those approaches, though. Cheers, Jan

Yes, I reproduced it as well... thanks!

Hello nicotum, very sorry that you encountered this problem! We will try to recreate it and hopefully fix it soon. Thanks for your report! I will get back to you if we need additional info! Cheers, Jan

Thanks for getting back to me on this - normally we are careful to "limit" the values that you can put into fields, but there is always the chance that we missed something. We are always thankful for hints and feedback on how to improve our plane, so if you gain any additional insight in this (or any other) matter, please let me know! Cheers, Jan

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: