Litjan

Hi Michael - this does sound quirky... with no AP in CMD and only one FD on, this one should be Master, you are right... will investigate and fix. Jan

Still a useful report - in this case we should get a "BYPASS" instead of a reversal... will take a look. Jan

...and incidentially some battery power is required to connect the GPU (otherwise the relay won´t hold). Recharge the battery through the "failures" menu... Jan

Yes, we found out that there is a problem with cruising altitude 10.000 (as this is also the speed restriction altitude). We will fix this, for now you can avoid this by cruising higher or lower. Jan

Well, because when you set "typical" you get a "typical" fuel load. Which is most likely not what you have set up before. Jan

I would bet that it is a problem with your scenery...there was a problem with world2xp before that caused a crash... Jan

Can you post the Log.txt again when it crashes after you took out all your plugins, please? Jan

I realize that comes with the "PMDG" label - but you must also not forget that we are selling only a fraction of the units that PMDG is selling. So in fairness (assuming the same work done by us), we would probably have to ask a lot more than 75$ to even come close to the amount of profit that PMDG is making when selling for Prepared and FSX. Jan

If you get a crash to desktop then I would suspect that other plugins are causing a conflict. We had some problems with hardware interface plugins, JAR plugins, flywithlua, AI traffic plugins, etc... To troubleshoot you need to remove all your plugins (not just disable them), move them to another folder (you can later move them back) and then restart X-Plane. Let me know when you find the offending one? Thanks, Jan

This sounds like a heat problem - the other bane of Mac hardware. VNAV doing weird stuff is a known issue and we will work on it as soon as we can! Jan

I noted the request for a modified altitude alerter function. We have a few sound-fixes in for the next hotfix, please report back after that one? Thanks, Jan

Hi, we would need a lot more information to recreate and fix this - can you read the "bug reporting guide" in the documents to help us out, please? Thank you very much, Jan

Thanks guys for these nice words, on the behalf of the whole IXEG team! We know that the plane isn´t perfect and some features are still missing - but we think that it already is in a state where you can really enjoy it - and hope that our customers feel the same. Fixes and additions are coming - and you, the community - have and will bee integral in helping us shape this into the perfect rendition of a 737-300. Please stay active in these forums, nag, whine, critique and occasionally commend our work . Thanks from everyone at IXEG!

check your anti-virus programs and disable them to test the effect. (Windows defender, etc.) Thanks, Jan

Hi Slayer, that is not what I see. I can select all numbers just fine (even or odd...) Jan

Its a known issue - sometimes the plane boots without any fuel - so the APU dies immediately. This will be fixed in the next patch. Jan

The problem is that the description of the SID is giving most FMCs a hard time. The SID was clearly coded for overloaded Soviet prop airliners - they would fly a few mile ahead until reaching 1300´, then have ample of space to make a right turn back to MNS and then track the VOR outbound. Most twin-engine jets will make 1300´ (which is only 600´above the aerodrome!) within 1NM of starting their take-off run. Then they will never be able to circle back to MNS - they are simply still too close (turn radius is too big). Of course a pilot will "know" what to do. He will pass south of MNS and then just keep turning until intercepting the radial. But an FMC is not smart enough (yet) - it will simply figure out that it can´t make the turn, BYPASS (disregard) the waypoint in question (MNS) and then happily go with the next task at hand (intercept R-241). So in conclusion - correct behaviour by IXEG and FF, just one those "weird" SID´s that modern FMS systems still have problems with... Jan

Will forward this - thanks! Jan

Thanks for the reports, everyone! We will take a look and see what we can find out! Jan

Excellent, thanks!

Hi, this is correct, the FL CHG mode will switch at a different point than the FMS. I am not sure what the underlying logic or algorithm is, we simply tried to mimic what the real plane does. The FMS switchover is a bit more involved - the FMS knows what the desired "new" speed is, and can switch over at the exact right altitude. The FL CHG has no idea what kind of MACH no. the pilot wants to fly after switchover, so it just does it at a "safe" speed. It´s up to the pilot to catch this switchover and adjust if desired. Jan

http://forums.x-pilot.com/forums/topic/10166-slowing-down-braking/

Hi sirtopper, the engine driven pumps are variable-dispacement piston type axial pumps and they can output 3000 psi at very low rpms. If you would run a lot of consumers (i.e. flaps, gear) at this low rpm you could probably see pressure drop a bit sooner. Theoretically (no leakage) you could even maintain pressure in a closed system without any type of pump action (think of the brake pressure accumulator), but I think we timed the pressure drop to the rpm after the real aircraft. Jan

Hi Bruce, the ESC is the "Eurovision Song Contest" held yesterday in Stockholm. Off-topic banter ;-) Be aware that Mac computers have a function that vastly decreases CPU frequency when they get too warm. They seem to be more prone to this than "normal" computers, so what they lack in raw computing ability they make up in style and design, it seems . One of our developers also had this problem and solved it by putting one of these cooling pads underneath. Could this be the case in your random slow-downs? Jan

Not "bad" at all - I invite all reports like that - even if they later turn out to be "working as intended". Report everything - then we will sort out what´s quirky and whats not! Keep ´em coming, please! Jan