AUTOPILOT INCREMENTS

[Johnson]

Hello Peter,

I know this is an old problem, but it keeps rearing it's ugly head. I have designed several panels for FS2004, all of which can be found at various sites.

I am currrently working on a B727-200 panel, while beta testing yesterday and doing an ILS approach vectored by ATC, I found that the autopilot airspeed and heading would only allow 10 degree adjustments and the altitude 100 feet.

This is most annoying, especially when I am using the same autopilot gauges from my previous B717-200 which works perfectly.

Why does this happen? Is it something in the airfile of the aircraft

I am running FSUIPC 3.1(unreg) WinXP Pro AMD 2100 700meg RAM

FS.cfg has had [OLDMODULES] [FSGAUGES] and [FSSOUND] added.

As a designer I find this continual problem frustrating and adds considerable time in development.

Please help me to permanently rid me of this problem

Regards

Steve Southey

Australia

[Pete Dowson]

This is confusing. Did you write to Project Magenta support with the same questions? This looks identical, so I'll repeat my replies for the benefit of other readers -- though you will actually find your answers in one or other of the threads already here. One quite recent one, in fact.

I found that the autopilot airspeed and heading would only allow 10 degree adjustments and the altitude 100 feet.

... Why does this happen? Is it something in the airfile of the aircraft

No, it is caused by some bad gauge programming somewhere.

Microsoft have been very specific about this. I consider it a weakness in the design of part of FS, but they say that if folks designed their gauges correctly it wouldn't happen. Therefore it won't be "fixed".

The acceleration from units of 1 to units of 10, or whatever, is triggered by a second control following the first within so many milliseconds. I'm not sure of the actual interval off-hand, but it relates to normal keyboard

repeat rates and so on, so is around 30-40 mSecs.

Really, I think the acceleration should ONLY occur if the second control,

arriving so close, is the SAME control as the earlier one. But for "efficiency" (if you like) MS don't bother to check. They just assume that if two controls arrive so close together they MUST be the same. After all, if they are being generated by user action, there's no way he could change so fast, right?

The culprit gauges seem to be those which, for some reason best known to their authors, send controls to FS continuously at ridiculous rates, many

every second.

The first panel in which I met this was the 767PIC on FS2002, which is when I added the "acceleration fix" into FSUIPC. For some daft reason that panel was sending controls like AP off 20 or 30 times a second! No wonder some of these panels slow FS down so much! So much waste!

Unfortunately it seems that, with the development now of XML gauges, my fix (which merely fiddles FS's acceleration timer if it sees a control which is different from the previous one) doesn't work with all gauges. The XML gauge "events" bypass the method I use to detect them.

I am running FSUIPC 3.1(unreg) WinXP Pro AMD 2100 700meg RAM

Ah, not FSUIPC 3.61 as in the email! :wink:

Please note that the current version is 3.44. I really cannot support old versions, especially as old as that! Anyway, FSUIPC isn't relevant. Take it out and you'll get the same results.

FS.cfg has had [OLDMODULES] [FSGAUGES] and [FSSOUND] added.

Why?

Please help me to permanently rid me of this problem

Just stop writing gauges which continually send controls to FS. There should be no need. At least test values before sending controls to see if they would actually do anything useful. Things like setting the A/P off 20 times a second are daft if the A/P is off already. Et cetera.

Regards,

Pete

[Pete Dowson]

Further to this:

Unfortunately it seems that, with the development now of XML gauges, my fix (which merely fiddles FS's acceleration timer if it sees a control which is different from the previous one) doesn't work with all gauges. The XML gauge "events" bypass the method I use to detect them.

I have now completed work on a modification to FSUIPC, on FS2004 only, which will hopefully deal with the problem on XML gauges too -- via the same "fix control acceleration" option of FSUIPC's Technical tab.

If you are still having problems, and have registered FSUIPC, send me an email (petedowson@btconnect.com) if you want to test an interim version of FSUIPC with this improvement incorporated. (I can't test that it works flawlessly here because I don't seem to have any of the acceleration problems with any of the panels I have, in any case).

In addition to this extension to the fix I have added an event logging option which should help gauge authors see exactly what is happening when their gauge is running and thus be a help in trying to make the more efficient.

Regards,

Pete