-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Joystick Gremlin sits between our physical sticks and the program of interest (the sim). As long as we provide we provide a means to activate the bound vjoy axes and buttons, the sim does not care if we exchange one set of physical inputs for another. That lets us retain complete control over how we map from physical inputs to virtual ones, which is the purpose of Joystick Gremlin in the first place.
However, this requires us to create two mappings: (1) between the sim and our virtual device(s) and (2) from our physical devices to our virtual ones. Up to the current (R13) release, Joystick Gremlin only provides a means to track the mapping from physical devices to virtual ones. The user must rely on descriptions or other manual means to track the intended mapping from virtual devices to the sim. Below, we provide an example scenario where this mapping process can cause confusion.
By introducing bindings to Joystick Gremlin, we can include the mapping from virtual devices to sim functions within Gremlin itself. The user may even choose to include all possible sim functions in Gremlin. This allows the user to set the intermediate virtual-to-sim mappings once, then map directly from physical inputs (including keyboard keys!) to sim functions. Additionally, since Gremlin is aware of bindings and their virtual outputs, we can also use Gremlin to modify sim configuration files directly. The new mapping process is described in more detail here, with additional notes on binding uniqueness here.
In the R13 release, each Remap action in Joystick Gremlin lets us map one physical axis/button to one virtual axis/button. Naturally, we might start with a 1:1 mapping - all physical inputs map to individual virtual outputs. Then, we activate the profile, load the sim's mapping wizard, and remap each button in the sim to the appropriate virtual output by pressing the desired physical input. This happily lets us adjust dead zones and sensitivities in Joystick Gremlin for that physical device Without having to re-jigger things for each and every sim. Only the in-sim bindings need to change.
Now, say we have a sim which supports more functions than we have physical buttons for. We could set shift bindings and create conditional remaps on certain buttons: "when SHIFT is released, map Button A to Virtual Button 1; when SHIFT is held, map Button A to Virtual Button 2". Then, just jump back in our sim and map the new virtual keys by holding SHIFT and pressing the same buttons. But wait, we've accidentally mapped over an existing virtual button! So now we go back into Joystick Gremlin, adjust the offending button and try again. But how can we be sure we're not stepping on another button this time? Joystick Gremlin has no knowledge of bound and unbound virtual buttons - we have the keep track of it ourselves. Depending on how many shift functions we want, we may have to spill over into a second virtual device. If we then add another physical device, what do we do? Do we map that to a third (or even fourth) virtual device? What if we want some of the new device's buttons to overlap with our existing ones?
Joystick Gremlin is extremely powerful, but reliance on user mapping to virtual devices, which are then mapped to in-sim bindings, turns the layer of virtual abstraction into a hindrance, instead of the asset it was at the outset. Fundamentally, we don't care how things are bound to virtual devices under the hood. What we really would like to do is skip the VJoy part altogether and assign physical axis and buttons (including shifted buttons, merged axes, etc.) onto the in-sim bindings. The question is, how can we do that while still leveraging the other amazing features Joystick Gremlin provides?
With this fork of the original code, the virtual device selector widget is modified to give the user a second binding selection option, in addition to the original VJoy device and axis/button drop-downs. The list of bindings is mapped to a list of virtual axes/buttons, so selecting a binding is no different than selecting the corresponding VJoy output - but we avoid the step of needing to manually cross-reference which in-sim binding corresponds to which VJoy output. Now, we can also map multiple physical inputs to one binding and ensure they all update together if that binding needs to be assigned to a new virtual device.
This approach does require additional setup:
- A unique list of desired bindings must be generated and assigned to VJoy outputs inside Joystick Gremlin
- Those bindings must be assigned to functions inside the sim itself
Fortunately for (1), we have abstracted the virtual devices where we no longer have to keep track for any virtual device numbering in ourselves. Given a list of in-sim button functions we can freely assign them in any order within Joystick Gremlin's VJoy lists. This is made easier if the in-sim functions are contained inside a text file (such as is the case for XPlane 11 and IL-2 Cliffs of Dover) or if we can list the desired in-sim functions to a "neutral" csv. From either, we can create a script to import bindings to existing VJoy outputs automatically.
Again, if in-sim functions are contained inside a text file, we can simplify our lives with (2) as well. We can create another script to export bindings within the current profile, with their corresponding VJoy outputs, into the entries of our sim config file. If the sim does not use a user-editable text config file, the in-sim wizard should be used after bindings have been mapped to physical inputs.
The recommended approach is to import all possible sim functions into Joystick Gremlin, then export the bound VJoy outputs back to the sim. This gives direct access to all relevant functions within Joystick Gremlin, even if those functions are not later bound to physical inputs. Additionally, modification of in-sim config files is only required once when using this method.
Note: Binding selection is not (yet) supported in macro VJoy selectors, so macro behavior with virtual outputs is unchanged from the R13 release. To help find the correct virtual output, you may use a Remap for reference.
It should be self-evident that every VJoy output may only map to a single in-sim function, regardless of Gremlin mode. Binding uniqueness is enforced in Joystick Gremlin on profile read and when new bindings are added from within Gremlin itself.
In the case of a manually-edited profile file, there may be inconsistent bindings between modes. For a given input item, Joystick Gremlin will capture the first non-empty binding found. If that same input item is given a different binding in another mode, the previous binding is overwritten with the new one. If the same binding string is used on another input item, even one of a different type (i.e. axis vs. button), the binding will be cleared from the old input item. A message is recorded to the system logger for each overwrite and/or binding clear. The VJoy output description is also cleared
When binding text is changed from the VJoy tabs within Joystick Gremlin, we check for it across all other VJoy outputs, regardless of output type. If the binding exists in the profile on another VJoy output, we allow the new binding to overwrite the old. A message is recorded to the system logger each time an overwrite occurs.
For determining binding uniqueness, all binding strings are treated as case-sensitive. Leading and trailing whitespace is also stripped upon entry.
Note: Binding descriptions are not forced to be unique. Like bindings, VJoy output item descriptions are copied across all modes. For convenience they are cleared if their associated VJoy binding is cleared due to an overwrite.