Honeycomb Bravo rocker switches and using both LUA scripts but only Alpha will work.

[paulinyyz]

Hello,

I have both the Honeycomb Alpha and Bravo and wanted to address the switch assignments greater than 32 for both devices. I found and followed this topic, "A step by step for FSUIPC7, Honeycomb Alpha Yoke, and MSFS2020" and now have the switches (rotary start switch) working for the Alpha (joystick #64) but not having the same luck with the Bravo, still no response when pressing any of the seven rocker switches.

I did see this reference, "The other lines which you might want to change are: Device = 0  -- Multiple devices of the same name need increasing Device numbers."  and wondered if this was necessary but there was no mention of what to change it to, 1 or maybe 01, tried both but didn't seem to make a difference and after searching every LUA related PDF in the Documents folder I still could not find anything.

I have attached my INI file and the latest FSUIPC7 log.

Paul

It appears that I can't attach both file because together they greater than what I am allowed to here is the LUA entries in the INI.

[AUTO]
1=lua hidAlphaButtons
2=lua hidBravoButtons

[LuaFiles]
1=hidAlphaButtons
2=hidBravoButtons

FSUIPC7.log

[John Dowson]

10 minutes ago, paulinyyz said:

I did see this reference, "The other lines which you might want to change are: Device = 0  -- Multiple devices of the same name need increasing Device numbers."  and wondered if this was necessary but there was no mention of what to change it to, 1 or maybe 01, tried both but didn't seem to make a difference and after searching every LUA related PDF in the Documents folder I still could not find anything.

No, you don't need to change that as the Alpha and Bravo are different devices (have different Product Id). That is only used if you have two devices that are the same, i.e. same vendor and product ids.

I'm not sure what you issue is. Someone else recently reported the same problem but with the Alpha.
The strange thing is that the logging is showing the same entry each time:
        46219 LUA.2: BRAVO Buttons= 8E040000 2AAA
However, the script should only log when this has changed:

Quote

        -- check for changes   
        fbutton = false
        if buttons[2] ~= prevbuttons[2] then
            fbutton = true -- flag change for logging
            prevbuttons[2] = buttons[2]
            -- Send to FSUIPC as a set of 32 virtual buttons
            -- i.e. DWORD offsets 3340 onwards (3340 = ALPHA, 3344 = BRAVO)
            ipc.writeUD(0x3344, buttons[2])
        end
...

    if Logging and fbutton then
         -- log in hexadecimal
         ipc.log(string.format("BRAVO Buttons= %X %X", buttons[1], buttons[2]))
    end
 

Could you add the following line to your bravo script please (in bold below):

Quote

...

-- check for changes   
        fbutton = false
        if buttons[2] ~= prevbuttons[2] then
            fbutton = true -- flag change for logging
            ipc.log(string.format("BRAVO Buttons= previous=%X, now=%X", prevbuttons[2], buttons[2]))
            prevbuttons[2] = buttons[2]
            -- Send to FSUIPC as a set of 32 virtual buttons
            -- i.e. DWORD offsets 3340 onwards (3340 = ALPHA, 3344 = BRAVO)
            ipc.writeUD(0x3344, buttons[2])
        end

Also, add offset logging for 3344 as type U32 in hex (from the FSUIPC7 log menu).
Then generate another FSUIPC7.log file and show me that.

I see you are also using two vjoy devices. They may also be using the same offset range (Alpha uses 4 bytes from 0x3340, Bravo 4 bytes from0x3344).

Thanks,

John

[paulinyyz]

Thanks for the speedy weekend reply Pete,

Yes, I am using vjoy with Joystick curves to improve A320 control performance in P3D, if need be I can remove it if we don't have any luck. I have added the line and turned on the offset logging. and attached the file.

 

Paul

FSUIPC7.log

[paulinyyz]

I think the previous log file was missing what you wanted to see so have attached another.

FSUIPC7.log

[John Dowson]

3 hours ago, paulinyyz said:

Yes, I am using vjoy with Joystick curves to improve A320 control performance in P3D, if need be I can remove it if we don't have any luck.

Maybe remove it for now and test without.

The logging shows that the presses aren't being registered for some reason.
As well as testing without your vjoy devices, you could also uncomment the logging of the discards change:

Quote

  -- Uncomment this part to log the numbers of discards
  --if Logging and (discards ~= 0) then
  --   ipc.log("Discarded " .. discards)
  --end

to

Quote

  -- Uncomment this part to log the numbers of discards
  if Logging and (discards ~= 0) then
     ipc.log("Discarded " .. discards)
  end

Also, the 'button = false' line is in the wrong place really - should be:

Quote

...

function Poll(time)
  -- We use "readlast" so the values we use are the most up-to-date
  CurrentData, n, discards = com.readlast(dev, rd)

  -- Uncomment this part to log the numbers of discards
  if Logging and (discards ~= 0) then
     ipc.log("Discarded " .. discards)
  end

 fbutton = false

-- Extract values we need
    if n ~= 0 then
        -- Now handle the buttons, 64 of them, only the last 32 are used
        buttons[1], buttons[2] = com.GetHidButtons(dev, CurrentData)

        -- check for changes   
        if buttons[2] ~= prevbuttons[2] then
            fbutton = true -- flag change for logging
            prevbuttons[2] = buttons[2]
            -- Send to FSUIPC as a set of 32 virtual buttons
            -- i.e. DWORD offsets 3340 onwards (3340 = ALPHA, 3344 = BRAVO)
            ipc.writeUD(0x3344, buttons[2])
        end
    end
     
    if Logging and fbutton then
         -- log in hexadecimal
         ipc.log(string.format("BRAVO Buttons= %X %X", buttons[1], buttons[2]))
    end
 end
 

So please test with that and without vjoy and report back. I haven't used vjoy for quite a while now so I'll take a look and see if thats interfering (which it most probably is as its also using the virtual button offsets....).

John

[paulinyyz]

Sadly no change, even vjoy uninstalled, I want to attach the latest FSUIPC7.log but don't have sufficient upload quota, can cut and past but that is a bit messy but can do so if you wish.

Paul

And sorry, I referred to you as Pete earlier, knee jerk reaction after many years.

[John Dowson]

5 minutes ago, paulinyyz said:

can cut and past but that is a bit messy but can do so if you wish.

Yes, just paste the contents if you can't attach.

5 minutes ago, paulinyyz said:

And sorry, I referred to you as Pete earlier, knee jerk reaction after many years.

Don't worry - I'm getting used to being called Pete by now!

John

[John Dowson]

Btw, doesn't MSFS have native support now for the Honeycomb Alpha and Bravo? If so, can you check if those rocker switches are seen by MSFS when assigned there.
Just to confirm those switches are working. i.e. switch back to the default MSFS assignment profile to test. I know there are issues with 'always on' switches, but it would be useful to confirm those switches are actually working.

[paulinyyz]

Good question, the answer is a bit yes and a bit no! For example if I try to assign one of the switches to operate the parking brake the "always on" either jams the brake on or off so they are doing something. Need to try something else to see if the original assignments are working which I will do tomorrow.

 

Paul

[paulinyyz]

Hello,

The Bravo comes with the toggle keys assigned to functions as landing light, beacon, pitot heat etc. If you move the switch, the corresponding assignment does not happen, i.e the pitot heat switch will not move but it seems like this is because the "always on" state is the reason. If I remove one of either the on or off positions, the corresponding switch on the panel will move one way but will not go back the other way. So they have an effect but not really working because they are stuck in one position or another.

To recap, the Alpha LUA script will work and is seen by FSUIPC at joystick #64 but the Bravo script is not recognised, I think it should be seen as #65.

I have attached the log file, it's a new day so I am now allowed more quota.

Paul

FSUIPC7.log

[John Dowson]

5 hours ago, paulinyyz said:

The Bravo comes with the toggle keys assigned to functions as landing light, beacon, pitot heat etc. If you move the switch, the corresponding assignment does not happen, i.e the pitot heat switch will not move but it seems like this is because the "always on" state is the reason. If I remove one of either the on or off positions, the corresponding switch on the panel will move one way but will not go back the other way. So they have an effect but not really working because they are stuck in one position or another.

Ok, thanks. It was just a test to see if they were actually registering somewhere else as a button press, which it seems they are.

5 hours ago, paulinyyz said:

To recap, the Alpha LUA script will work and is seen by FSUIPC at joystick #64 but the Bravo script is not recognised, I think it should be seen as #65.

Yes, but the device is recognised (in the lua), but the issue is that it is not picking up the button state changes for some reason.
There is also another current topic open for the exact same issue but for the Alpha.

Presumably you can see the buttons < 32 and assign to them as usual, no? And Axes assignments are ok?

The log file you attached is interesting. There is a discarded state change for each subsequent update, so it looks like it may have flagged momentarily and then rest, and the changes discarded. Maybe try increasing the poll rate to see if this is the case.

[paulinyyz]

Yes, buttons <32 all work and can be assigned, axes assignments are OK as well. I changed the poll rate and that didn't help. It's baffling.

 

Paul

[John Dowson]

10 hours ago, paulinyyz said:

I changed the poll rate and that didn't help. It's baffling.

It is - I really don't understand why those button state changes aren't being recognised. You could try the HIDScanner program - see 

 

If you leave it running and activate your buttons, it should log what it sees. Do you see any button state changes for the buttons > 32 using that?

You could maybe also try using vjoyoffsets with vjoy, and mapping the buttons to the virtual button offsets using that, to see if that helps (available from same link above).

 

[John Dowson]

The problem with the Alpha turned out to be a missing cable, but this doesn't apply to the Bravo.

Can you see any buttons/switches at all on the Bravo, i.e. those with numbers < 32?
If you run the windows game controller panel, can you see any buttons highlighted there?
What are the button numbers shown in the MSFS controllers description dialog (where it shows a picture of your device and the button numbers for each switch) - that should show the button numbers for those < 32.

Also check that you don't have power management enabled for that device - and maybe try a different USB port.

[paulinyyz]

I can see all the numbers <32 in both FSUIPC and the Windows game controller, it's only the rocker/toggle switches which don't appear. In MSFS the picture of the device has the first of the toggles switches starting at 34 up to 47, 33 doesn't seem to feature anywhere.

Power management for the port is disabled and changing ports didn't help.

I will try some of what you suggested under "Useful additional programs".

Paul

[John Dowson]

Ok. Strange as the lua script should provide access to those buttons as the alpha one does for the Alpha. I don't know why this isn't working for you. It will be unteresting to know if the HIDScanner utility recognises those buttons.

[paulinyyz]

Here is the HiDScanner log, if i am looking at it correctly, the buttons seem to be recognised, 'Buttons range 1 -> 48 at indices 6 -> 53'.

Paul

HidScanner.log

[John Dowson]

Yes, that show the device does have the buttons, but I (mistakenly) though the HiDScanner utility also logged button changes, but it doesn't.

I'm really not sure why those button changes aren't being recognised. You could try with the full HidDemo.lua script (available in the zip examples archive in your documents folder). The Alpha and Bravo scripts are based upon this. Try temporarily removing your Alpha/Bravo scripts and using the HidDemp.lua - you will need to edit to specify the correct vendor and product Ids.

 

[paulinyyz]

I tried the HidDemo.lua after editing the vendor and product id's and removing the other two scripts but no luck. It was odd because when I pressed one of the <32 switches or buttons, FSUIPC would ID the joystick as F which is correct for the Bravo but as I flipped between position, #64 would flash up, still nothing from any of the seven rocker switches.

In FS 2020 controls I tried to assigned one of the seven to a pitot heat switch by manually selecting the switch positions but as before it either froze the toggle on the panel in place or it vibrated, so the rockers are doing something, just not the right thing.

Maybe I will try vjoy and the other bits that go along with it and see what happens.

For what it's worth I ave attached the FSUIPC log and the HidScanner log.

Paul

FSUIPC7.log HidScanner.log

[John Dowson]

4 minutes ago, paulinyyz said:

I tried the HidDemo.lua after editing the vendor and product id's and removing the other two scripts but no luck. It was odd because when I pressed one of the <32 switches or buttons, FSUIPC would ID the joystick as F which is correct for the Bravo but as I flipped between position, #64 would flash up

Yes, thats normal as it will be receiving both the physical button press and the virtual button presses for buttons < 32.

5 minutes ago, paulinyyz said:

still nothing from any of the seven rocker switches.

Ok. So that's not recognising them either.

9 minutes ago, paulinyyz said:

Maybe I will try vjoy and the other bits that go along with it and see what happens.

You can try that, if you can map you device to a virtual device (using vjoy), and then use vjoy offsets to map the virtual device to the virtual button offsets.
I haven't used vjoy in quite a while (over 2 years), so I can't really advise on how to do this (withou looking in detail, which I don't have time for at the moment I'm afraid).

I'll also provide you with another lua script for an additional test at some point, which will log the real data when it changes, as opposed to the raw data processed by the Lua. This may show something. However, it may take me a while to get around to this - I'm a bit behind on support at the moment and have a backlog of requests to go though, which will take me a while (this one is near the end of the list, sorry!).

John

[paulinyyz]

Not a problem John, I appreciate your efforts to-date.

I will keep an eye out for the new script and let you know if I have any luck with vjoy.

Paul.

[John Dowson]

On 3/10/2021 at 6:52 PM, paulinyyz said:

I will keep an eye out for the new script

Here it is: HidTest.lua

Run that lua (via [Auto] or in a button/key press), press some of the switches on your Bravo, those with numbers < 32 and then those above, then attach you log.

Maybe also try with the attached version of FSUIPC7 (v7.0.7b). In this, I've corrected when [Auto] luas are started (i.e. when a flight is loaded rather than in the main menu).

John

 

FSUIPC7.exe

[John Dowson]

On 3/10/2021 at 6:52 PM, paulinyyz said:

if I have any luck with vjoy.

When vjoy with FSUIPC it will still  hit  the 32 button limit, but you can use multiple vjoys for more buttons. I did think you could map real buttons to virtual buttons using vjoy, but I may be mistaken (I think I didi this a few years ago but my memory could be mistaken....!).

We are working on adding native support for up to 128 buttons for FSUIPC (6 & 7). I will be releasing a beta version of FSUIPC6 with this functionality shortly. I could also build a version if FSUIPC7 with this update for you to try, but that will be sometime next week.

 

Edited March 12, 2021 by John Dowson
corrected

[paulinyyz]

Brilliant, I will get at it over the weekend, thanks very much. I am about to get back to P3D and FSUIPC6 as well as MSFS. I am spending more time messing about with settings and VR stuff then flying.

Cheers.

[paulinyyz]

And I would be willing to try the 128 button of FSUIPC7 when ready.