From: Alex P. <al...@fa...> - 2001-05-27 03:38:32
|
> I'd appreciate it if you would take the time to give it a try Works fine under Debian GNU/Linux with PLIB from CVS and both 2.2 and 2.4 kernel series. I just tried it with USB yoke, and USB pedals and an analog joystick being plugged in all at the same time. Everything was detected and I could assign channels to any of the units. Concerned comment ... It includes some incorrect assumptions about whether certain functions are assigned to digital or analog channels. For me, for example, brakes are analog and allow clean ground steering. It would be nice if it selected the first button _or_ axis to respond to each prompt, or something. > and let me know > of any problems you have with it. At the beginning, tell the user to assign two buttons, one for yes and one for no. That way, you can confirm selections and back up to redo choices. If the user selects the same button for yes and no, use a double click for no and warn the user of this distinction being made. It doesn't support additional axes that might be of interest; how about ... gear up/down, rudder trim, push-to-talk, show/hide moving map, pause, NAV1 frequency change, OBS change, active toggle, faster/slower simulate, release droplet of guano (for the future "seagull over redmond" version), etc, [that's probably all my buttons in use] I suppose the best bet would be to have an input file that lists all the possible properties, instead of compiling it into the source code. I recommend that the associated input file actually be an existing fgfsrc.js which is being loaded as the defaults for slight modification. I'm thinking like the "make oldconfig" feature of the kernel build. > And yes, the author is well aware that this program really does need a GUI. > One step at a time. No, it doesn't really. What it does need is a progress report so the user knows how much longer this is going to take, and a way to make changes to an existing output file, when one axis was found to be wrong. |