Universal Control Remapper (UCR) - v0.1.22 28th Oct 2018

[evilC]

Theoretically that should be possible, haven't tried it. Seems pointless though?
If it is on the same stick, then UCR would be the only thing feeding that stick, so why would you output two axes to vJoy, then use those as input to a merge onto a third axis?
Or is there a use-case there that I haven't thought of?

I am planning on working on UCR this weekend, should hopefully have a new build out by Sunday. The next release will feature a plugin that lets you bind a button to change to a specific profile. It will probably only be a basic implementation though, just an editbox to type in the name of the profile, and an inputbutton binder.
This is primarily aimed at the disabled community, but would probably be useful to many people - until I decide on a way to properly implement shift states for buttons, it would serve as a an interim solution. I guess if I made a version that switched to a profile when you pressed a button, and switched back to the original profile when you released, that would make a "shift" mode of sorts.

[shaul]

In the model airlane world, you sometimes have all types of channel mixing. So one way to achieve this is by feeding linear data to a channel then mix it with another.

Question: what are "shift states"?

Blasphemy: I get the feeling that AHK is getting old. It does not support more than 32 buttons, a single hat switch and only 6 (?) axes. This is because it is based on the legacy WinMM technology that is now emulated on top of directx. Why not work directly with directx? This is what I did with my joymonitor.

[evilC]

By shift states, I mean allowing a user to set up UCR such that button 1 normally does one thing, but if you hold button 8, button 1 does something else.
I want to look into allowing you to do this with axes also, eg let you change sensitivity of an axis while you hold a button, or make it so that when using a stick for steering, while you hold a certain button, the stick instead adjusts the trim, and if you hold the button for a long time, it resets the trim.

RE: WinMM - I know. I said the same to the developer of AHK, but he said he had no plans to replace WinMM
I have a partial, unfinished AHK-based solution that used RawInput, but it seems to me to be the kind of thing that should be done in C.
I am now working with HotkeyIt, the author of the AHK_H fork (Which UCR uses), and he has expressed an interest in implementing a better solution in the C++ source code of that version of AHK, so if you would be interested in helping us do that, then that would be awesome - we haven't got a clue about DirectX, and are also pretty much "stabbing in the dark" with HID and RawInput.
Another solution, as I previously mentioned, would be to write a sort of vJoy DLL in reverse.
The DLL would handle all the C code to read the stick from DirectX, and it exposes functions like vJoy does, but in reverse - eg GetAxis() to read the state of a stick via DirectX or whatever.
Hell, maybe even build it into vJoy. the vJoy DLL can be called from many languages, and in many of them it wouldn't be easy to get input from a physical stick, so it would make sense to make vJoy able to get the input from physical sticks for you.
If it were part of vJoy, you could possibly even write one of these "channel mix" feeders you mentioned using a a powershell script

[shaul]

For the record, I know nothing about AHK. I assume it gives you easy interface to Human Interface Devices such as Joysticks and also to Mice and KBs. Correct?
Also, I can write in C and C++. I don't know higher languages.

As for DI (DirectInput):
It gives you a set of tools to Enumerate devices, Acquire devices and get data from them. It also supports FFB but let's leave it for now.
Most of the code is boilerplate type. The enumeration and acquisition take some writing but you can copy-paste this part from other projects (e.g. vJoyMonitor). Enumeration of capabilities for a specific device is also a tedious work but quite straightforward.
What is left is getting the position data from the acquired device which is quite simple.

One part that complicates the whole thing is the detection of changes in the system. I assume that AHK does not respond to the insertion of a new device or to the removal of a device.
If we want to detect changes, especially when our device is removed, the code is complicated by the need to create a target to system messages (Usually a hidden window) and reacting correctly to these changes.
Also, we would probably want to keep a container with all available devices along with their capabilities.
I did most of the work in vJoyMonitor but restricted it to vJoy devices.

So if you are willing to settle for a software that enumerates the system once and ignores changes - writing the platform should not be too difficult. We can write it in C++ and export the API through a C DLL.
If you want the full solution, including detection of changes, we need to expand vJoyMonitor to support any type of HID plus KB and mice. This is a big project but it is probably the correct approach. Here too - write it in C++ and export the API through a C DLL.

[evilC]

AHK provides commands to have events fired when specified input occurs.
This includes, but is not limited to:
Keyboard and Mouse buttons, with blocking (ie it can use hooks to hide the input from other applications), and it supports combinations - in general any modifiers plus one "normal" button (eg CTRL+ALT+Middle Mouse). It is quite sophisticated in terms of keyboard + mouse input.
Joystick buttons (First 32 only), "up" event for buttons is inaccurate (always fires straight after down), but you can emulate the up event through polling the state of the button in a loop.
Joystick Axes (First 6 only) - no event for these, you have to poll state in a loop.
Joystick POV Hat (First 1 only) - same as axes.
AHK does not support "hotkeys" for joystick buttons in combination with keyboard/mouse buttons (eg no CTRL+Joy button 1) nor does it support hotkeys of more than one joystick button (eg no "Joystick Buttons 1 + 2").

So... the overall strategy I am going for is this:
UCR uses worker threads to emulate events for AHK input types that lack event based input detection (Joystick axes, hats, up events for buttons).
The "Shift States" system (as previously discussed) will solve the issue of not being able to do keyboard + joystick key combinations, or multiple joystick button combinations.

Regarding languages: AHK_H and AHK_L are both written in C++, so that would be the language of choice.

Regarding re-enumerating devices: Ultimately, I would love to have hot-swap, but would settle for no detection of changes.

I think the ideal solution would be to replace AHK_H's WinMM joystick input with DirectX. HotkeyIt has expressed an interest in solving a lot of the above issues by altering the source code of AHK_H, and I think that is a good route to go. I see little point in doing keyboard / mouse button support in DirectX though, as (AFAIK) you cannot block keyboard/mouse (stop other apps from seeing the input) with DirectX. If i were going to replace AHK's keyboard/mouse support, it would probably have to be hooks. We experimented with hooks using SetWindowsHookEx calls from AHK scripts, but it made debugging impossible, as all input locked up when you debugged your AHK script. I did some research and I think it is possible to avoid this (By offloading the hook code into a DLL or something?) but we couldn't work it out and moved on. Debugging issues aside, it is not trivial to implement a hotkey detection system for multiple keys, with blocking capabilities. Seeing as AHK already implements this, I see no reason to try to replace it while there are bigger problems to solve.

TL;DR: What would be absolutely awesome would be for you to help HotkeyIt and I implement DirectX joystick support into AHK_H's C++ source code. Hell, I see no reason to stop there. Why not build support for vJoy into AHK? As in full support. Add, configure, acquire vJoy sticks all through AHK commands.
Surely your Radio Controlled guys would love that? If you could write a vJoy feeder using a simple script with no libraries required, all native commands.
Read input from any source (keyboard, mouse, joystick) and mix it all as required to drive your vJoy output. You could easily implement niceties such as mouse aiming for the turret of some RC vehicle

[evilC]

New version released.

Just unzip the zip to your UCR folder and overwrite to upgrade.

0.0.4 - 24th Jan 2016
+ Profile Switcher plugin added to allow changing profile using a hotkey.
This can be placed in the global profile to always be in effect.
+ Basic Joystick Axis to Button remapper plugin added.
+ Settings file is now written after one second's inactivity, rather than on every change.
+ Fix for Gui getting "Lost" when you minimized it.
If this happened to you, edit your INI file and reset the x and y coordinates at the top to 0.
+ vJoy API calls optimized.
= State property added to Output GuiControls, to match input GuiControls.
= AHK_H version updated
= Objects which are used in multiple threads are shared via COM using new AHK_H function ObjShare().

[OneSwitch3000]

Loving the power! It's not hard to imagine how hugely enabling this is going to be. Brilliant work so far, Clive!

Some bugs to hopefully iron out when you have time...

1. Button to Button Binding crash in Global mode > Plugin "Remapper (Button to Button). If ignore error message, seems to work fine. Sometimes it works fine anyway.

2. Incorrect operation in Remapper Axis to Button plugin. I tried mapping a physical left-stick, to act as a vJoy hat switch (i.e. D-pad), and found you cannot repeat an action, until you push in the opposite direction to reset it. Tried this in Global.

3. Problem with flickering joystick control with Plugin "Remapper "Mouse Axis To Joystick Axis". In Absolute mode when moving the stick you get a high-speed flickering effect between the new position and 0 (the central resting point when you are normally doing nothing). With the old MouseToJoy system, you introduced some kind of filtering to stop the effect flickering if you recall and cracked it. I'm guessing that's needed again. I'm using the standard settings, but changing them made no change to the flickering.

4. One Switch Timer to flesh out at a later date I guess. All I get is a bleep.

5. Not necessarily a bug, but it would be good to improve the Profile Switcher. Presently it will jam some/all controls on, if you switch the profile whilst some controls are held. Also it would be good if you could attach a sound sample and/or image when you change profile.

6. The left-click is not recognised by the On Screen Keyboard, nor system event windows. This is the same problem that JoyToKey has. Wonder if there's a way around it.

By the way, it works great with JoyToKey. I just mapped a single button to switch the profiles between left-stick and right-stick on a single joystick, with the buttons and triggers globally mapped 1:1 across and it worked brilliantly. Thank you! Can't wait to get the Axis to Button plugin working correctly when you get a chance.

Genius work.

Barrie

[evilC]

1. Yep, repro'd this last night, and it worries me

2. Can you repro this with regular keyboard keys or is this unique to hats?
The plugin is designed such that it does not repeat keys - eg if you hold up on the stick, it holds W while up is held. It only holds W once - W will not "repeat". Repeating of the keys is something that would be implemented in a more advanced version of the plugin - one that could emulate analog input by "strobing" keys at different rates.

3. Part of this would be due to the way that mouse to joy has to work, it just sounds like I set the "Center Timeout" too low.
You could try editing this line of the code in Threads\ProfileInputThread.ahk and change the value 10 to something like 100. At some point I plan to make this configurable by the end-user.

4. Yeah, I need to do a bunch of work in this area.

5. This is a big worry of mine. I have not currently addressed this issue, and it is something I really need to look at. I think maybe all I need to do is whenever a profile deactivates, it calls deactivate on each of it's plugins, then make it so when a plugin gets deactivated, it releases any keys it has held.

[OneSwitch3000]

2. I'm having the issue right now, with the left-thumb-stick mapping it to Buttons 11-14 (up, right, down, left). It still only works consistently when you waggle! If I pressed UP repeatedly, only the first press is recognised, until I waggle.

3. Will try that to fix the flickering. [Yep - 100 fixed it very nicely indeed - thanks!]

5. It actually works great by accident in Call of Duty. Maybe keep it in as an option. I'll try to knock up a quick video of it. I have two-modes set-up for instance for a single-stick player. One mode acts the left-stick (move) and one the right-stick (look-around). If I hold-forward and change profile at the same time, it latches walking forward. I can then creep around/run around whilst looking with the stick to look/steer in Call of Duty. Press the mode shift-button and it cancels it. I really like it!! But yes, it could be a confusing thing in some circumstances.


From my side point 2. is the main stumbling block, and the lack of a time-out mode. Really liking it.

[evilC]

New version released

0.0.5 - 25th Jan 2016
= On change of profile, all held buttons are released.
= AxisToButton plugins now correctly manipulate the outputs.
= Multiple AxisToButton plugins now work together.

[OneSwitch3000]

Nice. That time-out button pulse would be really appreciated for when you have time (will trigger a profile shift in JoyToKey to jump out of a game-play controls mode into a menu navigation controls mode). I'm supporting a couple of players who can manage a single stick and 2-3 buttons maximum. Thanks again (and to Shaul, AHK and the guy helping you with the deep level AHK stuff).

[danrevella]

Hi!!
first of all, please excuse if i have post this before in the wrong section...
many thanks for your excellent work.
I have solved the problem by reinstalling virtualjoy driver......

Is it possible visualize the % value as in UJR:
Invert Deadzone Sensivity PHYSICAL VIRTUAL



Many thanks
danrevella

[evilC]

Hi!!
first of all, please excuse if i have post this before in the wrong section...
many thanks for your excellent work.
I have solved the problem by reinstalling virtualjoy driver......

Is it possible visualize the % value as in UJR:
Invert Deadzone Sensivity PHYSICAL VIRTUAL

Many thanks
danrevella

This could be done by updating the plugin to output those values. I will probably get around to it at some point.

New Feature
I just updated a commit of UCR.ahk that some people may find useful - ButtonToButton plugins work better when the output is mapped to a vJoy hat - you can now hit diagonals on the hat. Replace your UCR.ahk with the one from here.

[Brian]

I am trying to achieve this..i have xbox controller plugged in but i want to use mouse right and left click as controllers Rb and Lb..i tried assigning button to button function but it did not work in the game..

[evilC]

Brian, is the game bound to the xbox controller or to the virtual vJoy stick?
It needs to be bound to the vJoy stick, as UCR cannot alter the way the game sees your physical xbox controller.

[evilC]

New version released.

0.0.6 - 21st Feb 2016
= Fixed errors while switching profile at the same time as input was happening.
The ProfileSwitcher plugin should no longer crash UCR.

[evilC]

Just a quick update to let people know what is going on...

Over the last couple of weeks I have been doing research & development for a new feature - "Child Profiles". This is now approaching a usable state, and I hope to make a release featuring it by the end of this weekend. If you wish to check it out beforehand, you can download the Child Profiles branch from GitHub.

Child Profiles will mean that each profile can have a parent profile - instead of a "flat" list of profiles, they are now organized in a tree.

For your average, able-bodied user of UCR, Child Profiles will initially probably not bring much benefit apart from allowing you to better organize profiles - eg you could have a profile called "Games" that does not actually hold any plugins, but has child profiles for each of the games you play. Further down the line, I intend on looking into allowing child profiles to "inherit" the plugins from it's parent, such that if the profile "Games >> Game A >> Standard Controls" is active, the plugins in the "Game A" profile are also active.
This would allow a way to implement "Shift States". For example, if you wanted to set up Game A such that a joystick is mapped to a vJoy stick, and button 1 has two different behaviors - you could have two child profiles for Game A: "Normal" and "Shifted". The joystick axis mapping would be defined in the parent Game A profile, and would always be active, and while in "normal" (unshifted) mode, the "Normal" child profile would be active, mapping Button 1 to vJoy button 5, but in "Shifted" mode, Button 1 maps to button 5 on the vJoy stick. Button 2 could be used as the "Shift" button to switch between "Normal" and "Shifted" state.

So to achieve this, any input that does not change behavior while shift mode is active would be defined in the parent "Game A" profile, and the inputs that change behavior depending on shift state would be defined in the appropriate child profile. So when you hit button 2, the "Normal" child profile is deactivated and the "Shifted" child profile is activated - then, when you release button 2, the "Shifted" child profile deactivates and the "Normal" child profile re-activates.


For the disabled (Especially One Switch users ) community, Child Profiles will be utterly invaluable.
What we need for these users is some way for a profile to "Time Out" (No inputs in that profile were manipulated in the last x seconds) and change profile to the parent profile.
If in a profile that has child profiles, a menu can be displayed that cycles through the list of child profiles and allows a press of the button to change to that profile.
So UCR may be configured with a "Games" profile, which contains profiles "Game A" and "Game B". Game A has two child profiles, "Forward" and "Back" which maps the one button the user can use to either forward or back in a game (W or S). The user starts off in the "Games" profile, and a menu appears on-screen that cycles between "Game A" and "Game B". If the user hits the button when Game A is highlighted, UCR switches to the Game A profile, and then changes the on-screen menu to start cycling between "Forward" and "Back". If the user hits the button while "Forward" is selected, then UCR switches to the "Forward" child profile and the one button now maps to W so the user can use it to move forwards. If the user does not hit the one button for say 5 seconds, the "Forward" profile times out and returns to the "Game A" profile, and UCR starts cycling between "Forward" and "Back" again.


The Child Profiles update will also bring the ability to rename profiles, as well as re-order them, all through an intuitive drag-and-drop interface (You can drag profiles from one place in the tree to another).

Finally, it also features an enhanced "Profile Switcher" plugin that no longer uses just a text box into which you type the name of a profile. Instead you now click a button and it pops up the profile tree for you to select the profile to switch to when you hit the button. Furthermore, if you alter the structure or naming of the profile tree, any profile switcher plugins that have already been configured will auto-update to reflect the new structure / name of the linked profile. In other words, you can now set up a profile switcher plugin and not have to worry about updating it if you change the location or name of a profile that it points to.

These changes mean that the format of the settings file (UCR.ini) has changed, but I have written an import system such that your old config will automatically be updated to the new format.

At the moment, the profile selection Gui Element is a free-floating window that does not remember size or position, but I am looking into various possibilities (I think I will probably go with a "docked" window that sticks to the side of the main UCR window, so the profile tree can be always visible), but I don't think this will make it into the next release, I think it is probably best to collect feedback as to how people would like it to work.

[evilC]

New version released, 0.0.7

This release implements the "Child Profiles" system I was talking about in my previous post.
I have so far implemented the switch to a tree-based structure, moving / renaming / deleting items in the tree and a new profile picker for the profile switcher plugin. Existing profile switcher plugin mappings will be broken and you will need to re-select the profile that it points to.

It's all still a little rough-and-ready, but I just need to get a version out there to make sure I haven't radically broken anything, before proceeding with the more interesting features that will be based off this work.

So please, give it a try, see if you can break it, and please, as the release notes say, make a copy of your UCR.ini settings file before you run the new version.

Key:
! : Warning
* : Comment
= : Change / Fix
+ : Added feature

Code: Select all

0.0.7 - 13th Mar 2016
! Warning! Settings version has changed.
  BACK UP your INI file before using it with this version, if you value it.
+ Profiles are now organized in a Tree instead of a flat list.
+ Added a "Profile Toolbox" to allow navigation of the profile tree.
  Add / Add Child / Delete / Rename of profiles are all functional.
  Dragging and dropping of items in the Profile Tree to change parenting or order is supported.
+ Profile Switcher plugin now has a "picker" that can be used to choose a profile from the tree.
  If you later change the structure of the tree, it will still point to the same profile.
! Both the "Profile Toolbox" and the "Profile Picker" are experimental / placeholder.
  The Profile Picker does not close unless you pick an item or close it.
  Neither remember position or size.
= Multiple AxisMerge plugins can now be used together.

[nespcbuild]

Hi evilC. This is an awesome app! I'm having a couple of strange issues with it though. I have two identical controllers and I've mapped them to the same vjoy device. On either controller, If I hold a button, then hold down another button before releasing the first button, the first button won't release on the vjoy device until I let go of the second button. I can repeat this all the way up to 9 buttons. Once I get up to the 10th button, no input is detected at all on the vjoy device until I release the last button. I don't know if it's related but my vjoy device is configured for 10 buttons. The other issue I have is that when I am holding a button down, the hat input often doesn't work on the vjoy device until I release the button. This doesn't happen all of the time, but it happens more often than not. Any idea why this is happening? Is there a setting that I can change to resolve this?

[nespcbuild]

I did a bit more checking and found that this still occurs if I only have one controller mapped to the vjoy device and it doesn't occur when I use UJR. It's only happening in UCR.