Merge Axis Rework

[nlvw]

First off thank you for the hard work, this software you have created is really great! The biggest issue i've come across is problems with merge axis. The first issue I've had has been with response curves and dead zones with merged axis. In this case unlike elsewhere response curves assigned to the physical devices axis do not get applied. Also the vJoy response curves do not get applied but that is covered in a different issue (#67) here on github. The second issue is merge axis' settings seem to reset to different devices and axi when loading gremlin. The last issue i've had with this and is the topic for this rework is that merge axis is a separate popup interface instead of an action applied to the physical devices axis.

So here is a bad paint mockup of what i'm proposing:

Basically get rid of the merge axis popup and add it as an action. This brings merge axis back into the established interface for Input to Action mapping. This also allows for response curves set for the physical device input to be respected.

[WhiteMagic]

Yeah the merge axis is a bit of a pain as it's the only action so far that uses two uses two inputs. The separate dialog at the time was the simplest approach I didn't hate essentially. There are mainly two reasons I'd rather avoid placing the merge action on the physical devices.

1. you can't, at a glance, see how the entire action is configured
2. it gives the impression that a response curve should work but at least currently it never would and if it was made to work (transfer over to the vjoy side) then it only would affect part of the merged axis

I can think of a few alternatives / modifications that might make this less of an issue. One is to add the merge action into the vJoy device itself, where it then is clear what axis it is mapped to and the response curve clearly is for the entire axis rather then just one half of it. The other option is to have a "shadow" view of the second part of the merge action being shown so at least the combination of axes used is clear. However, that might cause some headaches as Gremlin doesn't have a concept of actions that are split over multiple inputs.

So overall I personally probably would lean towards adding the merge action to the vjoy device as to me it's cleaner from an information presentation point of view and definitely is less headaches to implement. Though I'd be happy to hear other thoughts on this.

[nlvw]

Ah, I see that we are looking at the concept of split axis a little bit differently. Let me see if I can adequately express what I am thinking. Consider that as it is currently you can map 2 different axis to both output to the same vjoy axis. Each of those 2 different physical axis can have their own curves and dead zones. For my example I have both the rudder push axis and joysticks twist axis outputting to the same vjoy axis. The curves and dead zones are applied to the physical axis's input and then outputted to the vjoy axis. Doing a half axis mapping is a similar concepts and applying curves/deadzones should be done in the same way. The values that gremlin outputs to the vjoy device should be numbers after all actions, curves, and dead zones have been aggregated. It already does this for everything but merge axis, which is why it seems inconsistent.

[WhiteMagic]

I'll have to ponder this whole thing a bit. Both merge axis and split axis actions are confusing in their usage as they are split between multiple tabs / windows which is caused by them being different in certain aspects from the other actions.

[nlvw]

would it be possible instead to add a new remap? So something like a half axis remap and then allow the response_curve to add dead zones/curves to that half axis input value. You can already map two or more inputs to the same vjoy axis. This would just be an extension of that concept.

EX: T16000M Axis 3 (Twist) is mapped to vjoy Z-axis T16000M Axis 3 response curve for input from this device and axis T-Rudder Axis 1 (Right Toe-Break) is mapped to vjoy Z-axis-UpperBound (or Z-axis Positive Half) T-Rudder Axis 1 response curve for input from this device and axis

Then you just need some backend logic for what actually gets sent to vjoy Z-axis based on the input and order of that input from the two different devices/axis.

This is basically so I can get my pedals toe-brakes to map to the upper and lower bounds of a single axis and be able to assign dead-zones/curves. Also without affecting the curves assigned to the joystick axis mapped to the same vjoy axis.