Feature request: axis trim

[PhoenixBvo]

Hi evilC,

First off, thanks for this macro. It's brilliant! I have been looking for something to combine joystick axes with for some time and yours is a really nice solution.

I'd like to request a third merge mode where the second axis is used to trim the first one. Meaning it shifts the center while keeping the range intact. This would be very useful for flight sims. (I know of a lot of people over at http://forums.eagle.ru/ who'd very much like to have a feature like that!)

I'd program it myself (basically adding a merge == 3 case to the routine on line 477 and following), but AHK gives me a syntax error when I try to run ujr.ahk:

"Error at line 39.

Line Text: {name Error: The leftmost character above is illegal in an expression.

The program will now exit."

I have added ADHDLib.ahk to the same folder and activated the corresp. line at the end of the ujr script:

Include ADHDLib.ahk

I also installed: AutoHotkey version 1.0.48.05 vJoy version 2.0.4

Your executable runs fine btw. I'd be cool if you could give me a pointer to solve this problem. Of course I'd be happy with the feature as well :).

[PhoenixBvo]

Nevermind my previous message, I forked the code and added the feature myself. It works perfectly. Check it out, if you like.

Also, I found out that http://www.autohotkey.com/ does not contain the current version of AHK and you need to go to http://ahkscript.org/ to get it. With AHK v1.1.15.04 installed the script runs fine.

[evilC]

Hi, Hmm, I have seen that error before, trying to think what it is... I think it is maybe the wrong version of AHK? You should be using the download from ahkscript.org, not the one from autohotkey.com My AHK version is 1.1.15.00

It sounds entirely possible to do what you want to do, I guess what you mean is a "relative" trim - ie instead of the trim axis sitting at the spot it would do to set the trim, you use the axis to move the trim around. The disadvantage of that of course is that you never know how much trim is being applied, you could only guess. You could have a button to reset it, but if you are going to use a button also, you may as well do an "absolute" trim - you move the trim axis to a certain deflection, then hit a button to set trim to that amount.

I am not really actively developing UJR at the moment, I am currently trying to get a new system together for the macros, to save having to have multiple macros for different tasks. The replacement I envisage would support "plugins" - so to recreate the functionality of UJR, you could add 8 axis plugins and 32 button plugins - plus special cases like what you describe could be handled by a custom plugin. At the moment though, it is very much at the proof-of-concept stage - I am working on making the UI that allows plugin windows to be added / removed etc. You can see a video here: http://www.screencast-o-matic.com/watch/c2jlbKnsuM

If you clarify exactly how you think the trim system should work, then I could probably further assist in modifying UJR in this way. Once you have a plan fleshed out, I would be happy to have a look at the code and see how it could be shoe-horned in.

Regards

Clive

On Sat, Aug 23, 2014 at 12:48 PM, PhoenixBvo notifications@github.com wrote:

Hi evilC,

First off, thanks for this macro. It's brilliant! I have been looking for something to combine joystick axes with for some time and yours is a really nice solution.

I'd like to request a third merge mode where the second axis is used to trim the first one. Meaning it shifts the center while keeping the range intact. This would be very useful for flight sims. (I know of a lot of people over at http://forums.eagle.ru/ who'd very much like to have a feature like that!)

I'd program it myself (basically adding a merge == 3 case to the routine on line 477 and following), but AHK gives me a syntax error when I try to run ujr.ahk:

"Error at line 39.

Line Text: {name Error: The leftmost character above is illegal in an expression.

The program will now exit."

I have added ADHDLib.ahk to the same folder and activated the corresp. line at the end of the ujr script:

Include ADHDLib.ahk

I also installed: AutoHotkey version 1.0.48.05 vJoy version 2.0.4

Your executable runs fine btw. I'd be cool if you could give me a pointer to solve this problem. Of course I'd be happy with the feature as well :).

— Reply to this email directly or view it on GitHub https://github.com/evilC/AHK-Universal-Joystick-Remapper/issues/3.

[PhoenixBvo]

Hi Clive,

thank you for your prompt and elaborate answer. That plugin system sounds interesting. Would it mean one could have a more customisable and lean solution for control device mapping?

I think you might have missed my previous comment :-) I have actually found the problem to be the AHK version, as you suggested. And I took the liberty to implement the trim feature in a fork of your source code: https://github.com/PhoenixBvo/AHK-Universal-Joystick-Remapper

The second axis shifts the center of the first axis around, but it's done using a quadratic function, so the extremes of the first axis remain clamped at their original values and so the range of motion is preserved. I added a little Matlab function (test_trim.m) demonstrating the effect, if you happen to have acces to Matlab.

My application is flight simulation, where for fixed wing aircraft, this is the preferred method of trimming. I had an aircraft without rudder trim, so the first axis is my rudder axis and the second is the slider axis on my Thrustmaster Warthog throttle. I can see its position, and so I know how much trim is being applied to the rudder. Your suggestion of absolute trim is the standard for helos, where the stick has a trim button which acts to neutralise all forces on the current stick position, thus making it the new neutral position. That would in fact be another helpful feature for UJR.

So, thanks for your help and please tell me what you think of my addition to your code :-)

Best regards, Mark

[evilC]

Hi Mark, First off - congrats on being the first person to suggest an improvement to UJR who could actually code it himself - Kudos!

I also think I was talking rubbish when I said it would be best off in the "special ops" dropdown - of course it makes sense to do it the way you have done because you can easily select which axis controls the trim for the primary axis.

With regards to the absolute trim - I think that would involve a bunch more work (there is no space in the UI for a dropdown for each button for a start) and maybe best left as a feature for the new version.

With regards to the new app I am developing (Codename: UCR "Universal Control Remapper"), yes it is intended as a generic one-size-fits-all solution for all your joystick / keyboard / mouse remapping needs. I intend to ship it with basic plugins (Digital -> Digital ie key / button remaps, Digital <--> Analog ie key to axis and vice versa, rapid fire macros, shift state support etc) The project page for that is here: https://github.com/evilC/UCR but be sure to pay attention to the readme - you need a custom AHK exe from the link in the readme. As I said though, at the moment it is purely a proof-of-concept for the UI. UCR is intended to be totally class-based code, so all people would need to do to write their own plugins would be to extend one of the base classes and tweak it as desired.

I had a play with your version, and it seems great - however the only minor niggle is that the "State" slider and the "Virtual" readout for the primary axis does not reflect the trimmed values, but that is probably a matter of preference and certainly fixable at some point in the future. If you would like to submit a pull request, I would be happy to merge these changes into UJR as they stand (With credit of course!)

Also, maths is not my strongest suit - the maths I used for stuff like the sensitivity curves was a product of a friend of mine helping me, but he is not into games and knows nothing of joysticks etc so it took a while to explain to him what was needed. It seems like you know your stuff maths-wise, so if I could maybe draw upon your expertise when designing these parts of UCR, that would be really appreciated! I think UJR is maybe a little sluggish in that regard and refinement of the maths would possibly help there...

Regards

Clive

On Sun, Aug 24, 2014 at 10:45 AM, PhoenixBvo notifications@github.com wrote:

Reopened #3 https://github.com/evilC/AHK-Universal-Joystick-Remapper/issues/3.

— Reply to this email directly or view it on GitHub https://github.com/evilC/AHK-Universal-Joystick-Remapper/issues/3#event-156484781 .

[PhoenixBvo]

I have just created the pull request.

We can indeed change the state slider for axis 1 to reflect the trimmed values, that would help to understand the effect.

I'd be happy to assist with axis curve equations and such for UCR. Let me know when you have a specific question. (I'll add the UCR project to my watch list, so I can receive issues there). Also, you might want to try out Octave (http://www.gnu.org/software/octave/) which is in essence an open-source Matlab alternative. You can quickly prototype and visualize algorithms e.g. for curves there, as I did in test_trim.m.

Regards

Mark

[evilC]

Code merged into master branch, version 6.5 has been released. Thank you!

On Mon, Aug 25, 2014 at 9:12 AM, PhoenixBvo notifications@github.com wrote:

I have just created the pull request.

We can indeed change the state slider for axis 1 to reflect the trimmed values, that would help to understand the effect.

I'd be happy to assist with axis curve equations and such for UCR. Let me know when you have a specific question. (I'll add the UCR project to my watch list, so I can receive issues there). Also, you might want to try out Octave (http://www.gnu.org/software/octave/) which is in essence an open-source Matlab alternative. You can quickly prototype and visualize algorithms e.g. for curves there, as I did in test_trim.m.

Regards

Mark

— Reply to this email directly or view it on GitHub https://github.com/evilC/AHK-Universal-Joystick-Remapper/issues/3#issuecomment-53238331 .