Yes, fix it and send us the patch, either to the [AD] mailing list, here, or on the SF.net bug tracker (as you have found). It's unlikely anyone else will fix it for you as we basically have no Windows developers any more.

The problem is that just adding checks for RxAxis and RyAxis doesn't help - the problem still persists. I tried that the last time around.

[EDIT]
Hmm. Actually, adding that check does make the missing Rotary show up - it just doesn't update. I think the problem might reside in joystick_dinput_poll() (or rather, that there might be an additional problem in joystick_dinput_poll()).

I think I'll try to wrap my head around Allegro's joystick code and see if I can produce a fix for this tonight.

[EDIT 2]
Way too many edits.

[EDIT 10⁴]
Hah. I was right. It was a combination of all three guesses to what the problem was: not enough MAX_STICKS + no RxAxis/RyAxis checking in object_enum_callback() + a similar problem joystick_dinput_poll().
I've tested a "proof of concept" fix that works for my joystick at least. I'll try to convert it into a clean fix and make a diff of it later tonight.

UPDATE: a proper fix will take a while, since trying to extract relevant information from MSDN is like repeatedly smashing a claw hammer into your groin.

Well, it's certainly showing its age anyway... it makes me wonder if there's any chance of introducing an _ex family of joystick functions and structures (with, for example, > 8-bit detail on axis positions, configurable deadzone/range properties, etc).

Well, I have some good news and some bad news...
The bad news is that there's just no clean way to do this without a major rewrite.
The good news is that I've found out why I never managed to get axis/button name mapping right.

In more detail:
Allegro's name assignment is completely broken. When a device is initialized, its elements are counted and their names are read and copied into Allegro's JOYSTICK_INFO structure. However, when the device's state is actually polled, the order in which the axes are assigned data has nothing to do with their order in that structure.
This is also why I can't fix the polling routine cleanly - without it knowing which axes correspond to which on the physical device, it can't actually know if lRx and lRy exist or not (an axis which doesn't exist always has a value of 0, but that is also a valid state of an existing axis). Therefore, the best thing I can do is to tack them onto two additional axes after all the others have been read. It's a hack, and an ugly one at that, but I don't think it should break anything (num_axis should make sure they're never visible unless they're actually there).

The solution to both problems would be to actually associate each Allegro axis with a corresponding DirectX axis, but I'm not sure if I'm allowed to touch the internal structures...

IMO of course. There might actually be a clean way to do all this, but I'll leave finding it to someone who's not as tired.

I will attach patches for testing in a minute or two.

[EDIT]
Attached.

[EDIT2]
I just realized I didn't make those patches against the SVN tree. I will rebuild them in a couple of minutes.

[EDIT3]
Reattached.

Good work Gnolam!

Yes. STICKS, anyway.

Well, that's a load of work for nothing then.

Wow you guys rock! Here I thought I wouldn't get much response for a while... gnolam you rock.

Props were due and given:
http://www.datarealms.com/devlog/cortex-command/open-sores-in-action/

A 4.3 update would be hot.

Don't install your modified Allegro binary to the system library directory, please!

How did you arrive at this conclusion? Just apply gnolam's patch on your local SVN copy of Allegro and staticlink your game. Problem solved.

Or you could apply it to 4.3 now.

AFAIK 4.3 compiles just fine.

its the old allegro_new branch or whatever that was totally broken.

And thats why theres a lack to begin with. "I'm not going to do anything if noone else does!".

Actually, I'm nearly done the new file/path handling stuff for allegro 4.3. Including the unix and windows specific code.