Supporting the Thrustmaster Warthog

Discussion and announcements regarding the Mac port… er, original version of Oolite.

Moderators: another_commander, winston

Post Reply
dhleong
Mostly Harmless
Mostly Harmless
Posts: 3
Joined: Sat Dec 20, 2014 4:23 pm

Supporting the Thrustmaster Warthog

Post by dhleong »

I recently got the Thrustmaster Warthog and was disappointed by the finicky support in Oolite. Though I have no experience with Objective C, I am a Software Engineer by trade and would like to help get this beast to cooperate. To that end, I threw together a crappy little CLI test harness based partly (mostly) on the OOMacJoystickManager.

What I discovered was this: (tempered, of course, by my utter lack of experience with the language and with joystick programming in general)

- Simply moving the stick was not enough to register it for pitch and roll in Oolite, and though Oolite had Axis 1 and 2 as defaults for those, they didn't work
- In the test harness, the input callback for axes on the stick is not fired until I pull the trigger. By pulling the trigger after moving the stick, I was able to get Oolite to recognize it and now I can turn and spin with aplomb!
- A lot of the buttons don't seem to trigger callbacks correctly. In fact, only the fully-depressed trigger (the Warthog has a 2-stage trigger) would make the above phenomenon happen. So, when I pulled the trigger, I immediately got callbacks for both axes and the trigger button. Again, this could be a problem with my code, because the button maps within Oolite (on the stick, anyway) do seem to work
- The throttle is a separate USB device, but it calls itself a joystick:

Code: Select all

 Discovered device!: <IOHIDDevice 0x1004023e0 [0x7fff77051cf0] 'ClassName=OverdriveUSB'  Transport=USB VendorID=1103 ProductID=1028 Manufacturer=Thrustmaster Product=Throttle - HOTAS Warthog PrimaryUsagePage=1 PrimaryUsage=4 ReportInterval=8000>
 #20, unnamed - usage 9:20, cookie 21, range 0-1
  --> value=1
 #33, unnamed - usage 1:57, cookie 34, range 0-315
  --> value=15
 #34, unnamed - usage 1:48, cookie 35, range 0-1023
  --> value=512
 #35, unnamed - usage 1:49, cookie 36, range 0-1023
  --> value=512
 #36, unnamed - usage 1:54, cookie 37, range 0-1023
  --> value=512
 #37, unnamed - usage 1:50, cookie 38, range 0-16383
  --> value=4870
 #39, unnamed - usage 255:1, cookie 40, range 0-65535
  --> value=45183
 #40, unnamed - usage 255:2, cookie 41, range 0-65535
  --> value=4237
 #41, unnamed - usage 255:3, cookie 42, range 0-65535
  --> value=12413
 #42, unnamed - usage 255:4, cookie 43, range 0-65535
  --> value=18260
 #43, unnamed - usage 255:5, cookie 44, range 0-65535
  --> value=63779
- The throttle has two separate axes, which are classified by AxisIndex as `5` ("Rz," the left throttle) and `2` ("Z", the right throttle).
- However, these report as absolute input, which may be related to Ahruman's comments about Sim_Throttle, etc.
- When registering the left throttle in-game, it shows up as "Stick 1 Axis 3"; the right throttle shows up as "Stick 1 Axis 6". This seems somehow opposite of what you would expect given the AxisIndex results (yes, I double checked that I didn't mix something up).
- Attempting to use either throttle provides a really bizarre experience, in which somehow the values of BOTH sticks are merged together. I'm not quite sure how to describe the interplay, so I'll enumerate some observations:
- It seems to act more like a button than a throttle. That is, whenever a change in value is registered the throttle slides all the way to its final destination, rather than tracking the position of the throttle.
- When the Right stick ("Axis 6") is registered:
- From 0, 0 (IE: left and right axes both full back), moving the right throttle brings acceleration to 0. If already 0, it does nothing. Moving left forward brings the throttle to ~60%. Then, bringing it back takes it to ~40%. Moving the right throttle when acceleration is ~40% then brings acceleration to 0. Moving it when acceleration is at 60% brings acceleration to 100%. Note that the direction of the right throttle is irrelevant. It seems to make the change as long as it moves. Perhaps this is like the phenomenon with the stick, where moving the right throttle just triggers the callback?
- I *think* when the left stick ("Axis 3") is registered, the behavior is largely similar to above, just reversed.
- Buttons on the throttle do not seem to register with Oolite at all

Is it possible to change the change event firing/reporting interval? The throttle axis issue may be as simple as that to fix, but I haven't figured out how to do it yet. I'm a bit stumped on the buttons not working, but I suspect it has to do with the throttle's axes being reported as belonging to Stick 1. Speaking of which—is there a way to cycle through the sticks within the Oolite Joystick config screen? I haven't found any way to do it.

Last, I have confirmed that there is nothing wrong with the devices themselves. I hooked them up to a Windows machine and they worked beautifully with Oolite, even without installing the special drivers.

Any help or insight here would be appreciated! I've forked the repo and gotten it to build, so I can try out any suggested changes.

Thanks!
dhleong
Mostly Harmless
Mostly Harmless
Posts: 3
Joined: Sat Dec 20, 2014 4:23 pm

Re: Supporting the Thrustmaster Warthog

Post by dhleong »

Just did a test, and can confirm that the weirdness with the throttle is simply that the device is not reporting its changes frequently enough. So, if I move the registered axis to say 20%, the throttle may not go there until I move the non-registered axis. It doesn't matter where I move it to, just so long as it's enough for the event to be picked up. If I want to then move to, say, 40% throttle, I have to move the registered axis to that position first, THEN, if that change wasn't fully picked up, move the other axis, at which point both events fire and I get 40% throttle.

In fact, there's a third axis element on the throttle device that will also trigger the callbacks to fire. So if we can somehow make the device report more frequently/poll the values more frequently, it should be usable! Doesn't help with the buttons, but I'd be happy with just the throttle as a first step.
User avatar
kanthoney
Commodore
Commodore
Posts: 281
Joined: Thu Nov 07, 2013 10:21 pm

Re: Supporting the Thrustmaster Warthog

Post by kanthoney »

My first contribution to Oolite was in the joystick code - I didn't know any Objective C until that point either, so don't let that put you off. Unfortunately, the bit of the code which actually interfaces with the joystick is completely different for the Mac than for Linux/Windows (which both use SDL), and I don't have a Mac. Or a Thrustmaster Warthog, for that matter.

The only real suggestion I've got at this point is to check the logs. There are a few settings in logcontrol.plist to increase logging on the Mac, and you could throw in a few extra OOLogs into the code too.
User avatar
Diziet Sma
---- E L I T E ----
---- E L I T E ----
Posts: 6310
Joined: Mon Apr 06, 2009 12:20 pm
Location: Aboard the Pitviper S.E. "Blackwidow"

Re: Supporting the Thrustmaster Warthog

Post by Diziet Sma »

G'day dhleong, and welcome aboard! That's quite an introductory couple of posts. Kudos! 8)

<wonders if anyone has tried a Saitek X55 Rhino with Oolite yet>

(My intended next stick for when I build a gaming rig)
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
dhleong
Mostly Harmless
Mostly Harmless
Posts: 3
Joined: Sat Dec 20, 2014 4:23 pm

Re: Supporting the Thrustmaster Warthog

Post by dhleong »

Thanks for the encouragement!

A couple more observations:
- Dropped a printf in the `if (axisNum >= 0) {}` branch of `handleInputEvent`
- The stick's axes fired rapidly with smooth numbers, as expected given the correct input handling
- This is NOT how it behaves in the test harness
- The stick's axes did NOT fire when Oolite wasn't in focus (it's running in fullscreen mode on another desktop, per OSX Yosemite)
- However, there was an event for both axes with a value of `0` when leaving Oolite.
- The throttle's axes DID fire when Oolite wasn't in focus
- The throttle's axes fired with a large delay between events, and abrupt number changes, with the extreme values not being represented at all.
- This is the same as in the test harness

Not sure how or why the stick is getting treated differently (better) than the stick, but somehow replicating that would probably make the throttle work....
Post Reply