Litjan

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

Hi Apeachs, thats really kind of you to say, thanks for the nice feedback! We are working on improving our plane as we type - I will post a preview movie of some of 1.1s features on our IXEG channel soon... Cheers, Jan

Hi ibawbag, Thanks for the nice words and the feedback. I can´t confirm your problems with the autoland - are you using some sort of weather injector/third party program? The real autopilots´autoland has some pretty strict limits on wind speeds (max CWC 10kts) and will also fail if there is a sudden change in winds close to the ground. The look of the CDUs is 100% realistic (and I have stared at those things for 10 years). The comparison with the ZX Spectrum isn´t half bad, because the era when they were designed is probably the same! Yes, the real ones have crappy resolution, a mind-numbing monochrome green and are slow to operate to boot. If other developers have "niced them up", then I would write that off to artistic liberty. Here is a shot of the real one: and this one wasn´t 75$ Cheers, Jan

When you press FL CHG or VNAV the autothrottle enters a "combined mode" - in most cases it will set climb thrust (N1) to fly the airplane to the next desired altitude. Try this - put the MCP altitude to below the aircraft and then click FL CHG. You will see that the autothrottle enters the combined mode of "retard - idle" and tries to descend. So yes, on the older software FMCs the throttles would advance to N1 limit thrust, and if the pilot is a total fluke, it would "take the aircraft to the air" (unless buildings or trees are in the way) The autopilot has no idea wether you are on the ground or not, you can even see it trying to fly a turn if you engage HDG SEL when you engage CMD on the ground... Jan

Just look into your scenery_packs.ini file and put a "_DISABLED" behind the "SCENERY_PACK" - that way you don´t have to move the relevant files. Jan

Hi Comet, sorry to hear about your crashes. I think there may be some kind of incompatibilitly here, most likely memory exhaustion. Cheers, Jan

Thank you for the report - we are working on curing all these errors. Bon Dia, Jan

Hi Phil, thanks for the nice words about the plane! ... The correct direction of speedbrake buttons and axis has been the cause for much debate. There is no consensus - as some say that "deploying" speedbrakes is akin to deploying flaps (down) - others say the speedbrakes go "up" to deploy - and then there is the physical motion of pulling the speedbrake lever "up" (from forward to pretty much vertical) but at the same time making a "down" motion with your mouse or hand (if you grab and pull it to you). I think now we are going with the "default X-Plane direction" (down to deploy, up to retract) since we didn´t change the assingment - which in my view is reversed. But we had a lot of complaints when the direction was reversed, and I think there is just no pleasing everyone. For now the easy solution is: Don´t fly any other planes ! Cheers, Jan

Yeah, 20% is the limit CFM gives you - meaning that you could probably go as low as 15% (for safety margin) without seeing any problem. Airplane operation is always geared to give you a good margin - things won´t go catastrophically wrong if you bust a limit by a small error. Jan

Yes, we made some simple attempts at simulating a hot start. You may also get a wet start if selecting that failure in X-Plane, and possibly a hung start (havent tried that). We are trying to use X-Plane´s engine model as much as we can - only scripting around it where needed. We are not trying to build our own simulator, just an add-on aicraft. So we (and you) will have to live with some of X-Planes limitations. It is up to Laminar to evolve certain aspects of the simulation, and beyond our scope. A simmers misconception about hot starts (and engine exceedance in general): The engines won´t spontaneously disintegrate if you exceed a limit, like getting 1000C during an engine start. Most likely an engine would run totally normal for thousands of hours after that. Yes, you need to have maintenance check if you exceed a limit, but you most likely wont see a fire, immediate failure or degraded performance. Boring, but realistic. Jan

Different ISA deviations´ effect on performance is not modeled for now - the effect is fairly small (for typical deviations) and X-Plane does not model certain aspects of ISA deviation (like true altitude changing, etc.) Jan