I have a Thrustmaster setup (T.16000M + TWCS Throttle) and I was testing input for it and found it very bad and after some research I found its mapped through SDL library, witch converts/breaks down to a standard controller.
But I have 8 axes and 18 buttons one the one and 4 axes 20 buttons on the other, witch get only partially recognized and some are even double mapped (2 buttons lead to same "input").
I have tried to use the config tool of SDL, but is still habe a bit more inputs then SDL supports?
Now my question, how can I get all input (maybe raw input for those devices?) or is it possible to double map a joystick in SDL (like have the input device twice and then use different mappings?). I am cable of using C and C++, but obviously I want the easiest solution to be able to support complex joysticks.
Cheers
HOTAS Joystick input
These are all the inputs supported.
You can check them with get_joy_axis
or is_joy_button_pressed
.
What do you mean with "These are all the inputs supported."?
All Input is supported, like all 8 axes? Or like that what I get right now is all that is supported?
I created a quick test script to test if I can get all axes with get_joy_axis and only axes 0+1 and 6+7 (witch is in truth only axis, a pedal, but left half is axis 6 and right is 7) work, all other give 0 back. Same result for buttons, like using input event.
So I understand in direct GDscript I wont get more support for more buttons and axes?
- JOY_BUTTON_MAX = 128 --- The maximum number of game controller buttons supported by the engine. The actual limit may be lower on specific platforms:
- Android: Up to 36 buttons.
- Linux: Up to 80 buttons.
- Windows and macOS: Up to 128 buttons.
- Edited
You can use this code to see if the buttons work and get their index numbers.
func _input(event):
print(event.as_text())
Note, if you do it this way, there are additional buttons/axis which you can't access in the project settings. However, in my testing, they are non-standard. Meaning even if you get it to work on your HOTAS, that doesn't guarantee the same mapping on another brand of HOTAS.
- Edited
Using input events with my virpil hotas setup.
Throttle:
All 6 axes read correctly.
Only first 32 buttons work.
Joystick:
All 6 axes read correctly.
All 31 buttons read correctly.
I set my throttle in the virpil software to split into 2 DirectInput joysticks, one with 0 axes and 28 buttons, the other with 6 axes and 32 buttons. This is to support badly written software like Elite Dangerous that can't handle more than 32 buttons per device. Godot is only registering one of those, the other with 28 buttons isn't detected.
I'm guessing Godot thinks the second throttle is really the first and ignores it, since they both have the same name.
- Edited
cybereality
I have used this to test it and found with that, that some get not registered at all, that's the reason I made this post in the first place. Some buttons do not trigger an input event at all and it corresponds to SDL GamepadTool with the mapping. So what I have in SDL is exactly what gets registered in godot's _input
The mapping does not matter in direct sense for me, as I give the player an menu to map them them self, that's also the reason I will mostly only use _unhandled_input method for input. But for this to work I would need all input like from DirectInput (what I am used to by other software, I am still getting used to godot way of doing things).
And just as a side note: I basically do almost everything with code, that's the way I develop.
Now is can create a mapping in SDL GamepadTool, but I still get not all buttons and axes then, as SDL has not enough to map (Gamepad limit).
Is there a way to get Input without the SDL mapping? That seems to be the bottleneck here.
Or is this something I should post on issue tracker on git?
Or is there a solution in work in godot 4.?
Edit: I just got the idea of trying to create a mapping for it as a custom string, to overcome the gampad tool limit and set up more buttons (godot supports more, so now I want to find a way to set them up).
I know that then the mapping does not work for every HOTAS, but honestly, I believe it mostly will stay a hobby game with a limited player base and therefore the players will stay in my reach and I can help out there.
I will write if I can solve it this way.
Edit 2: Okay, I can't find a real mapping guide, with what I found until now I can't get over my limit of 15 buttons and 6 axes with the mapping right now, as I don't know the names to map more. (They have seem to have specific names in a mapping string.)
And is it normal that godot closes when I try to execute this:
Input.remove_joy_mapping(Input.get_joy_guid(1))
(Trying to remove mapping on my throttle joy.)
Cheers and thanks for the help.
laufenderWahnsinn Kojack Perhaps it's appropriate to report an issue in regards to some of the buttons and axis not working then, but the more relevant question is should it be reported to godot issue tracker or SDL? I recon probably both.
Goldot itself doesn't use SDL. For windows it uses its own DirectInput and XInput code.
But it does apparently read the SDL_GAMECONTROLLERCONFIG environment variable if available and parse it itself.
The SDL Gamepad Tool isn't really the right thing to use for a hotas. It's made for gamepads with only 26 inputs to map (like left stick up/down/left/right, right shoulder, etc), not devices with many varied controls. So it's not surprising it won't map all controls.
I set my Virpil throttle to single device mode (6 axes, 60 buttons), they all work fine directly in Godot using joystick events.
I created an issue on godot for now, I think there is a deeper problem then only mapping it self (as removing the mapping (with Input.remove_joy_mapping(Input.get_joy_guid(joyID))) silently closes the debug instance).
I think this can be closed now, as it is a issue with godot or sdl.
- Edited
an interesting topic I saw on Star Citizen LUG(Linux user group) subforums:
https://robertsspaceindustries.com/spectrum/community/LUG/forum/149/thread/how-to-fix-the-wrong-recognition-of-the-saitek-x55
This issue is because SDL incorrectly thinks this device is a controller. It then creates those incorrect registry entries that tell Star Citizen that it's a controller.
By disabling SDL - Wine falls back to using the kernel driver (evdev, which does not think it's a controller) and Wine will then rewrite those registry entries telling Star Citizen that it's a joystick.
Might only be applicable on linux/wine tho.