That's much easier to read; unfortunately it makes no real sense... :(

I'm not sure it makes sense either... as I said up front, I would much prefer

<Click>   (>K:AP_ALT_HOLD)   (A:AUTOPILOT ALTITUDE LOCK,bool) 0 == 	   if{ (>K:AP_ATT_HOLD_ON) }</Click>

but the fact is that the following code, however cumbersome, gets the job done.

<Click>	(A:Autopilot Nav1 Lock,bool) (>L:NAV,bool)	(A:Autopilot Heading Lock,bool) (>L:HDG,bool)	(>K:AP_ALT_HOLD)	(A:AUTOPILOT ALTITUDE LOCK,bool) 0 == 		if{ (>K:AP_ATT_HOLD_ON) } 	(L:NAV,bool) 0 != 		if{ (>K:AP_NAV1_HOLD_ON) }	(L:HDG,bool) 0 != 		if{ (>K:AP_HDG_HOLD_ON) }</Click>

I'm still waiting for someone to post a more elegant solution (that also works) :(

Are you using those Lvars anywhere else in the code, if not just do away with them.

<Click>	(>K:AP_ALT_HOLD)	(A:AUTOPILOT ALTITUDE LOCK,bool) 0 == 		if{ (>K:AP_ATT_HOLD_ON) }	(A:Autopilot Nav1 Lock,bool) 0 != 		if{ (>K:AP_NAV1_HOLD_ON) }	(A:Autopilot Heading Lock,bool) 0 != 		if{ (>K:AP_HDG_HOLD_ON) }</Click>

I'm having trouble understand exactly what you want to do so coding it exactly the wait you want it is subsequently troublesome to me. :(

Are you using those Lvars anywhere else in the code, if not just do away with them.

First of all, thank you! I tried it and indeed it works...

<Click>	  (>K:AP_ALT_HOLD)		 (A:Autopilot Altitude Lock,bool) 1 ==			if{ (>K:AP_ATT_HOLD_ON) }		(A:Autopilot Nav1 Lock,bool) 1 ==			if{ (>K:AP_NAV1_HOLD_ON) }		 (A:Autopilot Heading Lock,bool) 1 ==			 if{ (>K:AP_HDG_HOLD_ON) }</Click>

So, I must have a fundamental misconception of how the XML logic is executed.I thought that it was all sequential: When the AP ALT HOLD gets toggled and the HDG and NAV get turned off,that the variables would also change and not be retrievable, unless I saved them into somelocal variables first.Does this mean that everything within the Click section is evaluated as if the AP HOLD togglehas not yet happened? (Note I changed the test from 0 to 1 to reflect that..) Or, are we taking advantage of the fact that variables change at "simulation speed" and that wecan get at them before the simulation has had a chance to change them?

Everything is executed sequentially.Your "mouse click" triggers the sequence:1. Turn on Altitude Hold2. If the Altitude Hold is ON, turn on the Attitude Hold3. If the Nav1 Lock is ON, turn on Nav1 Hold (Lock)4. If the Heading Lock is ON, turn on Heading Hold (Lock)Steps 3 and 4 are the ones that really make no sense to me. It's like saying "if the light is on, turn the light on..."Just because the A:vars and the K:events use different words, they are -in fact- referencing the same things, as I've shown with the parenthetical remarks. :(BTW, this sequence: (A:Autopilot Nav1 Lock,bool) 0 != if{ (>K:AP_NAV1_HOLD_ON) }is functionally equivalent to: (A:Autopilot Nav1 Lock,bool) 1 == if{ (>K:AP_NAV1_HOLD_ON) }However, according to the nice folks at ACES, when dealing with boolean variables, the only value that can be guaranteed to be reliable* is ZERO......hence my tendency to rely more on "not equal zero" instead of "equals zero," since the "non-zero value" might be either -1 or +1... :(NOTA BENE: ACES does not explain why non-zero boolean values can sometimes be -1, but they insist that it does occasionally happen. Perhaps it's dependent on the phase of the moon, or tectonic plate movements... :(

Step 3 & 4 serve to keep the NAV1 LOCK & HDG HOLD on as before when he would enable ALT HOLD it would turn off NAV1 LOCK and HDG HOLD and turn on WING LEVELER.But since you're saying ALT HOLD is done first, then it would turn those off and the code below it would be rendered useless. That doesn't seem to be the case, it seems that when he clicks the code checks to see if NAV1 LOCK is on and HDG HOLD is on and if they are on at the time of the click then they stay on.

Step 3 & 4 serve to keep the NAV1 LOCK & HDG HOLD on as before when he would enable ALT HOLD it would turn off NAV1 LOCK and HDG HOLD and turn on WING LEVELER.But since you're saying ALT HOLD is done first, then it would turn those off and the code below it would be rendered useless. That doesn't seem to be the case, it seems that when he clicks the code checks to see if NAV1 LOCK is on and HDG HOLD is on and if they are on at the time of the click then they stay on.

That is the mystery to me also... I've now tested enough different versions of this code to believe that1. Altitude Hold is toggled (lets say it was OFF)2. If it is toggled ON, the Altitude Lock simulation variable does not know it yet... so testing for it, returns OFF3. Altitude Hold in turn toggles HDG or NAV off, but the variables do not know it yet... so testing for it, returns what ever it was at the time of the Mouse Click.... I'm left thinking that employing the temporary variables and testing for Zero / Non-zero is the only reliable way to go...But I'm wasting a couple of assignments that maybe are not required.. :(

But it is working right?Sometimes you've just gotta let the code have it's way I guess. :( Good luck mate.

But it is working right?Sometimes you've just gotta let the code have it's way I guess. :( Good luck mate.

Yes, I've got it working, and I've learned a lot in the process!Thanks for the pointers!

Yes, I've got it working, and I've learned a lot in the process!Thanks for the pointers!

Well Bert inspired me to mess with the fs autopilot tonight-I have been trying to get a real working Century IV for a number of years.I got a semi functional one going based on Bert's that works in a broken fashion-though still having problems with button presses.It appears at least to me .xml/fs wise that there are some severe limitations. For instance, one should be able to track outbound on a loc or nav course using the Rev button-it appears fs ties Rev and Appr together only e.g. press rev and appr comes on. You should also be able to use appr to track a normal nav course more precisely than nav..doesn't seem to be an option. Also, on my autopilot GS should be separate from appr-appr automatically captures glideslope if within parameters-if not a manual press of Gs captures glideslope -there does not seem to be an option for that. Go around which pitches to best single engine climb speed looks like it can be faked but not really. Then a function like hitting heading and appr at the same time which allows turning with hdg mode till the autopilot recognizes appr and automatically switches to appr/glideslope seems well beyond the capabilites of the xml.How does one get a real working autopilot in fs-does programming in some other language other than xml accomplish this?I am desperate to get a real working one for myself!

Then a function like hitting heading and appr at the same time which allows turning with hdg mode till the autopilot recognizes appr and automatically switches to appr/glideslope seems well beyond the capabilites of the xml.How does one get a real working autopilot in fs-does programming in some other language other than xml accomplish this?I am desperate to get a real working one for myself!

Hdg-Nav intercept mode can be done. I've done it in C+ for the STec55X used in the Cirrus and Columbia 400 models. Likewise, Hdg-Apr intercept mode can be programmed.Similar results can be obtained in XML script. While not at liberty to post the actual code, I can at least outline the basic procedure used.

1. Hidden mouse point to select Hdg-Nav intercept mode.2. Synch the Hdg bug to the current heading3. Compute the cross track distance from the desired nav radial4. When less than 10nm from the desired nav radial, slowly increase/decrease the Hdg bug as required to initiate a slow turn towards the desired nav radial.5. When less than 1nm from the desired nav radial, switch to Nav mode.

The routine can also be scripted to work with either Nav or GPS active. IOW to intercept either a VOR radial or a GPS active leg.Similar script may be created to intercept a localizer also.