Search the Community

Hi, Anyone interested in clone of Hotkey Manager for KSP1 ? I would be very interested in it, since I play in KSP2 with Joystick. Then I could use AntiMicroX to map joystick buttons to keyboard chars and... SAS

Hello, I am attempting to use my tflight HOTAS X joystick with ksp (steam version) on windows 10. I am in the input settings and the game can bind joystick buttons to certain actions, but when I go to edit the bindings for axis it recognizes the axis but then when I click accept it reverts to not assigned. What is the issue?

I cannot use my Saitek HOTAS in KSP because of the horrible input lag it introduces. There is about half a second delay for all axes, making precise flight infeasible. Some said the problem is common for other Unity games aswell, but surely there must already be a workaround for it. Other people reported success with vJoy but that bypasses the Saitek drivers which I definitely don't want to, as I rely on their programming suite where I have over a dozen complex profiles for aircraft in another simulator called DCS. I've tried Advanced Fly-By-Wire aswell, with updated .dlls, but it changes absolutely nothing on my game. The lag is there in space aswell as in atmo. Windows 10 Pro N, tested both 32bit and 64bit game versions

Hi all, I'm fairly new to KSP (couple of hundred hours into career mode) and playing a pretty fresh installation of 64-bit 1.3.1 on Windows 10. Good old X58 platform with a Xeon X5660, 4GB GTX970 and 12GB of DDR3. I'm aware that Unity has some known issues regarding joystick input handling, and I've searched/scrolled through this support forum to read the previously posted questions re. multi-input, HOTAS throttles and Thrustmaster peripherals. But I haven't seen my specific issue previously reported, so I thought I'd post a thread... doubting it will be a super-quick-fix kind of issue, but I may as well document it eh? So, prepare yourselves... wall-o-text post incoming... SITUATION: I got all inspired by Cupcake's videos and bought myself a wee christmas present... Thrustmaster 16000.M FCS flightstick and the TWCS HOTAS throttle to go with it. These units can be used "plug'n'play" (in which case the game detects them as two separate input devices), or they can use a software app/virtual device driver called "T.A.R.G.E.T." which is basically a GUI laid over Thrustmaster's custom scripting engine. This software allows you to combine multiple physical controllers into one "virtual device", with customised axis mapping/response curves, button mapping, keystroke generation, mouse pointer control, etc. PROBLEM: Now, if I go the plug'n'pray route and don't use a T.A.R.G.E.T. profile, KSP recognises both devices as separate controllers and I can map the axes with no problems, everything behaves as it should. Except the JoyButton inputs are duplicated for both devices (whether due to limitations of the DirectX API, the Unity engine, or KSP's input handling code, I'm not completely sure), e.g. the flightstick trigger registers as JoyButton0 in the game but so does the thumb button on the throttle, and this behaviour is the same for all the buttons on both devices. Obviously this makes most of the buttons on one or both devices unusable for specific functions. Some duplication is acceptable, but you really need more than 16 buttons across both devices in order to make the best use of the HOTAS setup. BIGGER PROBLEM: "That ain't no problem..." says I, "...just create a T.A.R.G.E.T. profile with all the axes and buttons mapped the way I want". So I did this, and all the button mapping/keystroke generation worked perfectly. Except, as soon as I launch a craft and touch the joystick, all the control surfaces travel to their authority limit and stay there. When I push the joystick to the limit of an axis, the relevant control surface moves through its normal "rest point" to the other extent of travel, and then back to the first limit again when I release the stick back to centre. If I move the stick to the other limit on the same axis, the control surface in question exhibits the same behaviour. The throttle also seems to set its 100% limit at the middle of the DX_SLIDER axis' physical travel, and moving the throttle either side of this point causes the in-game throttle to move sharply back to 0%. Reversing the axes, either in the TARGET software, in the KSP input settings, or by changing the "deploy direction" of a control surface, merely results in the part moving to the opposite extent of travel on launch. All other response curve adjustments, absolute/relative settings, sensitivity and deadzone adjustments in TARGET and in KSP appear to have no effect on this behaviour. FURTHER BACKGROUND INFO: It should be noted that when observing the behaviour of the "Thrustmaster Combined" virtual device's axes (either via the Windows properties dialog or via the TARGET software's built-in "device analyser" function), all the axes and buttons appear to behave normally, the visual indicators sit at a center rest point (or lower extent of travel in the case of the Throttle/Slider axes) and move to their full extent of travel along with the appropriate physical movements of the controller/s. I've also tried previously suggested fixes such as starting the game with the physical throttle set at 50%, and I've tried starting the game with the joystick pulled over to the full extent of X/Y travel. No difference to be seen. Furthermore, I've tried disabling the TWCS throttle in the combined TARGET profile in case there was some weird axis mapping/config conflict occurring, and the FCS flightstick alone still exhibits the same behaviour on its assigned X/Y/Z/slider axes when being detected by the game as a "Thrustmaster Combined" device. POTENTIAL CAUSE: So it seems obvious to me that the issue lies with how Unity/KSP interprets the "rest value" of the virtual device's axes at startup. It assigns the centre "rest value" of the joystick axes as being one extent of travel and the axis limit (in either direction) as the other extent. But it's the opposite with the "virtual" throttle... the rest point is defined as being halfway along the physical axis (instead of at the lower limit of travel), with movement in either direction dropping the throttle back to 0% (or throwing it up to 100%, if the axis is inverted). When you analyse and think about this behaviour, it seems that Unity/KSP is getting the virtual device's "joystick" (self-centering) axes and "slider" (non-centering) axis behaviour ass-backwards. Self-centering axes behave as though the joystick's center rest position is one extent of travel and the axis limit/s are the other extent; i.e. behaving like a throttle/accelerator pedal. Non-centering axes behave as though the mid-point of travel is the rest position, with movement in either direction throwing the control to its limit; i.e. behaving like a self-centering joystick. But I have no ideas as to why this behaviour is only occurring with the combined "virtual" device, and not when the controllers are mapped as separate input devices. CONCLUSION: Sorry for the long long post, but I'm hoping this report might make possible some kind of fix in a future update, so I can use my AUD$250 HOTAS setup effectively in the game. At the moment I'm stuck using it as 2 separate input devices with severely limited button mapping/control options, which is pretty disappointing. I also suspect that squishing this bug might solve a lot of similar issues that people are having with other HOTAS/multi-input setups, especially where third-party "virtual device driver" software is involved. However, I also recognise that this is very much an edge-case bug, and probably not worth the dev time/cost to fix. But maybe the community can come up with its own fix... it's been done before. I've considered the possibility that this bug may be fixable by digging deeper into Thrustmaster's scripting engine/language - it's pretty much syntax-identical to C code - but the fact that Windows reports the virtual device as behaving normally leads me to believe that the issue doesn't lie with the TARGET profile/script, it's to do with how Unity/KSP interprets the input/rest position values of the virtual controller's axes. If I knew Unity at all I'd dig deeper into the game code/mod API to try and fix it myself, but that's beyond my scope at the moment. Feedback/input from anyone else using the Thrustmaster T.16000M FCS HOTAS setup specifically, or Unity/Mod developers generally, would be appreciated as a worthwhile contribution to this bug report thread. I'll capture a video of the behaviour and link to it from this post shortly. Logs and other supporting documentation etc. can also be willingly provided upon request. Cheers, BR

Game: I want to know if you can rebind the stage lock key (default on windows is alt+L) since it is to close to win + L and I wish to configure it to be on my joystick. Cannot find it in the settings menu, does the option exist?

So I'm almost certainly getting a thrustmaster warthog at this point and I just wondered what compatibility is like with KSP. For example, are there mods that would let you set up the individual throttles to control individual engines, set the switches to action groups and use hat switches to look around etc.

I was hoping the update to 1.1 would fix this but no luck. Stick itself works fine, pedals act as though they are off calibration and throttle is completely non-responsive. The buttons on the throttle work but the throttle itself does not. I use this setup with other games so I know the hardware works. I was using a Thrustmaster HOTAS X in KSP before and it worked fine and I am using the same bindings I had for it so the bindings should be correct. I am using Vanilla KSP 1.1, though the problem existed in the previous version as well. Does anyone know how I can fix this?