|
|
Unsupported — We cannot guarantee that this software will work properly on Mac OS 10.8 and above. Please be careful.
Release: WiiMote Control, v20080104
Release Type:
Beta
Version:
20080104
Release Notes
This WiiMote Control beta radically changes the patch's interface. It will almost certainly not work with your previous compositions, but adds a few new features to justify the change. First big change: Nunchuk support! To enable nunchuk support, use the inspector panel. You can also enable and disable the IR and Motion Sensors from that panel, simplifying the interface if you don't need some particular features. The nunchuk sometimes doesn't work if you power up the wiimote with the nunchuk plugged in. To get around this, connect the wiimote, and then plug in the nunchuk after the connection is established. This may be a hardware bug with no existing work around (other than reconnecting, which the Wii itself does on occasion with some games) By Default, newly created patches have the motion sensor enabled and the IR sensor disabled. Raw IR output was changed from 12 outputs to 1 structure output. This helps keep the patch size down a bit. No effort was made towards improving stability.
Installation InstructionsPlace the plugin file in |
Thanks for this new version, i'm personnaly very excited with nunchuck support, and structure output is uber-fancy. However, do you think this build will stay compatible with the next ones, or compatibility will be broken at some point in the future ?
Wiimote patches are such a hassle to connect (many options, lots of wiring, big math chains involved to get interesting results), that's why i'm quite cautionnous (?) at integrating wiimote support into my final product .
Anyway, Wiimote + Nunchuck + IRsensors is OVERKILL !!! Thank you so much.
Since the first inception of the WiiMote patch last summer, I've been struggling to find a good compromise between having a million outputs (and a very large patch!), and having control and flexibility for the future (since there are lots of new devices coming out all the time). I couldn't come up with one, so I simply chose to do nothing for a long time (with the exception of the nunchuk-aware beta before kineme.net had its own beta program).
With your inspector panel idea, I believe we've finally found that solution to having manageable patches that are still powerful. So I'm planning on keeping this setup for as long as I can imagine. There's nothing you can't do with it: Simply adding more dropdowns, and more ports for those dropdowns is all it takes. It never gets unmanageably large, and it doesn't cheat the user out of functionality. I love the design. And watching it reconfigure itself when you change the panel is pretty slick too :)
Can you think of any reasons why we'd need to break compatibility in the future? I can't. :)
[p.s. classic controller is now just a dropdown menu away... should be coming soon :)]
Ok then, i'll try to implement this feature safely. Just to be sure, if i wanna bundle the plug in my custom app, where should i declare this exactly ? : [QCPatch loadPlugInAtPath:
[Bad link]in my app controller ? (in the awake from nib/init section) thanks ( I'm a lil' off topic...)