BrianPeek.com

Thanks for adding support for multiple wiimotes! But unless I'm missing something, there's no way to tell them apart. Of course, I can have the user do something distinctive with each remote and from then on know which one is which. But I'd like to be able to save information about the wiimotes in a config file, and not have to recreate it ever time I run my program (at least as long as the wiimotes remain paired to the computer). I had hacked an earlier version of WiimoteLib to support multiple wiimotes. In that version, I exposed the equivalent of your mDevicePath as a public property "DevicePath". Perhaps you can do the same in yours, so I can start using the official library again? It's an imperfect solution, since the device path is only unique as long as the wiimote is connected to the computer. If I reboot, I have to start over. But it's better than nothing. (If only the HID interface exposed the mac address.) I believe I'd also need something like this if I want the ability to add a new wiimote to a running program -- I haven't tried it, but I think I could do so by enumerating all the wiimotes and discarding the ones for which I already have one with the same devicepath. If you do that, I think it would also be interesting to make the Wiimote(string devicePath) constructor public. p.s. In your tester, where you set an LED to indicate which wiimote is 1, 2, etc, it would be nice if you also set the checkbox in the UI, so that they match. p.p.s. How on earth do I put paragraph breaks in a message? I didn't mean for this to all run together.

I'll answer the last one first....it seems some browsers have issues with the text editor and it winds up running all text together...not sure why.

As for uniqueness...I'm throwing a unique GUID into each Wiimote object, but you're right, when the app ends, those GUIDs go away and new ones are created at the next run.

Grabbing the MAC address is the ideal an perfect solution, but I haven't managed to make that go yet.  If/when I do, that's going to replace the GUID goodness.

As for the device path stuff, I was going to use that, but I've seen some BT stacks do crazy things with the device path which is why I thought it best to not expose it.  What stack are you using?

Brian Peek:

What stack are you using?

Umm, how do I tell? I'm currently using a BlueSoleil device, but I didn't install anything, so it's whatever Windows came up with on its own when the USB new hardware detector did its thing.

If you didn't install anything extra like WIDCOMM stack/drivers, it sounds like it's just the standard Windows stack which is what I've got here on both of my machines.

I shall ponder this and see if I can come up with something better...

Well, I do have other machines with WIDCOMM drivers that I have to play with, so I'd hate to have a solution that only worked for the default MS stack...

I modified 1.5.2 to do what I suggested above (expose Wiimote.mDevicePath as a public property "DevicePath"), and it seems to suit my purposes just fine. My program now remembers which wiimote is which from the last time it ran, and that's good enough for now. This works with both the MS stack and the WIDCOMM stack.

hi my name is anderson I wanted to contact me some time but until now find the means to be able to ask as I do in my application to connect and I work two Wiimote for a game in XNA, I would be grateful for his collaboration