Emulator

Reports testing with a Dolphin windows build via wine:

• The same issue occurs. With 2 controllers, both motions and buttons are used on all DSU controllers
• I noticed gyro inputs are about 1/4 of the amount Cemuhook's PadTest detects, which is another bug on itself

joaorb64 wrote:

Reports testing with a Dolphin windows build via wine:

• The same issue occurs. With 2 controllers, both motions and buttons are used on all DSU controllers
• I noticed gyro inputs are about 1/4 of the amount Cemuhook's PadTest detects, which is another bug on itself

Untested but just eyeballing the code, I think I can confirm this issue and see the problem. I'll take a stab at confirming / possibly fixing this tomorrow or over the weekend. Whatever the outcome, I'll report back here once done.

As for the gyro inputs, I can't say. I do know I was seeing larger values in Dolphin/Citra for my custom DSU but then realized it was a bug in my implementation for Dolphin (see PR 8747 if interested). But this specific issue might be a better choice for Billiard. Regardless, I'd suggest you open another defect so we can track it separately.

iwubcode wrote:

joaorb64 wrote:

Reports testing with a Dolphin windows build via wine:

• The same issue occurs. With 2 controllers, both motions and buttons are used on all DSU controllers
• I noticed gyro inputs are about 1/4 of the amount Cemuhook's PadTest detects, which is another bug on itself

Untested but just eyeballing the code, I think I can confirm this issue and see the problem. I'll take a stab at confirming / possibly fixing this tomorrow or over the weekend. Whatever the outcome, I'll report back here once done.

As for the gyro inputs, I can't say. I do know I was seeing larger values in Dolphin/Citra for my custom DSU but then realized it was a bug in my implementation for Dolphin (see PR 8747 if interested). But this specific issue might be a better choice for Billiard. Regardless, I'd suggest you open another defect so we can track it separately.

After further testing and exploring I noticed this other bug was a bug in my DSU server, sorry about that. Still, the original reported issue applies, as you also confirmed.

Please try https://github.com/dolphin-emu/dolphin/pull/8804 and see if that resolves your issue.

iwubcode wrote:

Please try https://github.com/dolphin-emu/dolphin/pull/8804 and see if that resolves your issue.

My apologies, please ignore the above link (not sure how to delete posts). I did have a potential fix but there's a more appropriate solution that will need to be implemented.

I'm the author of the code in question. After looking at the code again, I think it should be correct, assuming the connected UDP Server handles requests for data from individual controllers like DS4Windows does. That is, responding with data from only the requested controller.

Source: https://github.com/Ryochan7/DS4Windows/blob/c9210c41bebcf8ec4562ff8126d0c7b798d667d3/DS4Windows/DS4Control/UdpServer.cs#L611-L613.

Assuming the DSU Server @joaorb64 has tested with is https://github.com/joaorb64/joycond-cemuhook, it handles requests for data from individual controllers differently, by responding with data from all connected controllers.

Source: https://github.com/joaorb64/joycond-cemuhook/blob/2a6a243e8af0c2ba64bbc0c8197ec961bed7c570/joycond-cemuhook.py#L304-L306.

This document https://v1993.github.io/cemuhook-protocol/ seems to support the DS4Windows way:
"Actual controllers data - When you get this type of message, no instant response is required. Instead, you should begin or continue sending data from requested controller to this server." (my emphasis).

The reason cemuhook's PadTest worked correctly with @joaorb64's DSU Server may be because
PadTest requests data from all connected controllers at once, in stead of individually.

I haven't thoroughly tested this issue, but indeed I couldn't reproduce it while testing PR 8804. I used multiple servers simultaneously (one of them had two controllers connected to it) and every controller reported still responded with its own data...

rlnilsen wrote:

I'm the author of the code in question. After looking at the code again, I think it should be correct, assuming the connected UDP Server handles requests for data from individual controllers like DS4Windows does. That is, responding with data from only the requested controller.

Source: https://github.com/Ryochan7/DS4Windows/blob/c9210c41bebcf8ec4562ff8126d0c7b798d667d3/DS4Windows/DS4Control/UdpServer.cs#L611-L613.

Assuming the DSU Server @joaorb64 has tested with is https://github.com/joaorb64/joycond-cemuhook, it handles requests for data from individual controllers differently, by responding with data from all connected controllers.

Source: https://github.com/joaorb64/joycond-cemuhook/blob/2a6a243e8af0c2ba64bbc0c8197ec961bed7c570/joycond-cemuhook.py#L304-L306.

This document https://v1993.github.io/cemuhook-protocol/ seems to support the DS4Windows way:
"Actual controllers data - When you get this type of message, no instant response is required. Instead, you should begin or continue sending data from requested controller to this server." (my emphasis).

The reason cemuhook's PadTest worked correctly with @joaorb64's DSU Server may be because
PadTest requests data from all connected controllers at once, in stead of individually.

Thank you for the complete answer. I'll try changing the server's response and report back.

Ok, fixed it from joycond-cemuhook's end.
From what I could understand, even though the protocol supports up to 4 controllers per server, all emulators create a client for each emulated controller. Because of this, I had to get which controller each client was asking for via the id they requested in the request message.
This issue is fixed and was not a Dolphin bug. Thank you all for your help!