Jump to content
The simFlight Network Forums

Recommended Posts

Posted

My understanding is if you recall a Lua script while it is running, the first instance of the script is immediately killed, and the script is restarted.

Is there a way to modify this behavior, such that the running script will ignore any repeated calls until it has completed?  What I'm trying to do is use a script to repeatedly increment a sim value while a key is held down until the current target value (which is displayed) is reached. The script is very simple, it just reads the existing Lvar value, adds 100 to it, and writes the new value back.

Thanks,

Al

Posted
16 minutes ago, ark1320 said:

My understanding is if you recall a Lua script while it is running, the first instance of the script is immediately killed, and the script is restarted.

Yes.

16 minutes ago, ark1320 said:

Is there a way to modify this behavior, such that the running script will ignore any repeated calls until it has completed?  What I'm trying to do is use a script to repeatedly increment a sim value while a key is held down until a displayed target value is reached. The script is very simple, it just reads the existing Lvar value, adds 100 to it, and writes the new value back.

No, sorry - I cannot modify this behavior for all users and all lua scripts one specific use case...there will be a lot of set-ups that depend on this behavior. Ignoring a call to start a lua script seems like a very bad thing to do in any case and would cause many issues.

But I don't understand why you would want to do this anyway, even for what you are trying to achieve.  Why not just use an event.key function? You can also add a event.timer that would terminate the event.key if no keypress seen within a certain amount of time (and also kill the timer and so exit the lua script, if that is what you want to achieve).

John

Posted
59 minutes ago, John Dowson said:

Yes.

No, sorry - I cannot modify this behavior for all users and all lua scripts one specific use case...there will be a lot of set-ups that depend on this behavior. Ignoring a call to start a lua script seems like a very bad thing to do in any case and would cause many issues.

But I don't understand why you would want to do this anyway, even for what you are trying to achieve.  Why not just use an event.key function? You can also add a event.timer that would terminate the event.key if no keypress seen within a certain amount of time (and also kill the timer and so exit the lua script, if that is what you want to achieve).

John

Guess I was not clear. I was not asking for anything to be modified for ALL users, but rather if there was technique I might use for my particular situation.  I will look into the event.key function idea -- thanks!

Thanks.

Al

Posted
Just now, ark1320 said:

Guess I was not clear. I was not asking for anything to be modified for ALL users, but rather if there was technique I might use for my particular situation.

Ah, sorry - misread/understood your request.
You could look into adjusting/increasing the LuaRerunDelay parameter - see the Advanced User Guide:

Quote

LuaRerunDelay=66: This parameter sets the time, in milliseconds, which is imposed between re-runs of the same Lua
plug-in. It is a safety precaution against repetitive execution causing an FS crash by stack overflow. For plug-ins which
take more than that amount of time to load and execute this effectively restricts the repeat rate from dials to 15 times
per second. The rate from buttons or keypresses being held down was already restricted as for those the repeat is not
effective until the current plug-in execution finishes.

 

That last sentence seems to indicate that if the lua is started on button/key presses then the repeat is not effective until the current lua execution finishes, so it may actually do what you want as-is - have you tried it?
 

Posted
54 minutes ago, John Dowson said:

That last sentence seems to indicate that if the lua is started on button/key presses then the repeat is not effective until the current lua execution finishes, so it may actually do what you want as-is - have you tried it?

Well John, that is very interesting.  What I had found was the increment script worked fine if I repeatedly pushed and released the key that called the script. But if I held the key down, or repeatedly pushed and released it very fast, it only incremented once or twice and then "quit".  I thought I had read that a repeated call to a running Lua script would kill it, and then restart the script, so I thought that was the problem.  I just searched through both the FSUIPC7 User and Advanced User Guides and could not find anything to that effect -- so another age problem I guess!  I will look further and try to figure out what is going on.

Thanks very much for the help!

Al

 

 

Posted

There are two other things that you could try:

1. Running your lua script on a key press, no repeats, and killing it on a key release. In the script, you can loop forever, reading the lvar value, adding 100 and writing it. However, as the lvar update is asynchronous and it will take a while (time depending on the lvar update frequency set in the WASM, which I think defaults to 6Hz) you will need another loop inside that to read the lvar value back and sleep for a short period (i.e. 50ms) if the value is the same, exiting once it has updated to continue the main loop.

2. Use an auto-running lua with an event.key function. In the event.key handling function, you would also need to only update if the previous update request has been reflected in the lvar value, and do nothing if the value is the same.

You can also change the lvar update frequency in the WASM to Frame or VisualFrame to get faster lvar updates.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.