BlueRaven

No, thank you guys. A remarkable phenomenon, and a huge inspiration to so many people. Be proud of everything you've done here.

Just wanted to say a quick Thank You! This has to be at least the 4th or 5th time I've been playing the game and thought "hmm... I wonder if I can..."; and sure enough, linuxgurugamer has a mod for that. Looking forward to playing around with this fork, I'm surprised that more people haven' t tackled music/sound mods for KSP. Anyway, thanks again Sir for all your hard work in consistently making a great game even better. (Edit: added "Sir" after watching the KSP Effect video and realising I'm addressing the true Modfather).

Thanks for the reply mate. I've come up with a usable default button setup that's working okay for now, but I'd really like to be touching the mouse a bit less frequently. I was unaware of JoyToKey and will check it out, it sounds like a good workaround solution as you said. Cheers.

"The Kershank Redemption" would seem like a fairly epic project in terms of locations, cinematography, etc... and I'm not sure if Cupcake has the necessary budget to retain Mr Freeman as a narrator? "The Usual Kerbals" would require quite a lot of thought put into screenplay, some clever editing, and some outstanding performances from the ragdolls. "The Great Kerscape" would work well however. EDIT: Cupcake's title for this vid makes me ponder the question: does anyone have a "Scrapheap Challenge" style KSP challenge going over on reddit? Or, sorry, "Junkyard Wars" style challenge, if you're from 'Murica. Because that could be fun.

Sweeeet, moar Cupcake! Mate, this is just genius, could not stop laughing the whole way through. Really nice way to kick off the year. Happy 2018, cheers from sixstringedthing

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