Pausing briefly in order for property change to catch up

[wonko]

Is there a nasal command to pause briefly for a set time interval in ? I did a quick google search but could not find anything.

Background:

I am trying to set up some joystick buttons for controlling the KAP140 autopilot. In particular, two buttons are used to control the vertical velocity. For example, the script for the down button looks like this:

Code: Select all

kap140.downButton();
         if ( getprop("autopilot/KAP140/locks/pitch-mode") == 1 )  {
            gui.popupTip(sprintf("AP VS %d",getprop("autopilot/KAP140/settings/target-pressure-rate-fpm")));
         }


This mostly works, but the VS indicated on the popup is the setting before pressing the button rather than the value it has been set to. On the property browser the change of the target-pressure-rate-fpm value appears essentially instanteneous. Without any real understanding of how the KAP140 autopilot is implemented I presume the kap140.downButton() actually initiates the change, but this is not completed by the time Nasal reaches the gui.popupTip command. So hopefully if I wait 5ms or so, then the property would have changed to the new value.

If somebody has a more elegant solution to this problem rather than a direct answer to the question, I would of course appreciate hearing about this, too

[Philosopher]

mini stack-overflow Q/A

It appears the autopilot uses a property rule (run every frame IIRC) to write to *-fpm from target-pressure-rate (with a gain of of -58000). Try using the property with the gain, i.e.:

Code: Select all

getprop("/autopilot/KAP140/settings/target-pressure-rate")*-58000

P.S. the corresponding function is settimer(fn, time_seconds);

[Hooray]

Listeners cause indirection - so as long as the corressponding properties are not tied, you could probably even use a listener to "hijack" the control flow and do something else - we were using that method to even execute Nasal per FDM iteration - so it works fairly well - you can use/make up your own properties, or simply check /sim/signals (e.g. the frame signal should work fine probably)

[wonko]

Philosopher's suggestion worked well so I did not yet have to delve into listeners. Thanks to both