POV buttons

[SeanMick]

Hi Pete,

Perhaps you could point me in the correct direction with the following (possible very simple!) problem? I am writing a lua script file to set up a joystick which has a set of buttons and a POV switch. The joystick also has the ability to set three different modes thus increasing the effective number of switches. Accordingly, I use calling "event.button" type commands with associated functions enclosing relevant "if" conditions depending on the mode status to assign the distinct operation to each individual button. All works fine.

My problem is that I am uncertain as to how the 8-position POV switches are handled. Under FSX control for panning they work fine and I have monitored the associated operation using FSUIPC logging. When I implement a similar control to duplicate this operation using a lua file with event.button/functions for buttons 32-39 it appears to cycle through all of the associated functions in sequence on activation of any of the POV switches. Is this normal and if so how is the activating POV button press uniquely determined?

Many thanks for any help,

Best regards,

Seanmick.

[Pete Dowson]

My problem is that I am uncertain as to how the 8-position POV switches are handled.

Currently POV switches aren't exposed to the Lua library functions. Nor are any axes. Didn't you notice?

In FSUIPC3 POV switches are treated in the same way as they were in FS98 and FS2000 -- as a set of 8 buttons 32-39. In FSUIPC4 I kept that option for compatibility but also added support for them as axes as well, so they can be programmed either way.

I'm not sure how I would support them in Lua, but if I added such facilities I might as well add axis support too. The problem with supporting axes via events is that the rate of change could easily far exceed the ability of the Lua interpreter to keep up.

Currently the best way to utilise axes (including POVs) in Lua is to assign them to a Lua control (i.e. an existing program) which would then be supplied with the axis value as ipcPARAM. This is as described in the FSUIPC Lua documentation. It would still have the inability to keep up with fast changes, though. You'd need to try it to see if it worked well enough for your needs.

Another way would be to assign the axes / POVs to FSUIPC Offset Word Set controls, using user-available offsets (66C0 - 66FF), and use the offset event to detect the changes in Lua. Really, though, this is just another way of doing the exact same thing only slightly less efficiently.

When I implement a similar control to duplicate this operation using a lua file with event.button/functions for buttons 32-39

How are you testing for buttons 32-39? There are no library functions for that. The existing button facilities only support 0-31, as documented.

Regards

Pete

[SeanMick]

Hi Pete,

Many thanks for the prompt reply and great support.

I was operating on the basis that the POV was simply a set of 8 separate buttons designated 32-39. So I put some test lines in my lua file for all of the POV buttons as follows, for example, for button 39

function button_39 ( )

ipc.display("Button 39 ",2)

ipc.sleep(2000)

end

event.button(joynum,39,0,"button_39")

When I push any single button on the HAT switch, the response is that all of the functions associated with buttons 32-39 appear to be activated in sequence, displaying the numbers 32 to 39 on screen in sequence, with a 2 second delay. Is this to be expected? If so, is there a way in which I can distinguish which button has been pushed?

[Pete Dowson]

event.button(joynum,39,0,"button_39")

Interesting. Yes, I see I do say POVs are supported in this way. Sorry about that -- I clean forgot!

However, according to the documentation, the "downup" parameter (the third above) should either be omitted, or set to 1, 2, or 3. I'm not sure what it would do with 0 there, though I'll check over the weekend.

When I push any single button on the HAT switch

You mean move it in one or other direction?

... the response is that all of the functions associated with buttons 32-39 appear to be activated in sequence, displaying the numbers 32 to 39 on screen in sequence, with a 2 second delay. Is this to be expected?

Well, the 2 seconds is explained by your programming, obviously -- the program is stuck in the "sleep" for two seconds on every occurrence of the event. Whether the phenomenon of getting events for all 8 possibilities one after the other is explained by your invalid 3rd parameter or not I can't say at present. Could you try omitting it instead, or using one of the valid values?

Regards

Pete

[SeanMick]

Hi Pete,

I have tried it with downup =1, 2 and 3 and I get the same effect.

For the button push action I simply activate it to any one of the 8 possible positions and then release it. The displayed sequence always starts at button 32.

By the way, when I assign the FSX pan/view function to the hat switch and monitor "events" in FSUIPC logging I get the control 66416 (with the angle parameter) repeated and then the -1 parameter as soon as the button is released. This is what I am trying to duplicate in the lua file for one mode so that I can then use the POV switches for other functions in the remaining modes.

Many thanks again,

Best regards,

Seanmick.

[Pete Dowson]

I have tried it with downup =1, 2 and 3 and I get the same effect.

Okay, I'll check it here.

For the button push action I simply activate it to any one of the 8 possible positions and then release it. The displayed sequence always starts at button 32.

You don't have a real POV?

By the way, when I assign the FSX pan/view function to the hat switch and monitor "events" in FSUIPC logging I get the control 66416 (with the angle parameter) repeated and then the -1 parameter as soon as the button is released.

That's right. Does the Angle parameter stay the same on each repeat? Does it correspond to the buttons pressed? (For 8 way, angles 0, 4500, 9000, etc to 31500).

Regards

Pete

[Pete Dowson]

I have tried it with downup =1, 2 and 3 and I get the same effect.

Okay, I'll check it here.

Okay, I can reproduce it. Very strange. i'll investigate and fix.

The Lua program I used was:

function showbutton(joy, btn, downup)
   ipc.log("joy=" .. joy ..", btn=" .. btn .. ", downup=" .. downup)
end

event.button(1, 32, 0, "showbutton")
event.button(1, 33, 0, "showbutton")
event.button(1, 34, 0, "showbutton")
event.button(1, 35, 0, "showbutton")
event.button(1, 36, 0, "showbutton")
event.button(1, 37, 0, "showbutton")
event.button(1, 38, 0, "showbutton")
event.button(1, 39, 0, "showbutton")

As well as fixing this bug, I might add another "special button number" to represent "any POV button 32-39" so that this can be done more efficiently!

Regards

Pete

[Pete Dowson]

As well as fixing this bug, I might add another "special button number" to represent "any POV button 32-39" so that this can be done more efficiently!

Okay. bug fixed in interim updates 4.624 and 3.989a, now available in the Updates announcement in this forum.

As well as the fix, you can now receive an event on any of the 8 POV buttons by specifying button number 40.

Also the undocumented value '0' for the "downup" parameter is confirmed as being the same as omitting it (i.e. acts like value 1). In fact any value other than 2 or 3 acts like 1.

So, to log all POVs, pressed or released, my test program becomes:

function showbutton(joy, btn, downup)
   ipc.log("NEW joy=" .. joy ..", btn=" .. btn .. ", downup=" .. downup)
end

event.button(1, 40, 3, "showbutton")

Of course not all expected events will be detected -- pressing more than one button at a time (hard not to on some Hat designs, like the MS sidewinder, my test device) might result in two "press" events, but only the one "release", because that's all that is seen -- a Hat can only indicate one thing at a time, unlike true buttons which operate in parallel.

Sorry about the inconvenience. Odd that the bug hadn't been found before. It was a pretty obvious one!

Regards

Pete

[SeanMick]

Hi Pete,

Many thanks for that, I'll update and try it out later but I'm sure that it'll work fine.

And once again, great software, great support.

Best regards,

Seanmick.