Shouldn’t you rotate it so A is the bottom button? I believe it’s the primary button, but now it’s to the right…
@SolarLune: That’s actually an awesome auto-detection idea! It would be relatively easy to script, too.
Also as far as “C” buttons, I think of the N64 controller. Although it’s totally not practical, it would be awesome to hook up an N64 controller with Blender- a N64 to USB adapter does exist. :evilgrin:
@MCStudios - Yeah, that should be relatively easy to code. The ‘C’ buttons would just be extra buttons - you could check to see if the controller has exactly 9 buttons (L, R, Z, C buttons, and A and B), one hat, and two axes - if that’s the case, then it’s most likely an N64 controller (I can’t imagine any other normal controller having that setup not being in the N64 style).
@ Starclopsofish - As far as I could tell, A should be on the top, and then go to D in a clock-wise fashion, like
–A
D—B
–C
I believe that’s the correct setup for a game controller (on my computer).
Yeah, okay. I’ll see if it’s the same on my computer and setup.
Well historically, A has been the “confirmation button” and been to the right. For some reason American playstations and Xboxes switched it to the bottom- but on the Japanese units O is still the confirmation button and X is the “cancel button”. This is how it was back on the snes.
As far as your particular controller, it doesn’t matter if it considers the upper button “1” - the point of the configuration profiles would be to abstract that away so that when the “B” button needs to be used the player knows where that is - in the example I presented this is the bottom position. the player should never have to know which button is considered button “1” unless editing configuration profiles. All controllers are different in his respect (if they were all the same we wouldn’t need the configuration profiles.)
EDIT: To be clear, I’m not saying the “confirmation button” (we seem to be in agreement it should probably be A or Alpha or whatever) needs to necessarily be on the right. In fact, when I was thinking about this very issue, I came to the conclusion that it might be the most ergonomic to place the confirmation button in the left position, with the cancel button (A and B respectively for the sake of argument) in the bottom position.
This way, the point of your thumb naturally rests on the confirmation button, and you simply depress the knuckle of your thumb to cancel without having to move it. (think like when playing Super Mario, you held down Y and tapped B when you needed to jump with the lower part of your thumb) It’s pertty nice, when in menus you don’t even have to move your thumb.
Checked out your blend file, Starclops, and it was working fine for me. However, it’s worth noting that moving the right analog on the X axis (left and right) made the camera rotate up and down, while rotating the analog on the Y-axis made it turn. I guess that’s a good reason to have this automatic controller recognition script, right?
Ha I guess you’re right- I started development with a wired 360 controller and used a ps3 controller while trying to debug it a couple days ago.
It’s frustrating that the problem doesnt occur on your machine. Maybe I’ll try different builds of Blender to see if it’s just a bug in SVN. Are you on 32 bit Windows? I’ve only tested it on 64 bit on windows… you’re sure it doesn’t hang for you at all when pressing the right stick straight up (or down, not sure if it’s inverted for you)?
Anyway when I get home tomorrow night I’ll dig up that mockup I made a while back to see what you guys think.
Yeah, I’m on Windows 32-bit (If I recall correctly). I don’t think it hung, but I’m not sure. I’ll check it out.
Perhaps we should create a testers data-base, which contains at least user’s OS and connected controllers. Any takers?
My specs:
WinXP32 sp3
Logitech wheel & pedals
CH-Products FighterStick
Saitek X35T throttle ‘Evo’
TrackIR 4 pro
Face Track Noir
When we start testing the controller application/s, it’s good to get a feedback from multiple OS & controller users.
I posted my specs before- but I’ve seen a dual PS2/N64 to USB adapter somewhere that I want to look into.
WinXP64 SP3 with Blender 2.57
Wired 3rd Party (MadCatz) Xbox 360 controller (Not sure if it will work the same as an official MS one…)
DualShock PS2 wired Controller
Wireless Logitech PS2 controller with receiver (Might work with the aforementioned adapter…)
Nintendo 64 Controller (In translucent purple. Just sayin’. :eyebrowlift2:)
I wish I could offer more though, but that’s all I have. I’ll let you guys know if I get the PS2/N64 adapter.
Sorry for my absence in the last few days- I’ve been a bit ill and just started summer session- 4 hour long lectures… ugh. Anyway tonight and tomorrow I’ll work on a more concrete mockup for what I’ve had in mind and post it for critique here.
I agree that it would be good to begin compiling a list of testers and their equipment, so anyone who’s interested, your help would be much appreciated! Make sure to include which OSs (as well as version, bittedness, and architecture) you have access to as well.
Try to provide a specific model number for your device if possible- many times there are very similar looking devices using different drivers.
@Starclopsofish: I just noticed yesterday that I have the same problem with my controller as you do- it reaches 32767 well before it’s pushed all the way. It affects the negative X axis and positive Y axis (because I had to flip Y to negative in the joystick script I’m using).
Glad its not just me- I was going nuts trying to find a bug in my scripts :eek: I’ve observed this behavior on three different OSs with three different controllers- so it’s looking like its a bug.
Instead of making an extensive database of as many different controllers we can find, would it not be simpler to make an .exe or a .blend file that allows you to calibrate your gamepad/joystick and which generates the required config file for all the buttons/axes. :eyebrowlift:
Think this should not be very difficult and there would be no need for an extensive database, which I expect would be hard to manage and keep up to date (considering all the possible combinations of controllers and operating systems…)
hey i have a B2 USB Controller.
i think i have some issues with certain buttons. ( 1 & 2 flipped? )
Wraah makes a good point. Perhaps a better method would be to make a calibration scene for people to generate their own files. However, a central database would still be somewhat useful, as well… Perhaps we should try out a basic auto-detection blend and see how successful that is.
Ya know I think you might be right.
Last night after discovering I’ve lost my dual PS2 adapter, I was browsing Amazon for a replacement. I discovered two translucent blue ones almost identical to my late black one.They are both said to be manufactured by “Generic” and from reading reviews each has several quirks and differences. This seems to be a common case as well. It would be difficult for a user to identify exactly which adapter he/she has, much less autodetect it- it would be a nightmare to keep such a database up to date.
So I agree, we should instead focus more on a standard configuration utility (perhaps written in Python with wxwidgets or something? - I think a .blend would be a bit messy atm as the api isn’t stable).
We could still include a couple configuration profiles for a few very common controllers (PS3, Wired 360, etc.), but it shouldn’t be too hard for users with exotic adapters to configure their own with a basic understanding of the system.
I’m thinking of a wizard similar to many emulators, which prompts you for each button on the controller. It would still only have to be done once, so I don’t think it’s a big hurdle.
I like your idea Star, about focusing on a configuration utility, though I think that writing it in blend format would make it easier to work with (rather than having an external program / window / service to worry about).