I can't get the AP to hold altitude or hold vertical speed. The AP itself is available and active. For vertical speed I've tried various combinations ofKEY_AP_VS_ON/OFF/SET/HOLDKEY_AP_VS_VAR_SET_ENGLISHKEY_AP_PANEL_VS_ON/OFF/SETFot altitude hold I've tried combinations ofKEY_AP_PANEL_ALTITUDE_HOLD/ON/OFF/SETKEY_AP_ALT_ON/OFF/HOLD/SETKEY_AP_ALT_VAR_SET_ENGLISHIn all cases neither altitude hold nor vertical speed hold works. I haven't tried capturing a specified altitude yet but I'll bet that doesn't work either. I absolutely have to have overlooked something simple.... but what?-Dai

VS autopilot doesn't work. I've never, ever gotten it to work.As for ALT hold... KEY_AP_ALT_VAR_SET_ENGLISH sets the desired altitude in feet... and then KEY_AP_ALT_HOLD_ON activates it.

VS hold worked for FS2K2 but that was the last time I used it. However, there was a catch - you needed to set KEY_AP_PANEL_ALTITUDE_ON as well. That trick doesn't seem to work with FS9 or FSX. I'll have another go at KEY_AP_ALT_VAR_SET_ENGLISH and KEY_AP_ALT_HOLD_ON when I get home.-Dai

Very strange, I

I've solved the ALT_HOLD problem but not VS_HOLD (yet.... I hope). Danny - you were almost right. I have built in a debugger to this aircraft and I actually got round to using it (gah! - I sometimes think 'idiot' is my middle name). The logfile showed up the problem immediately: FS switches the AP on when commanded, my autopilot code kicks in, FS decides it really doesn't want to use AP on this pass and turns it off without any instruction from me, my autopilot code switches off and then FS changes its mind again.... but at this point my autopilot code is in an indeterminate state because it 'thinks' the AP should be off. An additional minor check later around the code's 'off' states and it now deals with FS's ridiculous behaviour okay.I'll update when I solve the vspeed problem. At the moment it's behaving exactly as Ed states; my debugger logfile shows the required vspeed is being captured and VS_HOLD is switching on but the live update part of the debugger shows both of these being ignored.-Dai

I've solved the ALT_HOLD problem but not VS_HOLD (yet.... I hope). Danny - you were almost right. I have built in a debugger to this aircraft and I actually got round to using it (gah! - I sometimes think 'idiot' is my middle name). The logfile showed up the problem immediately: FS switches the AP on when commanded, my autopilot code kicks in, FS decides it really doesn't want to use AP on this pass and turns it off without any instruction from me, my autopilot code switches off and then FS changes its mind again.... but at this point my autopilot code is in an indeterminate state because it 'thinks' the AP should be off. An additional minor check later around the code's 'off' states and it now deals with FS's ridiculous behaviour okay.I'll update when I solve the vspeed problem. At the moment it's behaving exactly as Ed states; my debugger logfile shows the required vspeed is being captured and VS_HOLD is switching on but the live update part of the debugger shows both of these being ignored.-Dai

DaiIn XML I use (>K:AP_VS_VAR_SET_ENGLISH,feet/minute) for VS with (>K:AP_PANEL_ALTITUDE_ON) to trap alt set in alt var setting window

Hi,May be off topic, but it becomes really interesting when you start using Pitch Hold, Pitch Inc.- and Decrease.This together with Att Hold when you reach the desired position is interesting when you want to climb with a certain amount of thrust.Then the IAS can regulate the pitch attitude and so the vertical speed.Coding is quite complicated to avoid K-events firing, but it works ok.Also in autoland you can use those functions.I think in the past this was also a topic:http://forums1.avsim.net/index.php?showtop...p;hl=pitch+holdjan

Jan, that

Good catch Jan. I'm working through the info in that thread with the intention of adding some of it to the next issue of sd2gau. I really should have remembered the altitude trick for VS_HOLD; it works perfectly, as always.-Dai