Concurrent mouse macros

[aua668]

Pete,

 

One question to the expert about mouse macros: Some addon aircrafts need for trigggering actions mouse macros, which explicitely implement first the button down event and then the button release event. So the single click alone will not operate the switch. With the mouse parameters that easily can implemented. So in LUA you end up with code like this:

ipc.macro ("Q400:AIceStruct" , 31 ) -- right single
ipc.macro ("Q400:AIceStruct" , 19 ) -- right release

If I have code segments like this in several LUA modules, there might be a conflict, as such macro calls might run in parallell at the same time. And by that they are influencing/disturbing each other. The sequence can not be guaranteed. I experienced such a situation especially in the initialization phase, where all the LUA module try to synchronize with switches and by that firing some mouse macros.

 

So the question is: If I would create a multi action macro out of these commands, are these commands then executed in one sequence without disturbance? LUA threads are obviously completely independent and therefore you are not able to control the actual sequence, when more than one module is using mouse macros at the same time. In normal operation this is typically no factor, as you trigger one switch at one time.

 

Best regards

Reinhard

 

[Pete Dowson]

If I have code segments like this in several LUA modules, there might be a conflict, as such macro calls might run in parallell at the same time. And by that they are influencing/disturbing each other. The sequence can not be guaranteed. I experienced such a situation especially in the initialization phase, where all the LUA module try to synchronize with switches and by that firing some mouse macros.

 

So the question is: If I would create a multi action macro out of these commands, are these commands then executed in one sequence without disturbance? LUA threads are obviously completely independent and therefore you are not able to control the actual sequence, when more than one module is using mouse macros at the same time. In normal operation this is typically no factor, as you trigger one switch at one time.

 

Are these macros being instigated by buttons or switches being operated by the pilot? If so, how is it likely that he will operate several buttons or switches at exactly the same time?

 

If this is somehow likely, or if you are talking about operations being performed automatically by program, then yes, for one aircraft you are better off having one Lua module.

 

The only downside is a larger file needing compilation each time it is invoked. You can get over that by having that Lua program pre-loaded using the event system instead to fire off the macros -- using event.param or event.flag to allow easy assignment to buttons and switches using LuaValue or LuaToggle assignments. I think that method gives you the best solution in most cases.

 

Pete

[aua668]

Pete,

 

At normal operation by the pilot it's not a factor, as in most cases you don't operate two sitches exactly at the same time. Or at least you can avoid it. The problem is typically in the initialization phase, where you start all the LUA modules in parallel. And as I have to synchronize the hardware position of the switch (I might have left the switch on, when I left) with the actual state in the sim, all the modules do some similar synchronization. They are checking the hardware button state and switch the panel button to the same position (on/off). By that I can restart my complete LUA modules without reloading the plane.

 

I already use the event system to program these modules. So compilation time of a larger module is no problem. And it's not this event based code creating problems, but just the initialization sequence.

 

So I will move this initialization code out of the several event driven switch modules and by that I can control the sequence. Another option is to time the initialization calls of the several modules as it doesn't matter, if the sync is done immediately or 10 seconds later - it has just do be done once, when I startup my LUA modules.

 

One question was not answered clearly enough (and maybe it's not easy to answer for you too):

 

Are multi action macros (e.g. doing first the right single and then the right release click) treated as one sequence, which can't be interrupted by another mouse action? If so, I could create combined macros and have only one ipc.macro call in LUA (instead of calling the same mouse macro with the several parameters in sequence in LUA). This would be a simple change. Anyhow I will try to find out, if this is a solution too. I just thought, you might have a hint for me, which direction would be the best.

 

Many thanks for you valuable input.

Reinhard

[Pete Dowson]

Are multi action macros (e.g. doing first the right single and then the right release click) treated as one sequence, which can't be interrupted by another mouse action?

 

Yes. All macros are actually executed in the main FSUIPC/FS thread, not in the specific Lua thread. The Lua coding actually executes ipc.macro using the offset request method, at 0D70 and 0D6C.

 

However, that said, it could theoretically still be precarious. The actual machine instructions to write the string to 0D70 and then the length to 0D6C (which triggers the action) are distinct with no critical enveloping, so there is a very small chance that control could switch to another thread and by sheer coincidence that be at the similar level, of writing to the same place. This is extremely unlikely (the threads are all equal in priority and general only lose the processor when they voluntarily do a cooperative "sleep(0)", between each Lua instruction), but it is there.

 

If this was likely to be a problem I would have written 0D6C and 0D70 as one structure instead. I can still change that, but I don't think it is worth the change.

 

Pete

[aua668]

Pete,

 

Thanks for clarification. I will take care for getting the initialization in sequence on my own. No need to change the code. It was just to check, if this option might avoid the concurrent writing. It's better to avoid it by programming already on my side :mrgreen:

 

Thank you!

Reinhard