Litjan

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

Ok, this certainly does not sound like the cases I described - they would all have the LOC deviation pointer centered. I could also imagine a strong shift in winds - the gain (how hard the AP tries to track the LOC) is reduced when closer to the ground - otherwise the AP would get too twitchy and hectic. This is analog to the real aircraft, and a reason why automatic approaches are limited to 10kts of crosswind. There is also the need for the Pilot Monitoring to watch the deviation scales and call for a go-around if deviation exceeds 1/4 dot LOC or 1/2 dot GS (iirc), because this exact same think can happen with shifting winds in real life. If it happens to you again, try to capture a screenshot (with the FMA showing), or possibly even a short movie (I am using ShadowPlay so I can capture the "last two minutes" with a press of a button). Thanks again, Jan

Hi Charles, again, thanks for the feedback, both positive and constructive ;-) We are very aware of our shortcomings - and although it has been a bit more "quiet" on the update front in the last few weeks, we are at work on the the first big comprehensive update (no ETA yet). I expect to scratch quite a few items off the "not in 1.0" list for that, and you may have seen a teaser shot of the new TCAS, for example. The problem with the LOC signal not leading you down to the centerline can probably be attributed to (95%) bad X-Plane navigational data - usually the runway is misplaced by a bit. Go to your local map and zoom in on the runway (with display of ILS´s selected), then you can see how well the LOC lines up with the runway. The remaining 5% are attributed to deliberately offset LOC approaches (like KFLG, for example). Happy landings, Jan

Hi Charles, First, thanks for the nice words in your initial post. And yes, there is still lots to do on this aircraft, and we are well aware and working on it ;-) you are correct - the 737-300 is not certified for LNAV/VNAV approaches (to my knowledge) - you have to fly the RNAV in LNAV and V/S, using the deviation bar like a "glideslope". At least that´s how we did it when I still flew the 737. Cheers, Jan

So far every single instance of this happening could be traced to a "live virus scanner" type software that is interfering with the in-out database accessing that is running while the route is in a MOD state. I am a bit surprised by rgeber´s report because he specificially states that he has no anti-virus running...But that was the only report of that kind we ever got. Cheers, Jan

Huh, that is strange - we are forcing the switchover once past a certain altitude - so I wonder what happend. Thanks for the report, we will try to recreate (and fix) this! Cheers, Jan

Hi Pierre, we are experiencing some difficulties with this in 1.0.7 - so what you are seeing is under investigation! Thanks for the report, Jan

The DH should always be set to the same value - after all it is just one aircraft doing one approach that only has one DH . The DH is only used for CAT II and CAT IIIa approaches - so they should be set to the value specified in the approach charts for CAT II (usually around 100) or to 50´ for CAT IIIa autoland approaches. For all other approaches, set both to -20. Jan

Hit the "W" key... Jan

Yes, this will work if the angle is not too large - the plane will adjust for the drift. But if the set course is grossly wrong, the plane will turn "off" the localizer signal and then have no way of recapturing the centerline. Jan