Hi,

I saw in another thread that only one combo button is possible, right?

On the Honeycomb Bravo I have a selector and a rotary, but both are buttons. 

I set the selector on "HDG" and add as a combo button, and the fake rotary as Assigned button. Now, I would like to be able to change heading by 10 degrees or 1 degree. Easiest would be with a second combo button.

Right now I've made two assigned buttons, same button and combo button, but one with Fast Turn (20 ms) that turns more times. Is it possible to lower Fast Turn below 20 ms?

 

Do you know a better solution, maybe a function I've missed?

 

Are there any way to add a check in the script to see if another button are pressed, or can the script only receive one command (i.e. (L:Scripts-Heading_Bug)·(>K:HEADING_BUG_INC) )?

Does the script purge after every command, or would it be possible to make a counter that counts how many presses it gets within a specific time?

Fake syntax, but:

 

loop (5 times)

if (L:Scripts-Heading_Bug)!=0 then

X=X+1

wait (10ms)

end loop

 

If X>3 then

(>K:HEADING_BUG_INC|10)

else (>K:HEADING_BUG_INC)

1 hour ago, Jackiie said:

Do you know a better solution, maybe a function I've missed?

I think that scripting is the way to go. Use the button to set LVars of your choice to certain values, and trigger a "main" script that executes the desired action(s)
For example, the rotary encoder sets an LVar "(L:SelectorPosition)" to values 1-5. Then you bind another script to your "action" button(s) that reads this lvar and triggers the desired action. If you need that combo, add more scripts and LVars that you then combine in you main script using stacked if{ etc.

What is the use case for your second question? In general, you would do something like that with an aircraft automated script and a second one counting the KeyDowns. That being said - you cannot go lower than 100ms between scripts, and 55ms between button presses (fast turn is different, but not by much - the 20ms are just a threshold, there is no telling if the logic will actually catch up with that). Plus, at the moment you cannot access the current system timestamp, only the simulator time. That may be to coarse or too unreliable.
In general I would advise againt logic that tries to time things in the low millisecond area. AAO isn't designed for that, the internal logic is not fast enough. There is just too much to do for the app, and the need to synchronize with the processing speed of the simulator (it is quite easy to overload SimConnect and thus crash it or the sim).

 

Edited August 19, 20223 yr by Lorby_SI

1 hour ago, Jackiie said:

Are there any way to add a check in the script to see if another button are pressed,

Set an LVar and query it

1 hour ago, Jackiie said:

loop (5 times)

Scriptfile

0 (>L:counter)
:counterfornext
(L:counter) ++ (>L:counter)
(L:counter) (SPEAK:variable value is %1)
(L:counter) 5 < if{ (GOTO:counterfornext) }
(SPEAK:finished counting)
(END)

or multiline script

0 (>L:counter) \n
:counterfornext \n
(L:counter) ++ (>L:counter) \n
(L:counter) (SPEAK:variable value is %1) \n
(L:counter) 5 < if{ (GOTO:counterfornext) } \n
(SPEAK:finished counting) \n
(END)

Edited August 19, 20223 yr by Lorby_SI

3 hours ago, Lorby_SI said:

hat is the use case for your second question? In general, you would do something like that with an aircraft automated script and a second one counting the KeyDowns. That being said - you cannot go lower than 100ms between scripts, and 55ms between button presses (fast turn is different, but not by much - the 20ms are just a threshold, there is no telling if the logic will actually catch up with that). Plus, at the moment you cannot access the current system timestamp, only the simulator time. That may be to coarse or too unreliable.
In general I would advise againt logic that tries to time things in the low millisecond area. AAO isn't designed for that, the internal logic is not fast enough. There is just too much to do for the app, and the need to synchronize with the processing speed of the simulator (it is quite easy to overload SimConnect and thus crash it or the sim).

 

Thanks for all the answers, I'll read into them more when I'm not in a hurry, but for this specific case:

Right now I've set so that when I "rotate" (in reality, press the same button many times), it'll send the value 1. When I "rotate" fast enough, another, almost duplicate "Assigned Button" will send 10 instead, but only if the button presses are faster than 20 ms. This way, when I need to go from e.g. 120 to 275 degrees, I "rotate"/push fast, and it moves 10 every time. When I'm closer, I'll do it slower, and move in increments of 1. I have to say, it's working fairly well.

On 8/19/2022 at 2:14 PM, Lorby_SI said:

Set an LVar and query it

This has actually helped, but I haven't totally grasped it. Do I need a separate script for every LVar I want to set from a button, as my example below, or could I somehow put them in the same script?

Script1 (for button 1)

(L:Scripts-Script1) (>L:FirstVar)

Script2 (for button 2)

(L:Scripts-Script2) (>L:SecondVar)

Script3

(L:FirstVar) (L:SecondVar) == if{

55 minutes ago, Jackiie said:

This has actually helped, but I haven't totally grasped it. Do I need a separate script for every LVar I want to set from a button, as my example below, or could I somehow put them in the same script?

Script1 (for button 1)

(L:Scripts-Script1) (>L:FirstVar)

Script2 (for button 2)

(L:Scripts-Script2) (>L:SecondVar)

Script3

(L:FirstVar) (L:SecondVar) == if{

That would depend on what it is that you want to do. There is no clear answer. 

If a button needs to do something specific, it also needs its own script. I don't understand what you mean by "somehow put them in the same script". What is that supposed to achieve? 
You either hard code the scripts for each individual button
1 (>L:ComboVal)
2 (>L:ComboVal)

Or you use one single script and change the button value in the assignment itself (numerical box to the right of the event selection)
(L:scriptgroup-scriptname) (>L:ComboVal)

Your main button then reads the ComboVal and acts accordingly.

(L:ComboVal) s0 
l0 1 == if{ ...do action one } 
l0 2 == if{ ...do action two } 

etc.

But as I said, I don't really understand what you are trying to do. I can only strongly advise against overusing the Combo-Logic. You not only need to configure it - you also have to remember what button combination does what. I sure couldn't do the latter, I only use combos in those cases where you need "small and big changes" on the same rotary encoder. And for that a single combo button is enough. I wouldn't be able to memorize combinations of a lot of combos, let alone three or more buttons working together.

Edited August 20, 20223 yr by Lorby_SI

I've actually ordered an Xtouch Mini as I'm out of good buttons and rotaries - I'm using buttons on the yoke with my left hand for enter/clear/direct right now... While combo units work for me, they take a lot of time when I need to suddenly change altitude instead of COM frequency.

 

The earlier question  is for fuel selectors. They don't have an individual state for each in this plane - e.g. 0,1 for left, 0,1 for right, but instead 0,1 for both on, both off and 2,3 for only left/only right.

Therefore, as I still want two switches for them, I'll need to check left switch and right switch on my Bravo, to see which state I should set. Right now I'm making three scripts - two short ones for just assigning variables, one for making the choice for the fuel selector state. I would save two scripts if I could assign a button to a variable without writing a script. Still mostly learning possibilities and limitations of the MSFS, AAO and the whole syntax.

Thanks again for all the support, it really helps

If I set a variable, e.g. FLeft in one script, will that variable keep its number when I call it from another script?

I got those two script, each called by a switch (up=1, down=1 for respective switch and script).

(L:Scripts-Fuel_Left_var)·(>L:FLeft)

(L:FLeft)·(L:FRight)·==·if{
(L:FLeft)·1·==·if{
·1·(>K:FUEL_SELECTOR_SET)·}
els{·0·(>K:FUEL_SELECTOR_SET)·}}

(L:FLeft)·(L:FRight)·!=·if{
(L:FLeft)·1·==·if{
·2·(>K:FUEL_SELECTOR_SET)·}
els{·3·(>K:FUEL_SELECTOR_SET)·}}

(L:Scripts-Fuel_Right_var)·(>L:FRight)

(L:FLeft)·(L:FRight)·==·if{
(L:FRight)·1·==·if{
·1·(>K:FUEL_SELECTOR_SET)·}
els{·0·(>K:FUEL_SELECTOR_SET)·}}

(L:FLeft)·(L:FRight)·!=·if{
(L:FRight)·1·==·if{
·2·(>K:FUEL_SELECTOR_SET)·}
els{·3·(>K:FUEL_SELECTOR_SET)·}}

With "Watch AAO Script processing" I can see that FLeft and Fright changes when calling the specific script, but if I've used script one and go to script two, which changes FRight, FLeft gets set to 0 again, even if it was left on 1. Not sure what I'm doing wrong, or if that is a limitation of variables within the program - are they purged when starting to call other scripts?

7 hours ago, Jackiie said:

With "Watch AAO Script processing" I can see that FLeft and Fright changes when calling the specific script, but if I've used script one and go to script two, which changes FRight, FLeft gets set to 0 again, even if it was left on 1. Not sure what I'm doing wrong, or if that is a limitation of variables within the program - are they purged when starting to call other scripts?

All variables are reset when you close the RPN Editor. In production (=when you don't use the editor anymore) the variables keep their value until you switch to another aircraft (or reload the current one). So when you test this, make sure to use real button assignments, and not the "Test" button in the editor.

Also, make sure that your Scripts aren't the ones that are resetting the variables to 0 somewhere. Surely you must do that at some point? Otherwise, once set, the LVar is set to 1 forever?

Btw. "}}" is invalid, there must be a space character between the braces "}·}". The editor will probably accept it, but it is syntactically wrong. Out of habit, I also put space characters at the end of each line, because in the end, a script is always compiled into one single line (unless you make a multiline script, see manual)

Edited August 21, 20223 yr by Lorby_SI

I solved it, one part was me wrong, one part worked weird, which I don't understand. I had switched when to send a 2 and a 3 to FUEL_SELECTOR_SET, but it still read the wrong number from my Lvars FLeft and FRight.

Changing

(L:Scripts-Fuel_Left_var)·(>L:FLeft)

(L:FLeft)·(L:FRight)·==·if{
(L:FLeft)·1·==·if{
·1·(>K:FUEL_SELECTOR_SET)·}
els{·0·(>K:FUEL_SELECTOR_SET)·}·}

(L:FLeft)·(L:FRight)·!=·if{
(L:FLeft)·1·==·if{
·2·(>K:FUEL_SELECTOR_SET)·}
els{·3·(>K:FUEL_SELECTOR_SET)·}·}

 

to

(L:Scripts-Fuel_Left_var)·(>L:FLeft)

(L:Scripts-Fuel_Left_var)·(L:FRight)·==·if{
(L:Scripts-Fuel_Left_var)·1·==·if{
·1·(>K:FUEL_SELECTOR_SET)·}
els{·0·(>K:FUEL_SELECTOR_SET)·}·}

(L:Scripts-Fuel_Left_var)·(L:FRight)·!=·if{
(L:Scripts-Fuel_Left_var)·1·==·if{
·2·(>K:FUEL_SELECTOR_SET)·}
els{·3·(>K:FUEL_SELECTOR_SET)·}·}

 

made it work. For some reason, writing to (>L:Fleft) first and then calling it in the same script shows in "Watch AAO script processing" that it do change (>:Fleft), but still uses the variable state it had when initiating the script. So calling with a 1 shows that (L:Scripts-Fuel_Left_var)·(>L:FLeft) writes a 1 to (>L:FLeft), but then compares (L:FLeft)·(L:FRight)·==·if{ with FLeft being 0-

Reading directly from the state I sent with the button ( (L:Scripts-Fuel_Left_var)·) fixed it. Bug or is that how it works, or another user error?

 

I do send 1 with switch up, 0 with switch down, so I do reset it, which I could see in "Watch AAO".

8 minutes ago, Jackiie said:

Bug or is that how it works

This is how it works. You cannot change a variable value and then read from it in the same script. You would have to either (SPLIT:100) it (then the part after the SPLIT is a new script that gets the new variable value, or use multi line scripts with \n (where every line is a script in itself).

Or use the registers (s/l), those are local to the script code.

(L:Scripts-Fuel_Left_var)·s0·l0·(>L:FLeft)·
l0·(L:FRight)·==·if{·l0·1·==·if{·1·(>K:FUEL_SELECTOR_SET)·} els{·0·(>K:FUEL_SELECTOR_SET)·}·}·
els{·l0·1·==·if{·2·(>K:FUEL_SELECTOR_SET)·} els{·3·(>K:FUEL_SELECTOR_SET)·}·}·

In this script, the script variable is stored in register "0" with s0, then written to the LVar. In the rest of the script instead of reading the Lvar I read the value from the register with l0 (that is "ell zero", not "ten").

Alternatively you could also have used the script variable in your code instead of FLeft...

Edited August 22, 20223 yr by Lorby_SI