Litjan

There will ne one out very shortly, we have been working with the dev on that... should only be a few days. Jan

I habe never heard of that, so I assume its only valid for some (older) configurations. In our model the BAT position shows voltage of the battery bus. Jan

Interesting, I am following this to see if you find out the exact problem... you are not depressurizing the A-Hydraulics for the push, are you? (Some old procedures ask for this, when you don´t have a steering bypass pin). In this case make sure that you switch them on again after pushback... Jan

You can´t. This is a flightplanning format that can not be read by an FMS. You can enter coordinates if they are published as five-character waypoints, like N3050 or such. You would have to specify cruise speeds and level changes on the legs page, but changing level with the Step climb function is not yet supported. Jan

Hi Dainius, no tank will ever "fill" from other tanks - there are checkvalves that prohibit this. Crossfeed is for the rare situation when you want to feed a left engine from right tank, for example. Even when using the CTR tank pumps, the crossfeed valve normally stays closed. Only in a high-pitch situation you can observe one CTR pump run dry (they are placed fore and aft) - then you can open the crossfeed, so that both engines get fed from the still pressurized pump. When more than one pump is feeding engines, there is always a "stronger one" that will win - and no fuel will be delivered from the weaker one - this is like in reality, and it may look like the crossfeed is not working. Jan

Hi Ryan, something seriously wrong with your installation. You may have an old or conflicting version of gizmo, or not installed gizmo correctly. It is also possible that the file system is not correct, maybe using a special volume name in foreign characters for your main drive, etc. There should not be a gizmo-softcrash console window popping up first thing after the plane spawns. I suggest re-installing the plane and gizmo, paying special attention to the process and the recommended folder structure. Once you see this first console window opening, your 737-session is over. Do not attempt to fly or work the plane, you have to reload the plane or at least reboot gizmo. I hope this helps, Jan

10.50 should work. To really troubleshoot your problem we would at least need a video of what you are doing. Thanks, Jan

10.45/10.50 should have no effect on our aircraft. My guess is that your joystick is noisy/interfering - try to increase the "CWS deadband" zone in the preferences... Jan

My guess is that these virus scanners are trying to keep an eye on all in and out traffic. When the route enters a MOD stage, we access other folders in the x-plane installation (earth_fix.dat, etc.)... Jan

Thats cool, no rush! Cheers, Jan

Yes, sometimes you will not notice a reduction in thrust from R-TO to CLB-1 or CLB-2... In the economically ideal case there would even be an increase in N1 from R-TO to CLB. It is more economical to climb to altitude with full climb thrust (faster in thinner air -> more TAS, less specific fuel consumption). But the manufacturer wants the thrust to always DECREASE at the thrust reduction altitude, for fear of confusing the pilots when thrust suddently increases... Jan

Hi Chako, The EXEC light will only come on if you have a valid, activated route. My bet is that your route does not fulfil the requirements to be executed. As for the speedbrake, are you sure you are moving the lever to the "ARM" range? This only works in the air, btw...you are not trying to get the green light on the ground, are you? Cheers, Jan

Hi Ryan, at this point I am at a loss - I think the only way to get us further is you shooting a quick video (maybe with the built-in video capture function) of what you are doing and posting that here... then I can take a look and figure out if its something you are doing. The only alternative is you giving me a step by step VERY precise sequence of steps you are doing - like pushing every button, every LSK, what you enter in the scratchpad, etc. A video would be better ;-) Thanks, Jan

Hi Benjamin and "vielen Dank für das Troubleshooting"! I would bet that Avast not being set to exclude the whole X-Plane folder was the problem, so PythonInterface should probably work. We do access files in other folders besides the airplanefolder, so it is only natural that those must be excluded, too. Viele Grüße, Jan

Hi, thats a new one, but I would guess that you somehow turned your engine start levers to "run" and possibly turn the engine start switches to GRD - it could be that they are erroneously mapped to some button or key you are pressing? Try to follow the tutorial videos on this and see where your procedure differs... Jan

Hmm, not sure I understand the question correctly. You just set the thrust reduction altitude to 1000 AAL for the NADP 2 and also initiate acceleration from V2+10 to 250kts at that altitude. This results in a flightpath that is a little closer ot the ground at first, but ultimately achieves a clean aircraft (saves fuel) and steeper overall climbout angle (less noise further from airport). It is the preferred method for airlines. For NADP 1 you leave the TRA at 1500 AAL, but wait with the acceleration until you reach 3000 AAL. This yields a steeper initial climbout (less noise closer to airport) but results in overall more fuel used (longer flight with higher drag). To determine the point of when you start acceleration is done by choosing when to exit the TO/GA pitch mode. Simply delay pushing VNAV or FL CHG until you are high enough. This point can not be coded into the FMS like it is done for Airbus FMGC or (I assume) NG FMC versions. Jan

Hmm, did you do something odd to your X-Plane installation, like moving database files to other folders or moving the airplane´s files around? This is the first time we have heard that complaint, so it must be something specific to your setup. Also check if a virus program (like avast) is interfering with database access... Let me know how it goes, Jan

Hi, which ICAO code for the origin did you try to enter? If it is a smallish airport, it might not be in the navigational database - in that case just leave the origin field empty and take off VFR. But there should not be an error message in the console, so I would like to look into that. Thanks, Jan

Yay!! Keep me posted! Holding my thumbs (for good luck!) Jan

Thanks for the report and I am looking forward to hear what happens when you turn Avast off completely (or at least for the whole X-Plane folder). Just for troubleshooting, could you also remove FlyWithLua, Pythoninterface and XSquawkbox? The correct procedure is to remove them from the plugins folder before loading X-Plane, just disabling them in the plugin enable/disable box doesnt suffice. Thanks for helping us narrow this down, Jan

Hi guys, really sorry to hear that you continue to have that problem. Our biggest obstacle in fixing this is that no one in our development team can reproduce this. It must be something specific to your hardware/software combination/setting and its pretty much impossible to fix something you can´t see. There has been no change to the way modified routes are handled since version 1.0. If the simulation is slowing down this much, it hints at a computational problem, in other words too much to do for too little processing power. We have been through a lot of possible solutions to this and I think its especially disturbing that it is coming back for some users that reported it solved. I really can´t say that there is a definite plan on how we are going to fix this - since we have little idea what is causing it. It only appears for a tiny fraction of our users. I can only encourage you to seek for a probable cause along the possible solutions already pointed to in this forum. Maybe a second virus scanner that you "forgot" about or installed unawaringly when it piggybacks some freeware installation, or a OS specific setting that may cause this, some background process, a diskspace problem, or fragmentation. Good luck and I really hope that we can find the cause of this together - although I firmly believe that the solution to this is to be found on your end and can´t be solved without your investigative effort. Jan PS: If you can reproduce the problem reliably with just a few steps, I would like to hear them - so I can try it on my end. Maybe there is some highly specific combination of procedure or waypoints that is causing this? Maybe someone is adept enough to make a video of how exactly to reproduce it that we can use to troubleshoot?

Don´t be - we have all been there...especially with equipment this complex. I am here for your questions and advice, and I would hate it if someone refrained from asking or remarking about something for fear of being wrong. And don´t worry, I still have to learn some things about the 737 myself . Cheers, Jan

NO

Thanks for the report, 777 - added to the list. Tom will look at it, I think we are seeing the same coding problem rear its head in several places... Cheers, Jan

Hi, thanks for the thorough checking and feeback. I don´t think we have implemented the limit of trim regarding flaps extended/retracted (I wasn´t even aware of that) - only the different trim speeds. We decided to not implement the trim cutout with opposite control column as it is just too unintuitive in a desktop simulation and really only needed in a runaway situation. BTW: You missed one error! When the autoslats deploy, there should be no amber "LE Devices in transit" light - only on the aft upper panel... Its listed in the issues list. Cheers, Jan