UJR - Universal Joystick Remapper. Fixes problems with sticks in KSP.

[Soda Popinski]

When you say "the physical stick keeps getting chosen", do you mean you are trying to make game bindings and the physical stick appears in the bindings list?

Are you using the QuickBind feature to avoid this problem?

Exactly. I've been doing it with the QuickBindSelect, move the joystick, then QuickBind and double click on the setting, but it always gets the "Wingman Force 3D" instead of Virtual Joystick. I got Virtual Joystick once on one axis, but strangely, when I checked the settings it had the same id ("id = joy0.1" or "id = joy0.4"). I tried changing these in the settings file to "id = joy1.4" assuming the virtual joystick was joy1, but that didn't seem to help. Any way to determine what the joyID number is for the virtual stick?

I've also tried the fix in the Advanced part of the Read Me, where it mentions Alt-Tabbing and moving the slider, but the phyisical joystick would bind before I could Alt-Tab. I suspect my joystick is just a little too old and out of use, that it's probably feeding sporadic signals in and grabbing the attention of the game.

Might be time for a new joystick. Anybody have any luck with the XBox controller?

Edited November 30, 2013 by Soda Popinski

[evilC]

As I have said before - I would NOT trust what KSP "calls" the axis you just bound.

Use the "QuickBind" button to move the virtual axis only in flight mode - does it manipulate the inputs?

Disable UJR and move the physical stick in flight mode - does it manipulate the inputs?

It is entirely possible that it is working, just KSP is calling the stick by the wrong name.

What I normally do is not use the KSP bind routine at all, I edit settings.cfg manually.

For example, here is how my entry looks for pitch:

AXIS_PITCH

{

name = Custom Mapping

id = joy1.1

inv = False

sensitivity = 2.637589

deadzone = 0.1371864

scale = 1

group = 0

switchState = Any

}

Not that the name field can be ANYTHING, so I set it to "Custom Mapping" so I know which ones I have done manually.

The id field is the stick and axis id, in the format joy<stick>.<axis>

Regarding XBOX pads - they work OK, but various binds in the game do not recognize the dpad (as it considers it an "axis"), only buttons.

However, UJR can let you work around this by mapping the dpad to buttons.

You can then use this to your advantage. For example, for me in flight mode, the dpad is throttle (Mapped as an "axis", reading physical dpad). However, when on EVA, the dpad is movement (Mapped to virtual buttons).

So as you can see, you can leverage the fact that UJR does not hide the underlying physical stick to double up on controls - as long as they do not cross over (eg for me, when in EVA, throttle does nothing, and when in a ship, the EVA walk commands do nothing, so it is safe for them to share a dpad).

[sal_vager]

This is really good, and needs to be in the Tools and Applications section really, so I've moved it.

Thanks for this evilC

[evilC]

No problem Sal, thanks!

Oh, and I do not normally nag or solicit for donations, but there is currently a fund going to cover the cost of having the vjoy device driver signed.

What would this mean for UJR? It would remove the need for win7 x64 users to enter Test Mode.

So if you find UJR useful, instead of clicking my donate link, please go here and donate to the driver fund instead. We only need to raise like another $100, so every little helps.

[Black-Talon]

AFAIK windows always uses a consistent ID for a given stick - when you have plug it in for the first time, it gets assigned an ID, so if you are saying that the stick IDs change in UJR dependent on what is plugged in, well that is a new one on me.

Have a play with JoyIDs, see if you can work out any patterns in the behavior, and maybe we can come up with something.

I finally had a chance to play with this further. You're right, the IDs rarely change. Much less than I thought. The problems I'd previously had basically had me not trusting it. Testing I see that it typically keeps the IDs the same. That said, they do change. I can't quite nail down the case where they change...but sometimes I plug in a controller and it'll bump one of the existing controllers down further in the list (as seen in JoyID). Luckily, with this utility it is much easier to figure out the new ID and correct my mappings.

It would still be amazing for KSP and other games if UJR did something like Nuke describes by using the name or GUID to help follow a joystick when it happens to change IDs. It would be one less thing I'd have to double check. Update: Given that I've now learned that KSP does it's own ID mix'n'match I now doubt that this would help my issue. :-(

Secondly, is there anyway UJR could assign the ID of vJoy so you knew it was also consistent? As you've discovered and leveraged yourself in your KSP config, as long as Windows Joystick ID stays the same, KSP will use virtual stick associated with the ID denoted in KSP's config (this is of course despite the name it displays in game). But my testing and experience shows this ID just doesn't always stay the same. Again, this is something I have to double check every time I play. Otherwise I rediscover how the joystick mapping menu is annoying to get to once you're already in game and your controls aren't mapped correctly. It makes for a sad first flight. :-( Update: Given that I've now learned that KSP does it's own ID mix'n'match I now doubt that this would help my issue. :-(

That said, especially with JoyIDs everything is so much easier to get right if I take a peek before starting. Life is so much better now! I just have to use 3 or 4 utilities to get what I need. :-)

Sharing one more great thing about this... now with a quick switch of the profile in UJR I can switch from flying rockets to flying planes and EASILY switch the rudder pedals from controlling roll (as preferred when in a rocket) to controlling yaw (which is obviously what you'd expect in a plane). This whole thread really just takes the Joystick + Throttle + Rudder situation in KSP to a usable level for me. And it's so gratifying to be taking off with a real joystick, using the throttle for a moon landing, and flipping toggle switches to raise or lower my landing struts!! I can't thank you enough!

Update: After more testing I've discovered that Windows rarely changes the Joystick IDs. KSP/Unity on the other hand does not use Joystick IDs that correspond to the Windows IDs. And these Unity Joystick IDs DO change when joysticks are plugged in differently. I don't know of anything that could stop this from being annoying.

Edited December 9, 2013 by Black-Talon
Updating given new understanding of issue

[Black-Talon]

Exactly. I've been doing it with the QuickBindSelect, move the joystick, then QuickBind and double click on the setting, but it always gets the "Wingman Force 3D" instead of Virtual Joystick. I got Virtual Joystick once on one axis, but strangely, when I checked the settings it had the same id ("id = joy0.1" or "id = joy0.4"). I tried changing these in the settings file to "id = joy1.4" assuming the virtual joystick was joy1, but that didn't seem to help. Any way to determine what the joyID number is for the virtual stick?

Soda, I think you're doing it just right! And I agree with evilC, despite the joystick axis binding reporting that it's bound to "Wingman Force 3D" it probably isn't. It's a very erratic behavior and never seems to be right. Did you try getting a plane on the runway and seeing if the controls were in fact bound correctly? Following exactly the method you're describing my setup works perfectly.

As for manually putting the ID into the config, I did exactly that months ago but had to guess each ID before I found the right one. Now that evilC has pointed out JoyIDs it *should* be so much easier. [uPDATE: While this *should* allow manually setting the ID to be easier, the IDs shown in JoyID and those used by KSP/Unity are not related. This means I don't know which ID I would put in the config.] However, I seem to recall the same changing ID issues I describe in a previous post. And I wonder if the IDs even correlate in a predicable way? KSP is obviously using a zero based index of Joysticks (joy0) vs. what's shown in JoyIDs (starts with Id#1). And it just so happens that my settings.cfg shows the configured JoyID as 2 when JoyIDs shows vJoy as #1 and #3 ID is currently empty. Seems potentially misleading...I'd go with the binding plan you described.

Now that I'm explaining this I'm wondering if perhaps part of the problem in KSP is that the IDs it's using are something it made up and that don't relate to windows joystick IDs correctly. This would cause the behavior of "changing joystick IDs" I described before EVEN when the Windows ID never changes...hmmm. I'll keep an eye on this and see what I can find out.

UPDATE:

Answers to questions above that reveal that there are in fact real issues -

"And I wonder if the IDs even correlate in a predicable way?" - Windows Joystick IDs and KSP/Unity Joystick IDs do not correlate in a way I've determined.

"I'm wondering if perhaps part of the problem in KSP is that the IDs it's using are something it made up and that don't relate to windows joystick IDs correctly." - This is indeed the situation, Windows Joystick IDs and KSP/Unity Joystick IDs do not correlate. KSP/Unity Joystick IDs change. This causes uncertain joystick axis bindings.

"This would cause the behavior of 'changing joystick IDs' I described before EVEN when the Windows ID never changes...hmmm." - This speculation was correct. KSP/Unity Joystick IDs change when different joysticks are plugged in (even when the Windows Joystick IDs stay the same). This causes my previous bindings and mappings to be wrong and annoying to discover and correct.

And thus, currently, I have no idea how to get rid of the inconvenience of discovering my bindings are wrong. I just double check my bindings before playing each time. In addition, this means that I don't know any reliable way to manually set they Joystick ID in the config since there is no way to know which ID should be used.

Edited December 9, 2013 by Black-Talon

[Black-Talon]

No problem Sal, thanks!

Oh, and I do not normally nag or solicit for donations, but there is currently a fund going to cover the cost of having the vjoy device driver signed.

What would this mean for UJR? It would remove the need for win7 x64 users to enter Test Mode.

So if you find UJR useful, instead of clicking my donate link, please go here and donate to the driver fund instead. We only need to raise like another $100, so every little helps.

Donated! I would LOVE to be able to do all this without the frustration of Test Mode. Plus I think that would make the likeliness that others would use it so much greater!! Thanks!

[evilC]

Donated! I would LOVE to be able to do all this without the frustration of Test Mode. Plus I think that would make the likeliness that others would use it so much greater!! Thanks!

Dude, you are too generous I already forwarded the money you put into the UJR pot to the driver fund!

And I totally agree with you - I think vJoy is poised to become the ubiquitous virtual stick app that PPJoy once was, and that can only be a good thing for UJR.

When you say that you use different configs (ie pedals for rudder / pedals for roll), do you tab out of the game and swap profiles?

I was thinking of adding some kind of quick profile switching to ADHD (The library that underpins UJR), but have been unsure of how to implement it (as in the interface). I think the smartest way would be to add an extra binding for each profile, but that would require some changes to the code, to activate that binding for profiles other than the current one.

I also really think that as far as UJR / AHK is concerned, in general sticks do not change ID of their own accord.

The obvious exception is when you install or uninstall vJoy - that will grab ID 1.

I have 6 sticks installed, and since I got them set up they never, ever change.

KSP IDs jump around, but as I said I think that is because it labels sticks not as "stick number" but as "connected stick number" (ie it only counts connected sticks).

[Black-Talon]

When you say that you use different configs (ie pedals for rudder / pedals for roll), do you tab out of the game and swap profiles?

I was thinking of adding some kind of quick profile switching to ADHD (The library that underpins UJR), but have been unsure of how to implement it (as in the interface). I think the smartest way would be to add an extra binding for each profile, but that would require some changes to the code, to activate that binding for profiles other than the current one.

Yes, I tab out (or run in Windowed mode when I'm testing) to switch profiles. And for KSP this isn't a big deal at all. I can see this being a problem for other games if profile switches are needed for them. Rarely am I switching from an atmospheric plane to a rocket, but when I do, tabbing out to switch flight profiles is easy enough for me.

I also really think that as far as UJR / AHK is concerned, in general sticks do not change ID of their own accord.

The obvious exception is when you install or uninstall vJoy - that will grab ID 1.

I have 6 sticks installed, and since I got them set up they never, ever change.

KSP IDs jump around, but as I said I think that is because it labels sticks not as "stick number" but as "connected stick number" (ie it only counts connected sticks).

After further testing I completely agree that my earlier suggestions to handle Joystick ID changes would not help my issue. The root problem seems to be exactly what you've said, "KSP IDs jump around, but as I said I think that is because it labels sticks not as "stick number" but as "connected stick number" (ie it only counts connected sticks)." I've updated my previous posts with this new information.

Unfortunately this creates a nuisance for me that I have to manually avoid by rebinding vJoy in KSP each time I launch. So far, I haven't found any predictability to the KSP/Unity IDs. And when they change, bindings will be wrong. I currently don't see any way that UJR, AHK, or vJoy could solve this for me.

My primary case where I've seen this is where I have all controllers unplugged but vJoy installed. vJoy is WinJoystick ID#1 in this case. In KSP, vJoy can be bound to the proper axis controls and the config will show us that the KSPJoystick ID is 0. All axis IDs match up to those used in UJR. This all sounds very nice and makes sense.

Unfortunately, when I plug in my stick, throttle, and pedals (and technically I then install a 2nd virtual Joystick which is done by Thrustmaster's TARGET software which unloads the Stick & Throttle controllers), I am left with:

WinJoyID1 = vJoy (doesn't change)

WinJoyID2 = none (was the stick but TARGET eliminates it from showing up in Windows and replaces it with a virtual joystick)

WinJoyID3 = none (was the throttle)

WinJoyID4 = Clubsport Pedals

WinJoyID5 = Thrustmaster Virtual Game Controller

With this setup in Windows, KSP considers vJoy to be Joystick ID 2. I can't make sense of this change from ID#0 to ID#2. Perhaps (and I have not tested this) the Unity/KSP joystick list is alphabetical? Which is the only way I can imagine that JoyID2 would relate to vJoy...

KSP JoyID0 = Clubsport (did not confirm this is accurate)

KSP JoyID1 = Thrustmaster (did not confirm this is accurate)

KSP JoyID2 = vJoy (vJoy is definitely KSP JoyID 2)

But whatever it is, I don't trust it and it seems to change depending on what I have plugged in when I play. I'm hoping for a Unity/KSP change in this area. I'll keep updating as I learn more!

-Talon

UPDATE: I quickly bound my Thustmaster and Clubsport controllers to an unused axis and after exiting the game I examined the config. The KSP/Unity Joystick IDs, in relation to the Windows Joystick IDs (in this exact specific setup) are:

KSP JoyID0 = Thrustmaster Virtual Game Controller (WinJoyID5 - last installed, also last in Windows list)

KSP JoyID1 = Clubsport Pedals (WinJoyID4)

KSP JoyID2 = vJoy (WinJoyID1 - first installed, also first in Windows list)

So now I'd speculate that perhaps the KSP/Unity Joystick IDs are a reversed list of Windows IDs?? Still untested, and still don't trust it.

Edited December 9, 2013 by Black-Talon
corrected based on new information

[Black-Talon]

I've been using your recent update of UJR to 6.0 and ADHD (2.1 I think) tonight, you've been busy! Some nice goodies in there!

I'm a little thrown off by a couple of the changes (or perhaps bugs) with the new merge and "rests high/low" option. But the concepts are solid and I'll details of my confusion once I've got a handle on it. In the mean time, nice work as always!

[evilC]

Merging still works in the same way, it is just that each merged axis is now on a different page.

Slightly more confusing if you are using axis merging, I will agree, but for everyone else it makes the app simpler.

Just set up merging as you did before (except you only need to set the right pedal on the "Axes 2" tab to "Merge") and it should work.

However, now you can also set the left pedal (on the Axes 1 tab) to "Rests H". This will make the deadzone and sensitivity settings work properly for *both* pedals (ie independent settings for each pedal) . If you do not use those settings, you can ignore the "Rests" options.

The main reason for the layout change was to remove the possibility of bad settings (eg 3 rows set to virtual axis 1) and also enable me to know which row was for which virt axis, so I could disable rows for axes that do not exist on the virtual stick.

I am open to suggestions though, if you think things could be explained better or the way I have named things is confusing then let me know.

Sounds like you are having way more issues than me with KSP.

How about this for an idea?

Have you tried using the joyIDs app to move the IDs around? Try making the TM stick and the virtual TM stick the highest IDs.

I am starting to think that it may be TARGET that is causing the bulk of these issues.

I know it could be a ball-ache, but it may be worth trying uninstalling TARGET and seeing what happens if you just use the TM stick with no drivers.

I know KSP is guilty of some issues itself, but I suspect we may be seeing two issues layered on top of each other here.

[evilC]

Oops, 6.0 had a bug with axis merging, it was not working as intended.

The split function I put in at the last minute broke it.

New version up, 6.1

Pedals to rudder should work properly now.

[Black-Talon]

Oops, 6.0 had a bug with axis merging, it was not working as intended.

The split function I put in at the last minute broke it.

New version up, 6.1

Pedals to rudder should work properly now.

I wanted to quickly reply that 6.1 does fix my merge confusion. I was confused why the slider (and output) inverted when I set "Rests H." It no longer does this.

Sadly, I had a frustrating day with the rest of it today. I don't have enough consistent information to be truly valuable (my software testing/dev background haunts me perhaps - I expect much more concrete conclusions than this). But if you want to hear my experiences and gut feelings thus far read on...

Sounds like you are having way more issues than me with KSP.

How about this for an idea?

Have you tried using the joyIDs app to move the IDs around? Try making the TM stick and the virtual TM stick the highest IDs.

I am starting to think that it may be TARGET that is causing the bulk of these issues.

I know it could be a ball-ache, but it may be worth trying uninstalling TARGET and seeing what happens if you just use the TM stick with no drivers.

I know KSP is guilty of some issues itself, but I suspect we may be seeing two issues layered on top of each other here.

1. I currently don't believe that Target isn't making anything worse. I recently added it to the equation (when we were discussing all this a week or two ago I wasn't using it) and nothing new showed up. Only the old problems. I have regardless disabled it and continue to see the inconsistent KSP Joystick IDs. I also have always had problems with joystick recognition.

2. Today the Windows Joystick IDs correlated with the KSP/Unity IDs in a completely new way. I didn't really get to do the tests I wanted (or that you suggested). That said, today's notes on that seem to suggest that it isn't consistent:

12/12/2013

(Without TARGET)

WinId#1 vJoy joy1

WinId#2 Joystick joy0

WinId#3 Throttle (KSP Can't Find this Joystick? Windows shows it working.)

WinId#4 Pedals joy2

(With TARGET) - BTW, this got me to a place where I could play, but as you can see it's different than the other day.

WinId#1 vJoy joy1

WinId#2 [none]

WinId#3 [none]

WinId#4 Pedals joy2

WinId#5 vThurst joy0

12/08/2013

WinId#1 vJoy joy2

WinId#2 [none]

WinId#3 [none]

WinId#4 Pedals joy1

WinId#5 vThrust joy0

3. A problem I haven't mentioned before plagued me to death today. Sometimes KSP just doesn't know about my Joystick. Today it couldn't find my physical throttle even though everything worked well in Windows. So eventually I enabled TARGET and it couldn't find vJoy. Rebooting didn't solve this. Uninstalling/Re-installing vJoy did. FWIW - the problem exhibits itself when I go to bind an axis in KSP, while KSP is waiting for stick movement I can move the stick (sometimes this means virtually moving the stick with QuickBind in UJR) and KSP detects nothing (the same movement shows correct axis movement in the Windows Controller properties). Even stranger: typically when this is happening, KSP will then recognize my mouse movement as a joystick axis and bind it (this put joy3 in the config, but was referencing my mouse for that axis).

I know some of this sounds crazy but the part about the mouse binding as a Joystick Axis is something I am certain of. As is the changing KSP Joystick IDs. I've spent a stupid amount of time trying to figure out what the heck is wrong only to discover that moving my mouse throttles the craft up and down but nothing else does. The time spent and painfulness of this issue was new today. But the issues themselves I have seen many times. I usually just fiddle with it (restart KSP, restart UJR, reboot, etc) until it starts working. Today my typical fiddling didn't help and I became sad. :-p

So that was today. It sure doesn't look like a UJR problem. But thanks for hearing out my frustrations. :-)

-Talon - *begging for better Unity support of joysticks*

Edited December 13, 2013 by Black-Talon
fixing typo in notes

[evilC]

12/08/2013

WinId#1 vJoy joy2

[...]

WinId#5 vThrust joy2

I doubt both of those are joy 2. You probably had UJR using the thrustmaster stick as an input?

It seems to me that vJoy is not moving from one ID to another, so I do not really sure why you are bothered so much about the stick IDs changing from KSP's perspective.

Sure, KSP may decide one day that vjoy is one ID, and one day that it is another, but this is quite easily worked around.

Just make sure all references to sticks in the KSP config file are to the vjoy stick. Then, if the vjoy ID changes in KSP, simply do a search and replace in the KSP config file.

If all other references to sticks are removed, you can quite safely replace all instances of "joy0" with "joy1".

Maybe even keep various copies of the config file and just swap them out.

Finally, I am not 100% sure it is a unity issue. I have other unity games that behave OK. Monaco even lets you plug in/out controllers while the game is running.

What may be worth doing is taking a fresh machine that has never had any sticks plugged into it and seeing if the problem can be easily reproduced. I have a laptop, I may give this a go.

If we could get a bug report that allows squad to replicate the issue, we stand more of a chance of getting it fixed.

[evilC]

I did some testing with my laptop and have submitted a bug report here.

Also, it may be worth checking the "preferred device" settings in windows. It is definitely set to vjoy, right?

[Black-Talon]

I doubt both of those are joy 2. You probably had UJR using the thrustmaster stick as an input?

Good catch. You are correct, that was a typo. Data from the 8th should have matched my notes that I posted a few days ago. When I changed the formatting of the text I made a mistake. I'm fixing the post now such that it matches the data in my original notes. Details below...

Yes, in UJR I pull stick and throttle from the Thrustmaster Virtual Game Controller and assign it to vJoy. Once configured this works wonderfully!

On the 9th I posted this about my experiences on the 8th:

The KSP/Unity Joystick IDs, in relation to the Windows Joystick IDs (in this exact specific setup) are:

KSP JoyID0 = Thrustmaster Virtual Game Controller (WinJoyID5 - last installed, also last in Windows list)

KSP JoyID1 = Clubsport Pedals (WinJoyID4)

KSP JoyID2 = vJoy (WinJoyID1 - first installed, also first in Windows list)

On the 13th I posted about my experiences on the 12th and compared it to the 8th in a new format. Doing so again without the typo would look like this:

12/12/2013
WinId#1		vJoy		joy1
WinId#2		[none]
WinId#3		[none]
WinId#4		Pedals		joy2
WinId#5		vThurst		joy0

12/08/2013
WinId#1		vJoy		joy2
WinId#2		[none]		
WinId#3		[none]		
WinId#4		Pedals		joy1
WinId#5		vThrust		joy0

It seems to me that vJoy is not moving from one ID to another, so I do not really sure why you are bothered so much about the stick IDs changing from KSP's perspective.

Sure, KSP may decide one day that vjoy is one ID, and one day that it is another, but this is quite easily worked around.

Just make sure all references to sticks in the KSP config file are to the vjoy stick. Then, if the vjoy ID changes in KSP, simply do a search and replace in the KSP config file.

If all other references to sticks are removed, you can quite safely replace all instances of "joy0" with "joy1".

Maybe even keep various copies of the config file and just swap them out.

With regard to "vJoy is not moving from one ID to another," in Windows this definitely has been proven to be the case. The Windows Joystick ID for vJoy does not change.

However, "KSP may decide one day that vJoy is one ID[in my case, on the 8th it was ID 2], and one day that it is another[on the 12th it was ID 1]" is exactly what I am bothered so much about. With this being the case the following occurs almost every time I play KSP:

1. Plug in joysticks to use in KSP
   
2. Launch Joystick stoftware (UJR, TARGET) and quick test controls
   
3. Launch KSP and get a ship to the launch pad
   
4. Realize that the controls don't work
   
5. Back out to the main menu and rebind the axises in setup
   
6. (sometimes) Realize that KSP won't detect vJoy input for unknown reason and restart UJR, KSP, Windows until it works
   
7. Once sticks are bound correctly, get back to playing and dread the next time I want to launch the game

Steps 4-6 are what I've been describing as "frustrating," "annoying," a "nuisance," and an "inconvenience." And you are correct, these issues can be worked around. That's what I'm doing now and why I find so much value in UJR. UJR has made so many things possible for me with KSP. I'm really loving it!

However, doing a find and replace in the config, or swapping out configs once I figure out what the new ID in KSP is (and restarting KSP to reload the config) is still just as frustrating, annoying, and inconvenient as my current method. I've been venting my frustration on this in your thread. :-/ And hoping someone might have determined a method to make the process of "make sure all references to sticks in the KSP config file are to the vjoy stick" more convenient. *fingers crossed*

Finally, I am not 100% sure it is a unity issue. I have other unity games that behave OK. Monaco even lets you plug in/out controllers while the game is running.

This is really encouraging to know. Perhaps Squad can get KSP working like those other setups! I did not know this.

What may be worth doing is taking a fresh machine that has never had any sticks plugged into it and seeing if the problem can be easily reproduced. I have a laptop, I may give this a go.

If we could get a bug report that allows squad to replicate the issue, we stand more of a chance of getting it fixed.

Agreed, I can do this easily if you think it'll help. Your bug report looks great though. It describes the issue I'm having well. I may add to it the "Why is this really annoying for Joystick users" to assist Squad in setting the priority of the bug. And I'll stay optimistic that this can be fixed in KSP by Squad.

Thanks for the awesome utility and hearing out my pain points!

-Talon

PS - Yes, vJoy has been the "preferred device" the entire time I've been using vJoy. When I was originally setting it I wasn't sure what it did but hoped it might help with this ID changing stuff in KSP.

Edited December 13, 2013 by Black-Talon

[Black-Talon]

EXCITED!

I finished writing this long post and then headed over to listen to some KerbalKon and the plans for .23. As you saw from my post I'm of course hoping that they'll announce a Joystick improvement...but on the inside I'm knowing they won't.

So impressed and surprised to hear HarvesteR at 20:36 http://www.twitch.tv/ksptv/b/486870322 - "Good news on Joystick Axises as well! ..."

I know everyone has reported issues with trying to map axises when multiple joysticks are connected. There was indeed a very bizarre bug around how joysticks were enumerated. We fixed that and it should be much better and much more reliable to map multiple joysticks to KSP.

I nearly fist pumped. =) But super excited!

Edited December 13, 2013 by Black-Talon

[Jivaii]

Trying to get Saitek X-55 and Saitek Combat Rudder pedals to register with UJR, but having some issues with it not wanting to recognize the buttons on the stick (It registers the X/Y axis, but nothing else)

Tried following the instructions, but still confused and it's saying there's an updated library?

Edit: Got them all to register axis on UJR, can't get them to register together in KSP, the joystick isn't registering axis, but will register buttons in KSP.

Edited May 11, 2014 by Jivaii

[evilC]

Yeah, KSP is a bit crap in this regard.

KSP has no concept of which stick a button is on.

In other words, while axis bindings have a stick number and an axis number, button bindings only have a button number but no stick number.

So, I am not sure how to help you.

I know it is possible to do funky things with KSP and UJR though - my current setup allows me to use an XBOX pad (Normal usage) or a flight stick + throttle (VTOL flying) and switch between the two simply by changing the UJR profile. So while button 1 on my flight stick may do one thing, button 1 on the XBOX pad does something completely different.

My biggest advice would be to try to edit the config file (settings.cfg) manually. Using the KSP binding interface is an issue. If you do use the KSP binding interface, use the "quickbind" feature of UJR to press a button on the virtual stick without pressing a button on the physical stick.

[Cabin2N]

Would it be possible to have a key-bind or joystick bind to switch profiles?

This a great app for having different setups for atmo and space controls but my joystick (x-55) has this mode selector that is just begging to be used to switch profiles

[evilC]

Yeah, something I had considered, but it was just a case of working out a mechanism to do it.

I did, however, just write UJRC - UJR Companion.

This is a library to let you define unlimited shift states (ie button alone does one thing, button + shift_1 = something else, button + shift_2 = another thing.)

It is not dependent on UJR, but intended to be used at the same time. UJR handles axis mapping etc, UJRC handles button config.

No GUI unfortunately, you have to edit config files manually

Edited May 25, 2014 by evilC

[GranoblasticMan]

Hmm, seems like this bug still hasn't been fixed in the latest release of KSP =(

[OminousPenguin]

Hi all,

Bit of a necro but this is the most relevant thread and it doesn't make sense to just create a new thread.

As per my feature request I have implemented additional deadzone options: You can specify separate deadzone amounts for each end of an axis, including either side of the mid-point. This hastily assembled diagram shows the idea:

There are a few use cases for this. Most obviously is the ability to have a deadzone at either end of a throttle axis. In the current UJR you can only have a deadzone at one end. (See here http://imgur.com/DYV9AV9)

As you can see below, there are now 4 deadzone fields: Positive high & low, and negative high & low. For axis that rest at one end only the positive high/low deadzones are used.

In addition, I have added a new merge mode: 'Limit'. I was wanting a way to increase the precision of my joystick - Using the new merge mode I can use my throttle to set a max limit on my X/Y axis - eg With my throttle set to 10%, my X and Y axis are both limited to 10%. So with the stick 50% pushed to the right, the virtual axis is at 5% and with the stick fully pushed to the right, the virtual axis is at 10%.

This means I can use the full range of motion of the stick to have finer control over small movements.

In the image below I have my throttle at 50% and my stick fully pushed to the right. - Note that the output of the axis is 74.70 (ie 75%).

Another thing to note is that the Physical input column on the axes 2 tab now shows the value of that axis after deadzones + sensitivity adjustments rather than the original physical value.

There are a few tweaks I want to make before releasing this but I wanted to get your comments.

Thanks.

Edited January 18, 2015 by OminousPenguin

[evilC]

Really cool!

I always wanted some way of re-scaling an axis (eg throttle with detents that dont match in game scales perfectly) and this may actually be one way of handling it I suppose.

The only reservation that I have about merging this into UJR is that the extra boxes may confuse some people.

How about maybe we try and work a checkbox in there to enable "Advanced deadzone mode" that hides the extra boxes and resizes the normal ones?

[OminousPenguin]

Good idea. That concern had occurred to me.

In addition I'll swap the positive and negative boxes so the negative are on the left, and I'll disable the negative boxes for axes that rest at one end rather than the middle.