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

[evilC]

I had problems getting KSP to work right with an xbox pad. It did not like the shoulder analogue axis and recognised the dpad as a hat (axis) not buttons.

An app I wrote called UJR solved all these problems, so I thought I would link it here in case it helps anyone else.

http://www.autohotkey.com/board/topic/89279-ujr-universal-joystick-remapper-using-vjoy/

It is also better for deadzones and sensitivity as you can preview the input and output and tweak until it is just as you want it.

If KSP recognises the underlying physical stick, go into windowed mode, and use "manual control" in UJR to bind the virtual stick in KSP without moving the physical stick.

However, this can be used to your advantage - for example in ship mode, I use the dpad to control throttle, and the PHYSICAL hat is bound to throttle axis.

In character mode, I use the dpad to walk around, and this is bound to VIRTUAL stick where I remapped the physical dpad to virtual buttons.

So, in other words, by remapping your dpad/hat to virtual buttons, you can map the dpad to the physical stick to bind to an axis or virtual stick to bind to a button.

WARNING: uses vjoy, which has unsigned drivers. Requires test mode in x64 OSes.

[Black-Talon]

Thank you for this - amazingly helpful.

[evilC]

FYI, there has been a major new release of this app since I last posted.

It should now be significantly easier to map the virtual stick to ingame functions - no more tabbing out is required, it can all now be done from ingame.

[Black-Talon]

evilC, I've already downloaded 5.1 and the new QuickBind is indeed very helpful! Thank you!

I'm still struggling with merging two racing pedals into a single axis to use as a rudder. Setting it up works perfectly but a glitch develops in the rudder controls. As I'm flying a twitch kicks the rudder full right occasionally. Extremely frustrating as it knocks the flight out of SAS control and can be devastating to your flight or landing. Have you or others experienced this? Any ideas? It doesn't happen if I map a non-merged axis

Definitely a great utility, thank you. I sent you a few pounds in thanks!

-Talon

[Nuke]

there are several utilities that do this. this one actually looks good. but my ch gear does this for me

[FenrirWolf]

This looks like it could be handy. I might have to take it for a spin.

[evilC]

First up, regarding donations, they are especially welcome at the moment because we have a fundraiser going to pay for signing of the vJoy driver so that Test Mode is no longer required. Black Talon - I will redirect yours to that fund, thank-you.

Now on to your issue.

A couple of questions:

1) When this kick happens, do you see anything in the game controllers window (Start -> joy.cpl, double click vjoy controller). If you cannot normally see it, could you try playing KSP in windowed mode with it (And ideally UJR) visible? What do those apps display during the "kick"?

2) Are you 100% sure it is not your pedals? I have a cheap stick that does a similar thing, but it is due to dodgy potentiometers.

3) It does sound like it may well be to do with the axis merging code. To be honest, I have never used it myself much in anger.

Any info you could give me to help replicate could help. What kind of pedals are they? I have G27 pedals. If different, could you tell me which way they idle (At 0? 100?), do you need to use invert etc?

4) Finally, I could probably knock up some test code to only handle the pedal merging, which would make debugging much easier.

Do you know any coding? What UJR is doing is really rather simple - axis are read in as 0-100 values, and are output as 0-32767 values, so a simple in-> out would be multiplying by 327.67.

If you are at all comfortable with coding, I could maybe knock up some test code and between us we could hack away at it until it does the job properly.

Hope this helps.

Edited November 25, 2013 by evilC

[evilC]

there are several utilities that do this. this one actually looks good. but my ch gear does this for me

There are benefits of using UJR in addition to or instead of the manufacturer's software.

1) Your CH software will only let you do stuff with your CH stick. If you want to merge your CH stick with TM pedals into one stick, I doubt it would do that.

2) Normal windows sticks generally need to be plugged in before a game is started, a virtual stick does not, as the virtual stick is always "plugged in".

This means that if you decide to use a stick with a game, you can just plug it in, (tab out to UJR to config it if you need) and then play. Also, if you decide you do not like that stick for that game, but have another profile in UJR that maps a different physical stick to the same virtual stick, you can swap sticks without having to remap stuff in the game!

3) Functions. Never seen manufacturer software that can merge axes for example. TM TARGET may be able to do it, but I would not be surprised if you needed all TM kit to do it.

[evilC]

Boss called in sick today, so looks like not much for me to do.

Plugged in my G27, having a play now.

I think I have replicated the issue, but only very briefly.

Whatever, looking at the way axis merging is working, I am not happy with it - it is too confusing.

To set up axis merging correctly, currently both pedals need to move the slider in the same direction.

If you want to invert the result, you need to invert both axes.

I think it would be better if you set up the left pedal axis to move the slider left (from a resting position of full right), and the right pedal to move it's slider right.

Once you have that set up, set them both to the same virt axis and enable merge, and it should be the right way around.

I think this will make the maths for merge mode simpler too - if the axes are set up like I mentioned, then you just need to average the two inputs to come up with the output.

[evilC]

Heh, the change I was talking about was indeed way easier.

my old code:

val := ((val/2)+50) + ((merged_axes[%ax%]/2) * -1)

new code:

val := (val + merged_axes[%ax%]) / 2

The result is a much more intuitive Merge mode

Now I am not sure about your bug, but I think the smartest thing to do is for you to guinea pig the new code for me and see what it does for you.

As I have changed how merge works, if I roll out the code it will break other people's merge setups. Not a huge deal if the end result is worth it, but if it doesn't even fix your problem then I probably need to do more work before rolling out a new version.

Here is a link to the beta test version:

http://evilc.com/files/ahk/vjoy/ujr_beta.zip

Simply pop the ujr_beta.exe from that in the same folder as ujr.exe and run the ujr_beta.exe instead.

You will have different profiles too, just to be safe, but you can rename stuff as required.

[evilC]

Heh, just as I uploaded that, I had one of those eureka moments.

The merge code was assigning the value of the first axis to the merged axis, then later on averaging with the 2nd axis and re-setting the merged axis.

This of course could cause a momentary "kick" in one direction, which would only be aggravated by and momentary delays in the code.

I have uploaded a new beta - 5.3, same link as in the previous post.

I am 99% confident that this will solve your problem.

Furthermore, I have been thinking about the overall structure of the axis processing code, and it could maybe do with a bit more work.

I have made a post on the AHK forums asking for advice as to the best way to go about structuring the code to maximize responsiveness whilst minimizing CPU usage, so we will see what becomes of that.

Edited November 25, 2013 by evilC

[Nuke]

There are benefits of using UJR in addition to or instead of the manufacturer's software.

1) Your CH software will only let you do stuff with your CH stick. If you want to merge your CH stick with TM pedals into one stick, I doubt it would do that.

2) Normal windows sticks generally need to be plugged in before a game is started, a virtual stick does not, as the virtual stick is always "plugged in".

This means that if you decide to use a stick with a game, you can just plug it in, (tab out to UJR to config it if you need) and then play. Also, if you decide you do not like that stick for that game, but have another profile in UJR that maps a different physical stick to the same virtual stick, you can swap sticks without having to remap stuff in the game!

3) Functions. Never seen manufacturer software that can merge axes for example. TM TARGET may be able to do it, but I would not be surprised if you needed all TM kit to do it.

there are some advantages to not being locked into a stick manufacturer. for games though, the ch software is more than sufficient. it can merge axes, it can split axes, it can make fake axes with any number of buttons, its totally scriptable. its probibly the top stock software for any joystick product. only thing that might compete is what comes with a high end thrustmaster (as for saitek, their software is just a keymapper).

i do use virtual sticks other than the ch ones. for example i own a trackir and 9 times out of 10 the game i want to use it on doesn't support it, and i used to go through a virtual driver to make it work. i also do a lot of electronics projects where i need to get data from an arduino into the pc (such as logging imu data), and the joystick virtual interface is perfect for that. up till now i was using ppjoy. but its dated and loaded with bugs (and ive only been able to talk to it from a c application, which made it difficult to slap together an interface).

now the vJoy driver that this application is built on can be accessed through a dll. i pretty much just (this very night) wrote a lua interface (through alien) for the driver, so i can now slap together a script to act as a feeder application. talking to arduino can be easily accomplished through ethernet, or serial interfaces. i also accomplished joystick in and freetrack in through lua, so i can script my way to control perfection at this point. it is in my interest that vJoy gets signed though.

Edited November 25, 2013 by Nuke

[evilC]

oh really? I didn't think the CH software was that advanced.

Pretty impressive.

I own a TrackIR too, been doing anything interesting with it?

Do any of your sticks have multiple hats? Would you maybe know how to circumvent AHK's limitation of only being able to read 1 hat?

I think it is possible via DLL calls and such, but wouldn't know how to do it. I would probably try to tinker if I had a stick with more than 1 hat.

[Nuke]

i was able to transmit the data over a wireless transceiver to control a robot's camera turret. that was pretty awesome.

as for the hats, i have 8 of them. but they all respond as buttons except for the 2 8-way hats (one on each controller). but a device (or virtual controller) can only have one true hat, the rest are treated as buttons. you can map pretty much anything to anything. ultimately you are limited to 8 axes, 32 buttons and a hat, for any virtual controller (or real, but this is a direct input limitation).

cms scripting also lets you have 128 buttons and 64 axes. you usually source actual data from a physical control, transform it somehow, and then store it in one of the cms outputs, which can be bound to axes and buttons that the game can see (up to 16 virtual controllers and a virtual mouse). downside is you really have to be able to code to use it. its a custom scripting language and the help files give pretty useful examples. heres a simple axis combining script:

script
CMS.A1 = 128 + (JS3.A2/2) - (JS3.A1/2);
endScript

but there are lots of features that dont require programming skills. buttons can be mapped to keystrokes, axes can be mapped to a series of keystrokes (old flight sims that use 1-0 as throttle for example). buttons can cycle through lists of keys. you can have keystrokes controlling axes (up down and center commands). really i have barely scratched the surface of what you can do with it.

its quite overkill. the only drawback is you cant use the software for non ch stuff, which is quite sad.

Edited November 25, 2013 by Nuke

[evilC]

Windows does indeed support multiple hats natively.

The "hats" box gets multiple arrows of different colours when you move them.

Like so (Notice two arrows, one red, one blue):

In fact, the site I found that screenshot on is talking about arduinos and stuff. May be of interest.

[Nuke]

i didnt know about the multiple hat support. i guess i was basing it on what was on wikipedia.

with reference to the aduino thing, idk why they are using 8 bit axes, the atmega320/atmega32U4 mcu has 10 bit adcs (which i usually supersample to 16-bit with some fixed point magic). i dont have a leo (yet, i ordered one though) so i pretty much use a serial stream at 115200 baud, decode the packet and feed it to ppjoy with a c console application. i was getting decent 10-bit resolution at about 50 updates/sec (i could have gone faster but i ran into latency caused by buffers always being full). using a hardware usb interface would be orders of magnitude better though. in the mean time i expect better results with the lua->vJoy interface though luacom (serial) or luasocket (tcp/ip) libraries, and i can make it shiny with the iup interface instead of a console.

[Black-Talon]

Heh, just as I uploaded that, I had one of those eureka moments.

The merge code was assigning the value of the first axis to the merged axis, then later on averaging with the 2nd axis and re-setting the merged axis.

This of course could cause a momentary "kick" in one direction, which would only be aggravated by and momentary delays in the code.

I have uploaded a new beta - 5.3, same link as in the previous post.

I am 99% confident that this will solve your problem.

Furthermore, I have been thinking about the overall structure of the axis processing code, and it could maybe do with a bit more work.

I have made a post on the AHK forums asking for advice as to the best way to go about structuring the code to maximize responsiveness whilst minimizing CPU usage, so we will see what becomes of that.

I was all geared up to do some serious debugging and data reporting BUT, far better, the 5.3 beta patch works awesome! I'll report more as I get using it (a little distracted at the moment) but, extremely grateful for the great utility and extremely responsive fix! Thank you!

[evilC]

Thank you!

5.3 has been rolled out via the update notification system.

[Black-Talon]

Everything is still working wonderfully!

I am however curious what others have found as their preferred solutions to the Changing Joystick ID issue?

To be clear I'm talking about...

1) KSP/Unity maps an axis by noting it's Joystick and Axis ID in the config. This would be fine except those Joystick IDs change depending on ... who knows ... but most likely order they were plugged in or initiated in a system boot.

2) UJR basically does this same thing by keeping note of the Joystick and Axis ID. So when I reboot I have to reconfigure UJR and then KSP before I can play.

I've read a few ways to solve the various problems but thus far have stuck to *trying* to keep vJoy as ID 1 and getting KSP mappings tied to that. Then this makes it easy to just shift things around in UJR and I'm off and running. But it's pretty frustrating when it gets out of whack.

I'm currently trying to get a setup working that has anywhere from 3 to 6 joysticks plugged in at any given time. It's semi-frequent that I'll unplug one which will throw off UJR.

Thanks for your ideas,

Talon

[evilC]

I have experienced weirdness in the past with KSP - as you said, the game seems to decide the virtual joystick is a different ID and such. Also, for me when binding, it always calls stuff "Virtual Joystick", even if I moved a stick unconnected with the virtual stick.

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.

Get the JoyIDs utility from here.

Run that - the ID listed for each stick should be the same as the ID UJR uses for that stick. I have never seen this change - I can have just one stick plugged in or all my sticks plugged in, and UJR will always use a consistent ID for a given stick.

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

Edited November 27, 2013 by evilC

[Nuke]

a lot of games seem to enumerate joysticks based on their index and use that when they are being bound, or when binds are saved or loaded from a file. i kinda think this is asinine, and just asking for trouble, especially considering that windows no longer lets you change the joystick id on a stick by stick basis (you used to be able to do this, idk why they took it out, you can now only set which stick is the first). what i do in my game engine is get the name string from the joystick, and bind it by name in addition to the index. so even if you plug your joysticks in a different order, you still can retrieve information on the correct joystick even if their indices are scrambled. if for some reason you have two of the same stick, then then index is used to determine which is which.

[evilC]

The app I linked will let you change IDs around, so no biggie losing it under windows.

Also, I think that it is the game engines that are causing the problem.

My guess as to what is happening is this:

Windows is passing an object of available game controllers:

{

id:1 {name: "Some Joystick", {...}},

id:2 {name: "", {(Disconnected controller, null object)}},

id:3 {name: "Some Joystick", {...}}

}

The engine parses this - game stick 1 becomes stick ID 1...

Stick ID 2 is disconnected, so the game skips it

Stick ID 3 is connected, so the game refers to it as stick 2

Then when it writes the settings file, it saves ID 2, Axis 1

But when the settings file is read, it uses the ID of 2 as a *windows* stick ID, which it is not.

As I said, to my knowledge, windows does not change the ID of a stick, ever.

If you plug in your 5th stick, it will become stick 5, and even if you unplug all other sticks, windows will refer to it as stick ID 5.

So if a game does not behave in this way, it is a fault of the game (or the engine it uses).

Some games manage it fine, so clearly it is possible.

Edited November 27, 2013 by evilC

[Nuke]

sdl has a lot of good joystick calls. for example its possible to retrieve a GUID for a joystick, which is guaranteed to be unique (its an ms thing so im sure direct input has a similar function). so that might be better than the name and number approach ive mentioned before. unfortunately as much as ive tried, i havent been able to get sdl to work in lua (that doesnt break luagl), and the approach im using requires using a 3rd party dll for another game engine, and hacking into it with alien, and it doesn't have a getGuid function. maybe i should work on my dilapidated c++ based game engine instead of the more developed lua version

[Soda Popinski]

I'm not having much luck with this. The physical joystick keeps getting chosen. Any suggestions on editing the settings file?

I tried to follow the directions on the Read Me file to handle the issue, but I'm not clear on the instructions.

Edited November 28, 2013 by Soda Popinski

[evilC]

I'm not having much luck with this. The physical joystick keeps getting chosen. Any suggestions on editing the settings file?

I tried to follow the directions on the Read Me file to handle the issue, but I'm not clear on the instructions.

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?