One script for all joystick buttons question

[stevem737]

Hello,

I've searched the documentation, forum, and web and I'm totally lost...

I'm writing Lua scripts to control the JustFlight Vulcan add-on.  If I've got a joystick or button box with, say 50 buttons, it seems I need to do one of the following:

1. Write 50 different Lua scripts in the Modules folder, each assigned manually from the Buttons & Switches tab to each button (which makes for a ton of files to manage); or
2. I've read about putting a single Lua script containing all the button code into the Modules folder and configuring the FSUIPC.INI file to automatically launch it.

It seems like (2), above, is the way to go.  But, my question is how to write that Lua script to assign a joystick/button combo to a given chunk of code.

Is there an example/guidance on writing Lua code to recognize the joystick/button combo, to assign the Lua code to?  Logically, something like "For Joystick 1, Button 12 pressed, FUEL_PUMP_7=1", "For Joystick 1, Button 13 pressed, FUEL_PUMP_8=1", and so on.

Overall, I'm trying to prevent having 50+ Lua scripts, and instead, have everything in one script for easier management.  Thank you for any help.

 

[aua668]

Hi,

I made the experience, that having more smaller scripts with only a few event routines performs better than having all of the code in one single LUA file. While you would not see this effect on simple buttons, you will see it on rotaries.

Maybe this helps you. And a smaller code segment is easier to debug than a big one - at least for me.

Rgds
Reinhard

 

 

[stevem737]

Hi Reinhard,

Thanks very much for your reply.  I guess you're saying that, performance-wise, many smaller scripts are better than one big one.

It's not just the 50+ scripts I'll have to write, though... it's the 6 additional entries that FSUIPC creates in the pull-down menu when one, single Lua script is put in the Modules folder (i.e., FSUIPC creates the additional LuaDebug___, LuaKill___, LuaSet___, Lua Clear___, LuaToggle___, and LuaValue___ for every Lua script).  So, there'd be 300 (50 x 6) additional entries in the FSUIPC pull-down menu.  It's not easy to scroll that massive pull-down menu, if one needs to make a change.

Here is a follow-up question:

For a double-pole, single-throw physical switch, I cannot use this "toggle" code, because the code can get out of sync with the switch position, depending on where the switch is when you start the software:

-- I cannot use this "toggle" code
function switch_On ()
     ipc.writeLvar("FUEL_PUMP_sw7", 1)
end
 
function switch_Off ()
     ipc.writeLvar("FUEL_PUMP_sw7", 0)
end
 
function switch_Toggle ()
  if ipc.readLvar("FUEL_PUMP_sw7") == 0 then
       switch_On ()
  else
       switch_Off ()
  end
end

switch_Toggle ()

Instead, is there a way to write a single Lua script like this, where it references the joystick controller and the button:

-- Hard-code the switch position, instead of a toggle function
-- I realize I could have two separate Lua scripts, one for each
-- switch position, but combining them would make for fewer scripts
if [JOYSTICK1_BUTTON7] == 1 then
	ipc.writeLvar("FUEL_PUMP_sw7", 1)
end

if [JOYSTICK1_BUTTON7] == 0 then
	ipc.writeLvar("FUEL_PUMP_sw7", 0)
end

2) 

[spokes2112]

2 hours ago, stevem737 said:

FSUIPC creates the additional LuaDebug___, LuaKill___, LuaSet___, Lua Clear___, LuaToggle___, and LuaValue___ for every Lua script).  So, there'd be 300 (50 x 6) additional entries in the FSUIPC pull-down menu.  It's not easy to scroll that massive pull-down menu, if one needs to make a change.

In the FSUIPC dialog you can type in search params in the dropdown text box to get you where you need in the drop down. 
IIRC it takes the first 3, maybe 4, max letters typed in -
"lua" - gets you to the root lua listings
"luat" - may get you to the root of lua toggle listings

[stevem737]

Thanks, Spokes.  That does help a little -- I'll certainly keep that in mind.  I'm still searching for a code solution like I mentioned, however.

 

BTW, regarding 2112... are you a Priest of the Temple of Syrinx? 😂

[spokes2112]

5 hours ago, stevem737 said:

Thanks, Spokes.  That does help a little -- I'll certainly keep that in mind.  I'm still searching for a code solution like I mentioned, however.
BTW, regarding 2112... are you a Priest of the Temple of Syrinx? 😂

Ummm.. OK :)

1. Favorite album of all time...
2. In high school, my locker was #112 on the second floor
3. During a very long hospital stay, many moons ago, i was on floor 2, room 11, bed 2.

O - U - BETCHA! 

RE: problems..
I always try for the single lua. Saying that, you may want to take a look at the COM functions in the lua library.. Using those to "pre-run" a script to get everything synched to your switches, followed by another lua to detect switch changes after the "pre-run" synch. Never used the COM functions so it is way above my pay grade. Using a loop to actively check the states of your hardware, all the time, would probably be out of the question, bringing flight sim to a stuttering crawl.

BTW.. when is spring? hehe

 
 

[John Dowson]

Its always better/more efficient to have scripts auto-ran and monitoring something to re-act on, rather than starting on a button press. As to the number of scripts, its probably better to have a reduced number but this is less important really - you just get an additional thread per running script.

Adding lua autostart + visibility via profiles is on my list to add to the features this year, so hopefully that will also reduced the number needed for those who separate luas via aircraft.

Cheers,

John 

P.S. Spokes: Rush I'm guessing - remember it from 35 years ago, will have to dig it out...!

P.P.S. And yes, 'Temple of Syrinx' reference missed me..

[stevem737]

Spokes, I love the "floor 2, room 11, bed 2" thing!  And, John, yes, classic Rush.  I was inspired to put the 2112 CD into my car this morning.  Still sounds awesome.  Remember: "Our great computers fill the hallowed halls."

Back to sim-building... John, you're making the argument for auto-ran scripts.  I can understand that, but I'm still trying to figure out how to recognize a joystick/button combo in the Lua code.  I just stumbled upon this:

if ipc.testbutton(3,7) == true then
	ipc.writeLvar("FUEL_PUMP_sw7",1)
else if ipc.testbutton(3,8) == true then
	ipc.writeLvar("FUEL_PUMP_sw7",0)
end

I'm going to go run some tests, to see if ipc.testbutton(joystick,button) is the Lua function I need to simply recognize a joystick/button combo in the code.  I cannot currently find documentation on ipc.testbutton, but I'll keep looking.

[John Dowson]

Its in the 'FSUIPC Lua Library' document, page 9:
 

Quote

 

x = ipc.testbutton(joynum, btn)

Tests a scanned button. “joynum” is a joystick number, the same as shown in FSUIPC’s Button assignments tab.
Provided the joystick is one being scanned by FSUIPC (i.e. it has a button assignment), this function returns
the state of the specified button number (0–31) as TRUE or FALSE. 

You can test for the POV position too using button numbers 32-39, but you might want instead to read the POV state using ipc.readPOV .

 

 

[aua668]

On 3/4/2019 at 7:23 PM, stevem737 said:

It's not just the 50+ scripts I'll have to write, though... it's the 6 additional entries that FSUIPC creates in the pull-down menu when one, single Lua script is put in the Modules folder (i.e., FSUIPC creates the additional LuaDebug___, LuaKill___, LuaSet___, Lua Clear___, LuaToggle___, and LuaValue___ for every Lua script).  So, there'd be 300 (50 x 6) additional entries in the FSUIPC pull-down menu.  It's not easy to scroll that massive pull-down menu, if one needs to make a change.

 

Hi,

Sorry for answering late but I was skiing in the Alps. Assigning LUA routines to buttons by assigning them via the button tab is not very efficient. If you do it like that, every time you activate one of your buttons, the LUA code must be loaded, compiled and then be executed.

You really should look for the event library in the LUA library document. Using that method you only have to load the LUA modules once (maybe via the autoload functionality built into FSUIPC). Then these routines are waiting for the trigger events you have defined and execute the referenced function. Much more efficient to do it that way.

Rgds

Reinhard

 

 

[pilotjohn]

On 3/4/2019 at 1:23 PM, stevem737 said:

Hi Reinhard,

Thanks very much for your reply.  I guess you're saying that, performance-wise, many smaller scripts are better than one big one.

It's not just the 50+ scripts I'll have to write, though... it's the 6 additional entries that FSUIPC creates in the pull-down menu when one, single Lua script is put in the Modules folder (i.e., FSUIPC creates the additional LuaDebug___, LuaKill___, LuaSet___, Lua Clear___, LuaToggle___, and LuaValue___ for every Lua script).  So, there'd be 300 (50 x 6) additional entries in the FSUIPC pull-down menu.  It's not easy to scroll that massive pull-down menu, if one needs to make a change.

Here is a follow-up question:

For a double-pole, single-throw physical switch, I cannot use this "toggle" code, because the code can get out of sync with the switch position, depending on where the switch is when you start the software:

-- I cannot use this "toggle" code
function switch_On ()
     ipc.writeLvar("FUEL_PUMP_sw7", 1)
end
 
function switch_Off ()
     ipc.writeLvar("FUEL_PUMP_sw7", 0)
end
 
function switch_Toggle ()
  if ipc.readLvar("FUEL_PUMP_sw7") == 0 then
       switch_On ()
  else
       switch_Off ()
  end
end

switch_Toggle ()

Instead, is there a way to write a single Lua script like this, where it references the joystick controller and the button:

-- Hard-code the switch position, instead of a toggle function
-- I realize I could have two separate Lua scripts, one for each
-- switch position, but combining them would make for fewer scripts
if [JOYSTICK1_BUTTON7] == 1 then
	ipc.writeLvar("FUEL_PUMP_sw7", 1)
end

if [JOYSTICK1_BUTTON7] == 0 then
	ipc.writeLvar("FUEL_PUMP_sw7", 0)
end

2) 

What solution did you go with?

I will be in a similar state as I'm building a custom panel with many toggles, push buttons, encoders, with different behaviors (for example convert a OFF/ON toggle to ON/ON, or accelerate encoder, or long and short press etc.). I would very much prefer having everything in one codebase, but FSUIPC's Lua interface is sub-optimal for this, as you have to either launch on button press (as stated this incurs startup cost), or run one script polling (also inefficient, and may miss buttons?). Is there some wait/block function in the event loop (I don't remember from 5+ years when I was into this)? Also, there's no GUI interface/API to Lua scripts.

I view this as a layered problem:

1. Low-level: basic interface for button handling (e.g. efficient callback infrastructure etc.)
2. Mid-level: logic that is generic (that may require state coordination), but that can be reduced in complexity to simple state changes
3. High-level: simulator specific code that needs an interface like FSUIPC

So my current plan is to perform most of the "mid-level" button logic conversion in Joystick Gremlin's Python interface, which is event driven and can be GUI-customized (e.g. if you have a generic script like convert OFF/ON to ON/ON, you can set the button used by the script in the GUI, making configuration easy and simple). JG handles this well by instantiating your Python code once (for each config) and then using callbacks on state changes. JG is also needed to convert from 64 buttons (e.g. Leo Bodnar's BBI64) to 32, since FSUIPC can only deal with 32 buttons on a given device. I will use JG for managing generic non-sim button behavior and mapping them from the physical interface to many vJoy devices. Then, I'll use FSUIPC for all the sim-specific stuff. For now, the identified generic behaviors are:

• Map OFF/ON or ON/OFF/ON to ON/ON or ON/ON/ON states (e.g. like https://gist.github.com/IslandJohn/06589d5dec3c278dcd75f207cf42d099)
• Map long and short presses to different buttons (e.g. https://gist.github.com/IslandJohn/30fb66b8a3d0161ff6fe15053c9f3d01)
• Simulate encoder acceleration by pulsing vJoy buttons (e.g. https://gist.github.com/IslandJohn/ee13718fce203af52f13bd3c8e0e0ae2)
• Map multiple toggles to decoded bit states (like two OFF/ON to toggles to 4 buttons, e.g. OFF/OFF = 1, OFF/ON.= 2, ON/OFF = 3, ON/ON = 4)

I will use FSUIPC to map the vJoy buttons to whatever I need in the simulator. I do wish FSUIPC would have a GUI interface for sending multiple events or constructing some rudimentary logic (this is a rather simple GUI construct, but changes from major versions are mostly cosmetic on the UI side). Maybe there's an opportunity to write an FSUIPC GUI manager that generates these entries.