Jump to content
The simFlight Network Forums

Basic question to start a lua-plugin


ChesserGuy

Recommended Posts

Hi,
ANY HELP WOULD BE APPRECIATED!
I tried hard but I don't succeed in starting any LUA-Script. I think I miss somethinng very elemantary...
I use the MSFS 2020 and have a Bodnar card that works fine.
I tried a couple of LUA-scripts but nothing happend.
Let's take the rotaries.lua and let me show you what I did:

I changed the rotaries.lua to
..
Vendor = "Leo Bodnar Electronics"
Product = "BU0836 Interface"
Device = 0  -- Multiple devices of the same name need increasing Device numbers

-- Use separate Lua plug-ins for separate cards!

-- NOTE: this can handle up to 16 rotaries only, using the first 64 "virtual buttons"
-- List the pairs here:

Rotaries = { 0, 1 }
....

because the fsuipc.ini showed:
...
[JoyNames]
A=T.Flight Hotas X
A.GUID={3D8586D0-1093-11EB-8001-444553540000}
B=BU0836 Interface
B.GUID={D92BD810-A381-11EB-8001-444553540000}
1=T.Flight Hotas X
1.GUID={3D8586D0-1093-11EB-8001-444553540000}
0=BU0836 Interface
0.GUID={D92BD810-A381-11EB-8001-444553540000}
...

FSUIPC gave me the number of the buttons: JOY# B, BTN 0 und 1

I put the rotaries.lua into the FSUIPC installation folder and the log file shows
...
[LuaFiles]
1=ipcReady
2=Rotaries
...

 and nothing happens, not even some addional lines in the log file. Yes, I checked the Lua-plugins and Log-Lua-seperately buttons at the log tab.

The ipc.Ready.log has this:
********* LUA: "ipcReady" Log [from FSUIPC version 7.0.9] *********
    15219 System time = 29/04/2021 14:03:49, Simulator time = 14:03:15 (12:03Z)
    15219 LUA: beginning "C:\FSUIPC7\ipcReady.lua"
    15219 LUA: C:\FSUIPC7\ipcReady.lua:1
    15235 LUA: Global: ipcPARAM = 0
    15328 >>> Thread forced exit (ipc.exit or os.exit) <<<
    15328 System time = 29/04/2021 14:03:49, Simulator time = 14:03:15 (12:03Z)
********* LUA execution terminated: Log Closed *********


I also tried other lua files like the TripleUse.lua and a nice one I found at the MobiFlight site that should bring the heading bug to the actual direction and assigned a keypress to it.
HDGBUD.lua

hdg = ipc.readSW8(0x582)
hdg = hdg - ipc.readSW(0x2A0)
ipc.writeSW(0x7cc, hdg)

Again, nothing happened.
What do I overlook?
I would be very happy if you can help me with these basic stuff!
Greetings, Frank

 

Link to comment
Share on other sites

6 hours ago, ChesserGuy said:

I changed the rotaries.lua to
..
Vendor = "Leo Bodnar Electronics"
Product = "BU0836 Interface"

This is not correct. For the correct vendor/product ids, look for this line in your FSUIPC7.log for that device:
 

Quote

      625    Vendor=294B, Product=1901 (Version 1.5)

Note that is an example for my Bravo throttle quadrant. The vendor/product for you will be different, but still logged. Use those.

6 hours ago, ChesserGuy said:

I put the rotaries.lua into the FSUIPC installation folder and the log file shows
...
[LuaFiles]
1=ipcReady
2=Rotaries

DO NOT adjust the [LuaFiles] section of your FSUIPC7.ini. This is generated and maintained by FSUIPC. Changing this can screw up your assignments - NEVER change this. Sorry, you didn't do that yourself - that is correct. The [LuaFiles] section will list the luas found in your installation folder, ready for assignment or auto-running.

To auto-start luas, you add them to the [Auto] section, or the profile specific [Auto.xxx] section (where xxx is the profile name).
Please read the provided documentation.

John

Edited by John Dowson
corrected
Link to comment
Share on other sites

4 hours ago, John Dowson said:
6 hours ago, ChesserGuy said:

I changed the rotaries.lua to
..
Vendor = "Leo Bodnar Electronics"
Product = "BU0836 Interface"

This is not correct. For the correct vendor/product ids, look for this line in your FSUIPC7.ini for that device:
 

Quote

      625    Vendor=294B, Product=1901 (Version 1.5)

Note that is an example for my Bravo throttle quadrant. The vendor/product for you will be different, but still logged. Use those.

Sorry, that's not correct. You can use the strings for product and vendor - I just never use them this way and forgot about that, sorry!

6 hours ago, ChesserGuy said:

The ipc.Ready.log has this:
********* LUA: "ipcReady" Log [from FSUIPC version 7.0.9] *********
    15219 System time = 29/04/2021 14:03:49, Simulator time = 14:03:15 (12:03Z)
    15219 LUA: beginning "C:\FSUIPC7\ipcReady.lua"
    15219 LUA: C:\FSUIPC7\ipcReady.lua:1
    15235 LUA: Global: ipcPARAM = 0
    15328 >>> Thread forced exit (ipc.exit or os.exit) <<<
    15328 System time = 29/04/2021 14:03:49, Simulator time = 14:03:15 (12:03Z)
********* LUA execution terminated: Log Closed *********

 

What does you ipcReady.lua contain? Note that this is a special lua and is ran automatically, so doesn't need to be in the [Auto] section to be started, thats why its running and the the rotaries lua not.

 

6 hours ago, ChesserGuy said:

I also tried other lua files like the TripleUse.lua and a nice one I found at the MobiFlight site that should bring the heading bug to the actual direction and assigned a keypress to it.
HDGBUD.lua

hdg = ipc.readSW8(0x582)
hdg = hdg - ipc.readSW(0x2A0)
ipc.writeSW(0x7cc, hdg)

Again, nothing happened.
What do I overlook?
I would be very happy if you can help me with these basic stuff!

What does the log say for this? This isn't listed in your [LuaFiles] section you posted - is it in the correct location?
Having lua plugins logged is good, but best to de-activate the option to log separately - only needed for long complex luas. For simple luas, its better to have them logged in the main FSUIPC log file.
So, please try again with that option disabled, and if you have issues attach your .log, .ini and the .lua files you are using.

 

 

Edited by John Dowson
Further info added
Link to comment
Share on other sites

Hi, John,

thank you for answering my questions so quick.

I freshly re-installed FSUIPC and started right from the beginning. To my big surprise HDGBUG.lua works fine!!

But the rotaries.lua doesn't do anything. I'm going to attach the three files you asked for.

Thank you so much: I tried hard but didn't can't see what's going wrong.

Greetings, Frank

 

Rotaries.lua FSUIPC7.ini FSUIPC7.log

Link to comment
Share on other sites

12 hours ago, ChesserGuy said:

To my big surprise HDGBUG.lua works fine!!

I'm surprised thats running as your [Auto] section is not correct! If its running, its because its assigned to button 6 on your BU0836 Interface device, and it runs when you press that button.

To auto-run your Rotaries.lua, change your [Auto] section to:

Quote

[Auto]
1=Lua Rotaries

See P36 of the Advanced User Guide.

Link to comment
Share on other sites

Hi, John,

thanks to your hints the rotaries.lua seems to run now. But I don't see any effect on the speed. The only thing that accelerated the rotary was changing the Pollintervall in the ini-file from 25 to 10.

I'm going to send you my log-file again. I turned the button HEADING_BUC_INC slowly and the HEADING_BUC_DEC fast. I logged the lua plugins and the buttons.

I hope you can help me!

Greetings, Frank

FSUIPC.log FSUIPC7.ini

Link to comment
Share on other sites

You are right, I assigned the two bottoms of the rotary switch to the HEADING BUG Inc/ dec. Is this wrong??

I thought the different speed comes from the lua script. Do I need two other buttons for HEADING BUG FAST Inc/ dec ?

This is confusing me. 

Link to comment
Share on other sites

What are the button numbers for your rotary? This line should just contain the rotary button numbers:
    Rotaries = { 0,  1, }
Are 0 & 1 the button number you see when you turn the rotary left/right? If so, thats ok.
However, when you assign in FSUIPC, you need to assign to the virtual button flag. If you are using offset 0x3340, this should show as joystick# 64, with different button numbers for slow and fast om each direction. You should assign your slow inc/dec to the slow buttons, and the fast inc/dec to the fast buttons.

You should not assign to the physical  rotary buttons, but the virtual flags the the lua sets. It will set one flag for slow left, another for fast left, another for slow right and a 4th for fast right. If you see the physical buttons being registered, you can ignore these by using the IgnoreThese ini parameter in your [Buttons] section.

Link to comment
Share on other sites

The object of the Rotaries Lua is to convert the two "real" button presses (one for each direction) as seen from your rotary into four "virtual" button presses -- two for each direction, one fast, one slow. Then you assign to those.

The list of buttons you set into "Rotaries = { ..." tell the script which pairs of real buttons it should look for, whilst the resulting virtual buttons will be adjacent pairs (slow and fast) on joystick 64 or 65 for each real button. So your list of two { 0, 1 } is correct for one rotary which operates real buttons 0 and 1.

The rotaries example was really provided as an example of programming a rotary on any kind of HID device connected to USB. With a joystick recognised by FSUIPC you will get the real button presses being seen as well as the virtual buttons programmed in this plug-in. The IgnoreThese facility John mentioned will help when assigning to the correct virtual buttons, avoiding confusing when trying to do the assignments.

For a single rotary you will get your real button 0 converted to virtual buttons 64,0 and 64,1. and similarly your real button 1 converted to virtual buttons 64,2 and 64,3. The code in the plug-in copes with up to 16 rotaries, so would then use up all 32 buttons both virtual joysticks 64 and 65.

Then in order to get a reliable fast versus slow turning recognition you will probably need to adjust the timings, i.e. these two:

FastTimeLimit = 60 -- Adjust to taste

Pollrate = 20  -- same as 50 times per second

With those figures, if button pulses are seen less often than 60 mSecs apart they are counted as "fast", otherwise they are "slow". Note that if you enable Lua logging, as you have done, things will be much slower in any case! There's no harm in adjusting the poll rate too, as you have done.

Note also that it is normal to assign whatever it is you want to both "press" and "release", because the rotary presses on one click and releases on the next.

On 4/30/2021 at 9:14 PM, John Dowson said:

I'll take a look in detail tomorrow, but on first glance you are only assigning to the HEADING BUG INC/DEC. and not the fast options. Try with:
   Rotaries = { 0, 11, 1, 10 }

That would list two rotaries, one pressing 0 one way 11 the other way, and the other pressing 1 one way and 10 the other.

On 4/30/2021 at 11:33 PM, ChesserGuy said:

I thought the different speed comes from the lua script. Do I need two other buttons for HEADING BUG FAST Inc/ dec ?

The buttons you assign will be "virtual" buttons, not the real ones, and there will be 4, two for each direction. The Lua script is converting your real ones according to the speed you turn the knob.

Pete

 

Link to comment
Share on other sites

Hi, John, hi Pete
I would like to give you my final feedback. You’ve helped me a lot and once again I’d like to thank you for your patience. 

Finally I succeeded and everything worked. 


But some remarks. My main problem was the assignment of the rotary buttons. It’s definitely not right that these are the numbers that FSUIPC shows in the buttons & switches tab. I use the bottons 1 and 2 of a Bodnar interface. FSUIPC sees them as 0 and 1. And it only works with

rotaries={1,2}

I experimented a little with both the FastTimeLimit and the PollRate and was disappointed. (Maybe due to my cheap rotary encoders?) I couldn’t manage to achieve a satisfying result. It is very difficult to exactly set a specific course, haeding or NAV frequency. If you get close to the desired value a fast impulse runs in and makes a subtle setting impossible. 
 

I think it is much better to use the compound function of programming the encoders. Mine have a push button which I use for setting a flag. With this flag I can toggle between fast and slow increment of altitude etc. 
 

This seems to be much better and easier. If you are airborne you don’t want to spend much time with handling the instruments, do you?
 

Greetings, Frank

Link to comment
Share on other sites

12 hours ago, ChesserGuy said:

But some remarks. My main problem was the assignment of the rotary buttons. It’s definitely not right that these are the numbers that FSUIPC shows in the buttons & switches tab. I use the bottons 1 and 2 of a Bodnar interface. FSUIPC sees them as 0 and 1. And it only works with

rotaries={1,2}

Yes, it appears so. I never noticed that before!  The button number is "corrected" to be the same as that FSUIPC would recognise here:

                mask = logic.Shl(1, Rotaries[j]-1)               

I don't know how that oddity arose. It is easily corrected of course, by using

                mask = logic.Shl(1, Rotaries[j])         

Odd that this example has survived at least five years with no one spotting that!

Pete

 

Link to comment
Share on other sites

12 hours ago, ChesserGuy said:

I think it is much better to use the compound function of programming the encoders. Mine have a push button which I use for setting a flag. With this flag I can toggle between fast and slow increment of altitude etc. 

This seems to be much better and easier.

You can certainly make it much more predictable that way. The fast/slow turning rotary facility may have to be quite extreme, timing-wise, to get a really usable result. It would be much much better written as a proper program and compiled rather than an interpreted script. The Lua script is useful in two ways:

1. An alternative way of reading buttons -- directly from a USB HID device
2. Another example along with the others of a Lua script. All of the examples are provided for folks to use as a basis of developing their own.

Pete

 

Link to comment
Share on other sites

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.