Hi All,
Thanks for your responses so far, I should introduce myself as I am the person who has initiated all this. My name is Clive, I wrote a (free) piece of software called UJR (Universal Joystick Remapper), which can read physical stick input from one or more sticks and route it, with modifications (ie axis invert, deadzone etc) to Shaul’s vJoy driver.
This became rather popular, and users of my software funded the initial code signing cert for Shaul’s vJoy driver, and now Shaul has agreed to help me out in writing a successor (Working title: “UCR - Universal Control Remapper”)
Shaul does not really know much about the workings of my code, so I thought it best (as tersely as possible) to lay out objectives, constraints, etc so that we can, if possible, find the best solution.
UJR and it’s successor are written in AutoHotkey.
Ostensibly a scripting language, this is actually starting to basically become a wrapper for windows functionality - especially with the advent of AHK v2.
I am not a windows coder. I use a lot of windows API calls etc via AHK, but I know next to nothing about the inner workings of windows and drivers.
Parts of the solution could be written in C, and AHK could be extended to do things it currently cannot (We have a developer of an AHK fork on board) - so there are plenty of options.
I have already implemented RawInput (And HIDP_ “Preparsed Data”) DLL calls to read stick states in AHK (Handling of WM_INPUT messages), so any solution that utilizes that would be great.
OK, so on to the actual reason for the posting.
Lets say that a user has a super-duper top-end flightstick from SomeCo
This come as two USB devices - the stick and the throttle.
Now please excuse me, I do not happen to own a working version of one of these super-expensive sticks, but from what I understand they work like this:
If you open the box and plug the devices in, you see two entries in the Windows’ Game Controllers dialog (WGC).
The devices are HID devices and without drivers will work in a default configuration.
If you wish to configure it, you must install SomeCo’s software that came with the sticks.
Now I guess this is a driver, but there is a UI part as well.
This config software will let you remap buttons to keys, or, most importantly, merge the stick and the throttle onto one virtual device.
This is important, because some games only allow input from one stick at a time, so if you wish to use stick and throttle, you are outta luck.
In this instance, the physical sticks will either disappear from WGC, or their states will never change - so if you go into a game’s bind routine and try to bind an input, the game will see the combined virtual controller move, not the individual controller.
Now for example, I know at one point the software that came with the $200+ Saitek Rhino stick did not support combining of both the sticks onto one virtual stick, so owners of that stick had pretty much no other solution than UJR to let them play certain games with their stick.
Now we come to the main reason for all these questions.
In UJR, because I could not hide the physical (individual) sticks from games, or stop them from updating, when using the bind routines in game option menus, you invariably bind the input to the physical stick, not the virtual stick. I had to write a system called “Quickbind” that lets you move the virtual stick without moving the physical stick.
So… this got me thinking…
UCR would be able to do everything that the manufacturer’s software could do and then some - so why not try to replace it?
In fact, it would be worth mentioning that the scope of UCR would potentially include remapping for any HID device - ie why stop at replacing the software that comes with joysticks? Why not replace the software that comes with any keyboard / mouse / stick, or even provide software if your device did not come with any.
With regards to “remapping” keyboard or mouse, I possibly do not need drivers etc to do that - I have also implemented hooks via SetWindowsHookEx DLL calls which I think can take care of most keyboards / mice etc. I dunno - it’s probably best to limit discussions for now to the subject of joysticks, as “blocking” physical sticks is the most asked-for feature from users of UJR.
In order to “block” the physical stick input, there appear to be two ways to go:
For both methods, my code would always need to be able to read the actual state of the physical sticks (Ideally via my existing WM_INPUT code).
- Stop games from seeing the physical sticks move. Games should then always see the virtual sticks move. This may not work though as some games may decide to not even scan all sticks. However, virtual sticks should always be the “preferred device”, so this may be unlikely.
- Hide the sticks entirely (don’t appear to exist) from games, just leave the virtual sticks visible.
Apologies for the wall-o-text on a first post, hopefully it makes what we are trying to do pretty clear.