WiiLi.org

[Brian]

After some hours trying to master neverball with my wiimote, I found myself wishing for some better control over the driver. I think the tracking plugins should also be able to emulate a joystick. I don't know how much of a stretch it is, but if it's not a great deal of work, I think it should be done. Also, perhaps allow a plugin to define the actions when buttons are pressed, rather then direct button-to-key mapping.

The reason i would like some kind of joystick input is because mapping the wiimote tilt to an absolute mouse value works great DURING a game of neverball, but trying to navigate the menus is near impossible, and i imagine similar problems would arise trying to use the driver in such a way for other games and such. If it could emulate a joystick, it could easily be used in other ball games, racing games, flight sims, etc. even if those games dont support using a mouse. (What kind of racing game uses a mouse?) With this kind of customization, the wiimote could become the perfect companion to a laptop (although still very useful for anything else); Great for presentations, and doubles as a joystick, and a steering wheel, and whatever useful feature we think of in the future.

Another thing that would be great, is changing plugins on-the-fly (again, not sure how hard this is in actual coding) so you could have say, a desktop driver that is useful for presentations, browsing, whatever you do with a normal mouse, and different tweaked versions for certain apps / games.

One last thing, more of a question, what exactly is going on in the IR tracking routine? It looks to me, on the outside, that its not using absolute positioning, but actually relative. When the cursor goes to the edge of the screen, and the wiimote keeps going, it seems to realign, so that when you come back over, the cursor is shifted to the side. This causes me to have to re-align the cursor whenever i accidently go a bit too far, by moving the cursor to all 4 edges so that it gets centered, otherwise i cant reach some of the corners.

Anyway, if you read everything and said "What the hell is this guy thinking? These ideas are so stupid!" or "Why am I reading this crap and not playing neverball?" then fine, i don't mind, i just wanted to put my two cents in. And once again, great work so far (should i mention neverball again? it just fits that game so well... nah, i wont )

[abstrakraft]

joystick emulation: Haven't looked into this, like the idea, but it sounds like a job for a separate program. I'll take a look into the world of Linux joystick drivers.

changing tracking on the fly: Hmmm...interesting. I think I like it. Just need some sort of wminput control interface that'll probably need to be written eventually anyway.

IR tracking: There's definitely some room for improvement here. Basically, if one IR source disappears, the algorithm remembers the location of the center of the two sources relative to the remaining source, assumes it stays constant, and uses that to calculate the cursor location until another IR source is picked up. When the other source moves back into view, the algorithm _should_ pick it up, but if it picked up another IR source elsewhere in the room that is still visible, that source will take priority. I think the best thing to do right now is add some intelligence to the source choosing part of the algorithm, maybe take roll into account when choosing sources (e.g., if roll is 0 degrees, the two sources should have roughly the same y value). In the meantime, try covering up the IR camera to reset it - that should cause new sources to be chosen, which will probably be the large ones in your sensor bar.

wminput is on hold for a little while - working on nunchuk, classic controller, and speaker right now.
_________________
"I seldom let practicality get in the way of my fascination with shiny things and blinky lights."
- some guy
http://abstrakraft.org/cwiid

[mattmacf]

I was going to start a new thread for my suggestion, but I found the plugins-on-the-fly idea to be nearly identical. In my limited twiddling with the cwiid driver so far, the problem I find myself running into the most is the fact that the wiimote itself only has 11 usable buttons. While 11 is plenty for controlling two, maybe three unique apps, I have been running into conflicts trying to control everything I tend to have running.

For example, when listening to music, a sensible controller setup would have the - and + keys adjust the volume, the L and R D-pad buttons for previous and next track (perhaps B as a modifier to allow B + L/R seek back/forward), and A to pause/play/stop. While watching TV (kdetv atm, MythTV if/when I finally get it running), we see similar defaults, but often using a separate set of key commands. This is (generally) solved (almost) trivially by changing keyboard shortcuts within the program itself.

Where things get incredibly tricky is when we begin to add programs that run simultaneously. Suppose for a moment I am browsing Firefox with my wiimote while listening to Amarok in the background. Is my music going to pause each time I click a link with the A button? Would switching tabs with L/R or +/- change tracks or adjust the volume? Suppose we throw Beryl into the mix. Can I now rotate left or right without affecting anything else? And can I do this without having to hack around Xmodmap and xbindkeys to do all of this?

I believe at the moment, the answer to most of these questions is no. What I would suggest (even before the on-the-fly adjustments) would be some sort of manual remote context switching. What I mean by this is something functionally analogous to universal TV remotes, generally with TV, VCR, CATV, etc buttons on the top that determine which device the remote will operate on. Ideally, it would be great to define a variety of different profiles (perhaps one for each LED or each binary LED combo) that can be manually toggled by a reserved (user-definable) key or key combo that can move the remote into a new, distinct set of buttons (and adjust the LEDs accordingly).

Oh, and it would also be great if all of this could be done from a single, coherent, GUI so that I don't have to go digging through a half a dozen config files every time I want to change a remote setting.

All of this is just a suggestion, however, and I'm pretty sure there are a number of issues yet outstanding. I'd also like to complement you on the excellent job you've done so far. Keep up the good work

[abstrakraft]

All good points - what I have in mind is a config file with labelled sections, and add capability to switch between "sections" on the fly, with a command-line utility, or with a button. Then, write a GUI to create/modify the config files, and possibly set up Xmodmap. When I get to it, it'll be great, but it's going to be a little while. In the meantime, if anyone wants to take on the task, let me know, preferably by posting a patch to a ticket at http://abstrakraft.org/cwiid .
_________________
"I seldom let practicality get in the way of my fascination with shiny things and blinky lights."
- some guy
http://abstrakraft.org/cwiid

[grossafe]