FSUIPC with HidVanguard/Guardian Issues

[pilotjohn]

With latest update of MSFS, there's a CTD with Controls if you have more than 10 devices.

I tried fixing this by using HidVanguard/Guardian to "hide" devices from MSFS, but allow FSUIPC to see them.

This would have worked except for 2 things:

1. The order of devices returned by HidGuardian seems to be random so FSUIPC always reassigned letters (this was fixed AutoAssignLetters=No)

2. Some of the devices (VirtualFly) didn't show up on launch, and letters using them were marked as "missing". However when I went to Axes, they were recognized by FSUIPC, but this caused a refresh, and the devices received new letters.

Is there a possible fix in FSUIPC for #2 (some different scanning behavior on startup that is similar to when I open Axes?). That would resolve the issue.

Also, scanning after opening Axes should still maintain the letter mapping (even if they were missing on start), although this would not fix the problem (since I would need to visit Axes every time).

Logs and ini attached. Thank you.

 

FSUIPC7 HV issue.zip

[John Dowson]

13 hours ago, pilotjohn said:

1. The order of devices returned by HidGuardian seems to be random so FSUIPC always reassigned letters (this was fixed AutoAssignLetters=No)

I don't understand this. It will only re-assign letters if/when it detects a new device. It looks like different GUIDs are being returned each time you run, and so different letters will be assigned as they are detected as new devices. Changing that parameter means that they are still detected, but letters won't be assigned.
This won' help as the numbers (joy ids) being used for each device will also change.

13 hours ago, pilotjohn said:

2. Some of the devices (VirtualFly) didn't show up on launch, and letters using them were marked as "missing". However when I went to Axes, they were recognized by FSUIPC, but this caused a refresh, and the devices received new letters.

I'm not sure why this would occur. Could the device have been 'asleep'? Maybe check the power management (in Windows) for that device/hub, and if using an external hub make sure that it is powered correctly.

14 hours ago, pilotjohn said:

Is there a possible fix in FSUIPC for #2 (some different scanning behavior on startup that is similar to when I open Axes?). That would resolve the issue.

I don't think this would help, as the initial scan is identical to the scan when opening the axis page.

I am also reticent to add hacks to fix issues caused by using other programs, especially if this is a temporary work-around for issues in MSFS.

John

[pilotjohn]

2 hours ago, John Dowson said:

I don't understand this. It will only re-assign letters if/when it detects a new device. It looks like different GUIDs are being returned each time you run, and so different letters will be assigned as they are detected as new devices. Changing that parameter means that they are still detected, but letters won't be assigned.
This won' help as the numbers (joy ids) being used for each device will also change.

The GUIDs look the same for the same device, but the numbering changes (e.g. the device order). This was causing re-lettering for some reason (e.g. YOKO+ went from D to R for example).

Quote

I'm not sure why this would occur. Could the device have been 'asleep'? Maybe check the power management (in Windows) for that device/hub, and if using an external hub make sure that it is powered correctly.

This only occurs with HidGuardian, and so far only noticed it in FSUIPC (USB Game Settings, Joystick Gremlin did not have the issue).

Quote

I don't think this would help, as the initial scan is identical to the scan when opening the axis page.

I am also reticent to add hacks to fix issues caused by using other programs, especially if this is a temporary work-around for issues in MSFS.

John

MSFS seems to be a mess with their QA, and introduces these random issues that I have to try to work around. I'm not sure how they're not catching these, as it really manifests itself within the first 15 minute of me trying an update. With the CTD in Controls when there are more than 10 devices, I was trying to fix it by hiding the devices from MSFS but not FSUIPC, but that introduced these other issues. It seems I just won't be able to touch the controls until next update. 🙂  Thanks for taking a look.

Not to start a separate thread, but StreamDeck support would be nice (since then I wouldn't have to use vJoy and the StreamDeck vJoyPlugin), and it would eliminate 8 devices. 🙂 I would be willing to fork/adapt the vJoy Plugin to support FSUIPC directly somehow. Do you have suggestions on how an external program can trigger FSUIPC functionality similar to button pree/release?

Specifically, how could I cause an input to trigger an assignable event in FSUIPC? FSUIPC only seems to have Keys, Buttons, Axes. Keys is not a good solution because there's just not enough of them to not interfere with something else (e.g. its management is a nightmare when you have 100+ assignments).

Ideally there would be a "virtual' section/tab, where I could simply send some device ID and button ID (or just some binding like a string) externally, and assign things the same exact way that I assign them in Buttons. Is this viable? That is, essentially duplicating your button handling code, and create a new tab where some external API (REST, or some library you can provide) could be used to trigger assignments. Then I could change the vJoyPlugin in StreamDeck to send these "virtual" events which FSUIPC would react to (e.g. press/release events or something).

Do you have any other suggestions?

 

[John Dowson]

8 minutes ago, pilotjohn said:

The GUIDs look the same for the same device, but the numbering changes (e.g. the device order). This was causing re-lettering for some reason (e.g. YOKO+ went from D to R for example).

But it is due to the changing joystick numbers that the joyletter facility was added. This then matches the name and GUID to the letter, and so if the joy id changes then the same letter is still in use and so the assignments (to the letter) still work.
If its generating a new letter for your device, then its not recognising it either due to a name or GUID change.

13 minutes ago, pilotjohn said:

The GUIDs look the same for the same device, but the numbering changes (e.g. the device order). This was causing re-lettering for some reason (e.g. YOKO+ went from D to R for example).

Maybe you can attach you Joyscan.csv file.

I have not used HidVanguard/Guardian, so do not know how it is affecting your devices or registry entries for those devices. BUT, FSUIPC must be able to determine what each individual device is, and this is mainly done from the GUIDs, although the id numbers are also used, especially when not using the Joy Letters.

17 minutes ago, pilotjohn said:

I would be willing to fork/adapt the vJoy Plugin to support FSUIPC directly somehow. Do you have suggestions on how an external program can trigger FSUIPC functionality?

Specifically, how could I cause a button input to trigger an assignable event in FSUIPC? FSUIPC only seems to have Keys, Buttons, Axes. Keys is not a good solution because there's just not enough of them to not interfere with something else (e.g. its management is a nightmare when you have 100+ assignments).

Ideally there would be a "virtual' tab, in addition to Buttons, where I could simply send some device ID and button ID externally, and assign things the same exact way that I assign them in Buttons. Is this viable? That is, essentially duplicating your button handling code, and create a new tab where some external API could be used to trigger assignments. Then I could change the vJoyPlugin in StreamDeck to send these "virtual" devices IDs and buttons which FSUIPC would react to (e.g. press/release events or something).

Do you have any other suggestions?

 Sorry, I don't understand what you are trying to achieve here. What would a new 'virtual' tab provide over the current button tab? Virtual devices are just devices as far as FSUIPC is concerned, and are handled the same (w.r.t buttons and axes) as any other device. Maybe @Pete Dowson can advise, I'm not sure.
I think the best solution really would be for MSFS to fix this issue - is it known and/or have you raised a zendesk report?

Also, please be aware that I am now on holiday/winding down (announcement yet to be posted). I will be covering support occasionally over the festive season, mainly for urgent requests.
All other support issues will now have to wait until I'm back to full time work around January 11th.

John

 

[Pete Dowson]

28 minutes ago, pilotjohn said:

Ideally there would be a "virtual' section/tab, where I could simply send some device ID and button ID (or just some binding like a string) externally, and assign things the same exact way that I assign them in Buttons. Is this viable? That is, essentially duplicating your button handling code, and create a new tab where some external API (REST, or some library you can provide) could be used to trigger assignments. Then I could change the vJoyPlugin in StreamDeck to send these "virtual" events which FSUIPC would react to (e.g. press/release events or something).

All that sounds like exactly what the virtual Buttons facility was invented for. You can have up to 288 buttons mapped to bits in the offsets 3340 onwards. Offset 29F0 also relates.

Pete

 

[pilotjohn]

3 minutes ago, Pete Dowson said:

All that sounds like exactly what the virtual Buttons facility was invented for. You can have up to 288 buttons mapped to bits in the offsets 3340 onwards. Offset 29F0 also relates.

Pete

 

That sounds interesting... how can this be triggered by an external process? Are there C# libraries for it? Would they be assignable in the "Buttons" interface (that is will they show up as some device letter)?

[pilotjohn]

9 minutes ago, John Dowson said:

But it is due to the changing joystick numbers that the joyletter facility was added. This then matches the name and GUID to the letter, and so if the joy id changes then the same letter is still in use and so the assignments (to the letter) still work.
If its generating a new letter for your device, then its not recognising it either due to a name or GUID change.

 

Maybe you can attach you Joyscan.csv file.

I have not used HidVanguard/Guardian, so do not know how it is affecting your devices or registry entries for those devices. BUT, FSUIPC must be able to determine what each individual device is, and this is mainly done from the GUIDs, although the id numbers are also used, especially when not using the Joy Letters.

 Sorry, I don't understand what you are trying to achieve here. What would a new 'virtual' tab provide over the current button tab? Virtual devices are just devices as far as FSUIPC is concerned, and are handled the same (w.r.t buttons and axes) as any other device. Maybe @Pete Dowson can advise, I'm not sure.
I think the best solution really would be for MSFS to fix this issue - is it known and/or have you raised a zendesk report?

Also, please be aware that I am now on holiday/winding down (announcement yet to be posted). I will be covering support occasionally over the festive season, mainly for urgent requests.
All other support issues will now have to wait until I'm back to full time work around January 11th.

John

 

I'm trying to trigger button-like functionality from an external process in FSUIPC. I don't want to go through vJoy as a layer of abstraction anymore (both because vJoy drivers are somewhat buggy with many devices installed, and because it creates these extra peripherals that some programs can't deal with). I can write a StreamDeck plugin in C# that could call an FSUIPC API/RPC. It sounds like these virtual buttons Pete mentioned might be it, but ideally there's a C# library I can use.

 

[John Dowson]

1 minute ago, pilotjohn said:

It sounds like these virtual buttons Pete mentioned might be it, but ideally there's a C# library I can use.

 

[pilotjohn]

17 minutes ago, John Dowson said:

 

I think that will work. So these virtual buttons will be assignable in the Buttons tab (what device letter do they show)?

[Pete Dowson]

26 minutes ago, pilotjohn said:

That sounds interesting... how can this be triggered by an external process? Are there C# libraries for it?

FSUIPC applications use a library to let them read and write FSUIPC offsets. For C# I'd recommend you look at Paul Henty's .NET DLL for FSUIPC -- please see the separate sub-forum above. Paul is very helpful and will no doubt answer any other questions you have. I don't know whether it has any special functions for the virtual button offsets, but it is quite likely -- and even if not I think it's an easy library to use.

Pete

 

[Pete Dowson]

5 minutes ago, pilotjohn said:

So these virtual buttons will be assignable in the Buttons tab (what device letter do they show)?

Yes, they are assignable -- that's really the point of them. They appear with Joystick numbers 64 to 72, each with 32 buttons 0-31.

Pete

 

[pilotjohn]

1 hour ago, Pete Dowson said:

Yes, they are assignable -- that's really the point of them. They appear with Joystick numbers 64 to 72, each with 32 buttons 0-31.

Pete

 

Since they're not visible when FSUIPC starts up, will they be auto-assigned letters when they are first received?

[pilotjohn]

Thank you both. I'll see how this works out. Hopefully I can just get rid of vJoy.

 

[pilotjohn]

Is the "Button Assignment" window supposed to react to these externally triggered offset changes? I assume yes, but want to make sure. And does it matter whether FSUIPC is connected to MSFS or not in this case (I know for physical devices it works without MSFS connection)?

 

[Pete Dowson]

16 hours ago, pilotjohn said:

Since they're not visible when FSUIPC starts up, will they be auto-assigned letters when they are first received?

They don't need letters as they are not subject to getting different joystick IDs like real devices do which disconnecting and reconnecting or updating Windows. The joystick numbers are fixed -- 64 for offset 3340, 65 for 3344, etc. Those joystick IDs can't change!

5 hours ago, pilotjohn said:

And does it matter whether FSUIPC is connected to MSFS or not in this case (I know for physical devices it works without MSFS connection)?

Ah, good question! Probably not, as I don't think FSUIPC7 starts operating the offsets system until it is connected. After all, it cannot supply meaningful data from an unconnected MSFS.

But John would have to confirm. He might consider making an exception for the virtual button offsets as I can see it can be useful to be able to sort out all your assignments without the Sim actually running.

Pete

 

 

 

[John Dowson]

6 hours ago, pilotjohn said:

Is the "Button Assignment" window supposed to react to these externally triggered offset changes? I assume yes, but want to make sure

Yes.

6 hours ago, pilotjohn said:

And does it matter whether FSUIPC is connected to MSFS or not in this case (I know for physical devices it works without MSFS connection)?

Currently FSUIPC7 has to be connected to MSFS for the virtual button offsets to function correctly. I can look into making such assignments available without an FS connection. I've made a note to look into this at some point in the New Year, but this will be low priority.

John

[pilotjohn]

Ack, thanks. I'll post this Stream Deck plugin to User Contributions if it ends up working out (and I'll probably add actions for direct offset and controls as well). This will provide Stream Deck integration for FSUIPC (which Spad.Next is adding). Maybe it can be evolved by others to provide bi-directional updates (e.g. change the button image based on offset changes - I have no need for that but other probably do).

 

[John Dowson]

@pilotjohn Ok, thanks. Let us know how it goes or if you need any assistance, although support will be occasional for the next 2.5 weeks or so.

Regards, and have a Healthy and Happy festive period,

John

[pilotjohn]

Everything seem to be working, except for one thing... the "repeat while held" for the FSUIPC virtual button seems to be a lot faster than for physical/device buttons. Is this by design? Can this by adjusted? Because it takes about 0.06 seconds for a press-release cycle, it's hard to stop at the right spot or do one step increments (like frequency). I'll just start a new topic on this.

 

 

 

[John Dowson]

On 12/24/2020 at 9:44 PM, pilotjohn said:

Everything seem to be working, except for one thing... the "repeat while held" for the FSUIPC virtual button seems to be a lot faster than for physical/device buttons. Is this by design? Can this by adjusted? Because it takes about 0.06 seconds for a press-release cycle, it's hard to stop at the right spot or do one step increments (like frequency).

I see you have now created a specific topic for this question: 

I will respond there, once I have taken a look to see what is happening. This may take a few days though as I am supposed to be on holiday (until the 4th)....

John

 

[pilotjohn]

Sounds good, thanks. No hurry, just thought it would be cleaner to not mix topics. 🙂