Bevy: Gamepad Disconnected Event not dispatched correctly

[PradeepKumarRajamanickam]

Gamepad Disconnected Event not dispatched instead Connected is dispatched again.

tested using:
XBox 360 Controller
MacBook Pro (Catalina)

[CleanCut]

I can't replicate this with an Xbox One or PS4 Dualshock controller on macOS Catalina. 😕

[PradeepKumarRajamanickam]

Hmm.. maybe be this is a device specific driver issue. Let me try it on a Xbox series x controller i.e. if I manage to get hold of one this holiday season.

[Bobox214]

I have not encountered the issue testing on an Ubuntu 20.04 with an XBox360 Controller, Disconnected event is correctly detected by the gamepad_input example.

[PradeepKumarRajamanickam]

Recent os updates seem to have solved the disconnect not firing issue.

There however still seems to be an issue with connected event. Each time I unplug and reconnect my controller the Gamepad id/handle seems to increase even though there is only one usb controller plugged in. Can someone please confirm if they are experiencing it or is it just my device?

[CleanCut]

@PradeepKumarRajamanickam

I'm not aware of any official USB controller support in macOS. Am I missing something, or are you using a third-party driver like USB Overdrive?

From what I see for game controller support in general, macOS doesn't have stable device id's. Quite the opposite, it looks like macOS expects you to assign a player id to a newly-connected controller to indicate which player the controller should represent (and light up the corresponding player light). See the Player Indices Identify a Controller section of this developer document. I haven't found any references to playerIndex in gilrs, io-kit-sys, or core-foundation, so I don't think this particular ability is yet exposed.

Nevertheless, I _think_ the pattern we need to follow is to take each new incoming gamepad id as if it were a temporary unique identifier, and manually map it within our game logic to an available player.

[PradeepKumarRajamanickam]

"Nevertheless, I think the pattern we need to follow is to take each new incoming gamepad id as if it were a temporary unique identifier, and manually map it within our game logic to an available player."
@cart or @simpuid Are we (plugin writers) supposed to manage player handle to gamepad handle map or will this be abstracted for us.

@CleanCut I am using a community built driver https://github.com/360Controller/360Controller#about

[cart]

Short term I think it makes sense to handle this sort of mapping in game code (or plugin code). This sort of logic is context-specific and I'd rather not dictate it in bevy, especially this early in development.

[simpuid]

According to gilrs, it supports _Hotplugging_ but it is not reliable. It works with my controller but may not work with others(not frequent).

One of the solution is:

• For an old device, map them to the old player entity
• For a new device, either map them to an old player entity or create a new one depending on the button input, player count and player limit

This kind of solution is suitable in game code.

[PradeepKumarRajamanickam]

@simpuid Thanx will try it.

[PradeepKumarRajamanickam]

I am going to go ahead and close this ticket. I got what I needed.

Thanx for the support everyone.