Quite hard to track down without owning he actual hardware.

Open your debug.log (within ~/.hedgewars or C:/Users//.hedgewars; depending on os) and look for some line similar to the following one - post it and ~ 5 - 10 following lines (those related to game controllers).

0: Console write: Number of game controllers: 1

0: Console write: Number of game controllers: 1
0: Console write: Using game controller: Logitech Cordless RumblePad 2 USB
0: Console write: * Number of axes: 4
0: Console write: * Number of hats: 1
0: Console write: * Number of buttons: 12
0: Console write: Init SDL_Net...
0: Console write: ok
0: Console write: Establishing IPC connection...
0: Console write: ok
0: Console write: Getting game config...
0: IPC send: C
0: IPC send: ?

Looks okay.

So, once you assign axes buttons no longer work? Could you do some step-by-step testing (e.g. binding one button at a time) etc? There are less axes/hats/buttons compared to a Xbox360 controller (which I used while testing), so I don't expect any issues there ... hm ...

Yes, as soon as I assign axis buttons it does not work.

Ok, here's a step-by-step testing:

Normal directions (D-pad):
Logitech Cordless RumblePad 2 USB (1): Hat (Up) works
Logitech Cordless RumblePad 2 USB (1): Hat (Left) works
Logitech Cordless RumblePad 2 USB (1): Hat (Right) works
Logitech Cordless RumblePad 2 USB (1): Hat (Down) works
All directions together works

Buttons on the right side of the gamepad:
Logitech Cordless RumblePad 2 USB (1): Button 1 works
Logitech Cordless RumblePad 2 USB (1): Button 2 works
Logitech Cordless RumblePad 2 USB (1): Button 3 works
Logitech Cordless RumblePad 2 USB (1): Button 4 works

Buttons on the top of the gamepad:
Logitech Cordless RumblePad 2 USB (1): Button 5 works
Logitech Cordless RumblePad 2 USB (1): Button 6 works
Logitech Cordless RumblePad 2 USB (1): Button 7 works
Logitech Cordless RumblePad 2 USB (1): Button 8 works

Select/Start buttons:
Logitech Cordless RumblePad 2 USB (1): Button 9 works
Logitech Cordless RumblePad 2 USB (1): Button 10 works

Pressing the analog sticks:
Logitech Cordless RumblePad 2 USB (1): Button 11 works
Logitech Cordless RumblePad 2 USB (1): Button 12 works

Now the interesting part

Logitech Cordless RumblePad 2 USB (1): Axis 1 (Up)
Assigned it to the "up" under "Move your hogs and aim".
Down was still the down key on the keyboard.
It does not work when I just moved the stick up,
but when I moved it up left or up right it works.
Sometimes (after releasing the stick) it kind of blocked the down key on the keyboard.
Had to move the stick a second time to make the down key work again.

Logitech Cordless RumblePad 2 USB (1): Axis 1 (Down)
does not work at all

Logitech Cordless RumblePad 2 USB (1): Axis 2 (Up)
As soon as I pressed any of the buttons (but not the D-pad) and afterwards released it the game received axis 2 (Up) events continuously (even if no button was pressed any longer). Example: Pressing the button 1 when axis 2 (Up) is assigned to "right" the
hog moves right the whole time.

Logitech Cordless RumblePad 2 USB (1): Axis 2 (Down)
does not work at all

Logitech Cordless RumblePad 2 USB (1): Axis 3 (Up)
same like Axis 2 (Up) but also when I pressed a direction of the D-pad

Logitech Cordless RumblePad 2 USB (1): Axis 3 (Down)
does not work at all

Logitech Cordless RumblePad 2 USB (1): Axis 4 (Up)
Similar to Axis 2 (Up) but only when I moved the right stick.
When I moved it to the left the hog stopped walking.
Releasing the stick made it start walking again.

Logitech Cordless RumblePad 2 USB (1): Axis 4 (Down)
does not work at all

Odd, or?

VERY odd ... could you test it with some other (SDL based) game or gamepad (just to know it's really the hardware in some way)?

Its very odd because the "axis triggers" will measure how far you moved the analog stick and then set or unset the "key" based on the amount it was moved. Its very odd that you don't seem to be able to get simple or direct up/down inputs.

What OS are you running? If it's windows, did you try the testing stuff under Control Panel -> Game Controllers?

I'm using Windows 7. The testing stuff works fine. All buttons, the D-pad, and both analog stick show expected results.

Tony Hawk's American Wasteland is working with game (don't know if it's SDL based, guess not).

Tested it with Secret Maryo Chronicles.
http://en.wikipedia.org/wiki/List_of_games_using_SDL
No problems using the left stick to move the character.

I don't have a second gamepad (or know someone who could borrow me one).
So I cannot test HW with a different gamepad.

hi there,
i can confirm that behavior, i use a moded xbox(1) small gamepad.
I tested it with other games like secret maryo chronicles, jstest-gtk (uses sdl aswell) - works fine.
but in hedgewars, it does exact the same as mentioned above. one thing, if i assign the axes up to both directions it sometimes works in one direction, while pressing in the other one makes it hung (also released, still going or aiming there)
I may help you out on this, as i am good in programming, may you tell me where the sdl-joystick stuff can be found in sourcecode?
also, maybe it is because the analog sticks go from -32000 to 32000 (in jstest), dont know if sdl turns this into a floating point (like -1.0 to 1.0), but that may be a reason why positive values work (up). maybe it counts 0 as minimum instead of -1.0 or -32000.
the analog pedals (index-finger) are from 0 to 255 - if i assign the down there to something it always moves there, and stops when pressing the pedal complete - so maybe the analog sticks are handled in a similar way...
just a thought though.
best regards
zuloo

ps: running ubuntu lucid 10.04 on a Mac - installed hw from repos...

so i tried compiling from source, went well, but problem with analog stick is still present.
are there informations available, where joystick input is managed in source, maybe i can compile it with debug-symbols, or log more stuff, so it becomes more obvious what is going wrong there...

best regards

zuloo

Controls are done in "hedgewars/ukey.pas"

alright, i did some debugging so far, just printed out what value the axis have when triggering an axis event... they are positive all the way, no matter which direction is pressed.
i guess its a conversion (or implicit cast) problem, as in integers the -/+ bit is the most left one i could be cut off (i am on a 64bit machine), but on the other hand the maximum value seems to be 65xxx (isnt that the maximum for unsigned 32bit integer?)
i guess somewhere there is the problem, i will try some stuff tomorrow to solve the issue
also i found something in SDLh.pas that returns a word from the axis (when not using sdl1.3)...
maybe that is the problem, any clue if word is unsigned in pascal?
could be a little/big endian problem aswell, will investigate further...
any suggestions so far?

Sounds interesting - according to docs (iirc, been some time) the axis should be -32xxx - 32xxx (signed 16 bit integer). Really interesting. Also: If possible, could you try booting a 32 bit live cd/dvd and see if you still get the same results?

bugspray 2000 is still the best ...

the point is, that in SDLh.pas on line 409 (or something) the typedef says to return Word if not in SDL1.3. that has to be changed to SmallInt.
Word is unsigned 32 bit integer. I tried to set it to integer as well, but that has the same effect as word, because bit#16 the +/- bit is handled as normal value-bit while casting it to 32-bit then.
I am not sure if the typedef for SDL1.3 has to be SmallInt as well, i use SDL1.2...
so far it works good now, the values are as expected now, -32xxx to 32xxx ...
i also tried a workaround before i looked up integer-types. i tried to apply a -32768 to the value of ControllerAxisEvent (in uKeys.pas) before assigning it to the axis-array - that did not work properly; it inverts the false behavior.

so line 409 (at least in the revision i checked out) in SDLh.pas is the bad guy
it should look like this:

TSDL_JoyAxisEvent = record

...

{$else}
value: SmallInt;
{$endif}
end;

oh btw, i could not use a live cd cause my dvd-rom is crap. maybe i will try the pad on my kubuntu-pc (its lucid as well, so it should be the same libs as on my mac) or i will manufacture a usb-boot-stick (thats something i need to do anyway in case of system-melt-down) to test it in 32-bit lucid.

so long

ps: i will try to implement the cursor-scaling-todo in uKeys.pas this weekend, where can i submit my code then?

alright, scaling the cursor-movement by the axis-value works great, i decreased the deadzone value to 10000 and -10000 so it responds earlier and so there are ~23000 values for the scale zone (i use a stepwidth of 2000 which feels very good)...
the only thing is i cant find the window (renderer) dimensions, any idea where to find those, so i can incorporate them too???

so long

There should be some global constants: cScreenWidth, cScreenHeight

Post your patch to google code or here (using pastebin or another hoster).

Edit: Applied the change from "Word" to "SmallInt" to the default branch

fine, i used it to set a scaling factor in the initmodule procedure. i used a stepwidth of 500 starting at 1000, so on 2560 its a factor of 4 in addition to the axes. i guess i will initialize the axes-scaling with 5 so there will be a scaling of 5 on 1024xsomething when using no joypad, and
20 on 2560xsomething. will test it for usability tomorrow.
so far with joypad its well playable...

mh, i tested it in many games and had to kick out the screen-size-scale-modifier. the reason is, it gets very inexact when playing on a big screen, on a small screen the minimal step is 1px on a big screen its 4 so this multiplies with the scale of the analog sticks and makes it difficult to place markers and select weapons...

maybe i will experiment with a exponential scale for the analog stick, to be very precise in the lower section and having a very fast mode on the end, i am just trying to find a processing-time-friendly implementation... (maybe second trigger value at 26000 to apply x2 or x3) dont know yet...

i will submit a patch after clearing up the source and diffing it...

So
Did you guys manage to get to the bottom of it in the end? I see there hasn't been an update on this issue for months.