Merging Bindings
Your bindings live in different places. DCS has some, Joystick Gremlin has others, and a base profile might share bindings across three aircraft. Joystick Diagrams can merge all of that into one diagram per device. This page covers the two user-configured tools that do it (profile inheritance and device aliases) plus the conflict strategies that decide what happens when two bindings land on the same input. A third source of merging, input routing, happens automatically in supporting plugins (notably Joystick Gremlin); you don't configure it, but it feeds into the same conflict strategies.
When Merging Happens
Joystick Diagrams merges bindings in three situations:
- Profile inheritance. A base profile pulls in bindings from one or more parent profiles. User-configured.
- Device aliases. You explicitly tell Joystick Diagrams that two GUIDs refer to the same physical hardware. User-configured.
- Input routing. A parser plugin declares that bindings on a virtual device should surface on the physical device that fed them. The Joystick Gremlin plugin uses this to place vJoy bindings on the real stick automatically. No setup required. See JG vJoy routing.
All three eventually land in the same question: when two bindings collide on the same button or axis, what should appear on the diagram? That's the job of the conflict strategies.
Profile Inheritance
A base profile receives bindings from one or more parent profiles. Typical use case: you have a shared HOTAS layout with comms, view controls, and UI actions that apply to every aircraft, plus aircraft-specific bindings that override the base.
Setting up Inheritance
- Process at least one plugin so profiles are available.
- Go to Customise → Inheritance.
- Select the base profile in the list.
- Add one or more parent profiles.
- Order the parents. Higher in the list = higher priority. The top parent wins against a lower parent on any collision.
Inheritance Rules
- Bindings flow from parents into the base. Parent profiles are never modified.
- The base profile wins by default. Its bindings stay, the parent's binding is dropped on a collision. You can change this behaviour with an inheritance conflict strategy.
- Parents apply in priority order. The top parent is consulted first.
- Inheritance can cross plugins. A Joystick Gremlin profile can parent a DCS profile.
Worked Example
A base profile F-15E with two parents: UiLayer and F-15E_WSO.
With the default Keep Existing strategy, the base wins every collision.
BTN 1 exists on both the base and a parent. The base profile wins, so Action F is kept. All other bindings are merged in.
Device Aliases
An alias tells Joystick Diagrams that two device GUIDs refer to the same physical hardware and should be collapsed into a single device on your diagrams. You set aliases up manually when a plugin doesn't already handle the merge for you via input routing.
When you'd reach for an alias:
- Two plugins see the same stick under different GUIDs because of OS or driver quirks.
- You swapped hardware and want bindings from the old device's GUID to show on the new one without re-binding in-game.
- You use a third-party remapper whose parser plugin doesn't (yet) declare routes, and you want to merge its virtual device into the physical one manually.
Setting up an Alias
- Go to Customise → Devices.
- Select the source device (the GUID to hide).
- Choose the target device (the one to merge into).
- Pick a conflict strategy for how bindings collide on the target.
Alias Rules
- One hop only. You can't alias A→B if B is already aliased to C. Chained aliases aren't supported.
- Fan-in is allowed. Multiple sources can target the same device.
- The source device is hidden from diagrams. Its bindings surface on the target instead.
Conflict Strategies
When two bindings collide on the same input, Joystick Diagrams needs a rule for what the diagram should show. Strategies are set globally from Settings and there are two independent choices: one for inheritance, one for aliases.
Changing a strategy immediately reprocesses all profiles. You'll see a status-bar toast ("Settings applied, profiles reprocessed") and the diagrams update next time you visit the Export or View tabs.
Alias Conflict Strategy
Both bindings kept on the winning input. The text becomes
winner | [qualifier] loser. If the qualifier is empty the brackets are dropped.
The loser's binding is promoted to a modifier on the winner's input. The qualifier (Short, Long, Toggle, Conditional, or the source input id for bare containers) becomes the modifier key set.
Inheritance Conflict Strategy
The base profile's binding stays. The parent's binding is dropped. This is the historical behaviour.
Both shown: base | [parent_name] parent_action.
The qualifier is the parent profile's name.
The parent's binding becomes a modifier on the base's input, with the parent profile name as the modifier key.
In every strategy, pre-existing modifiers on the loser are carried into the winner's modifier list. If both sides already had the same modifier key, the winner's version stays.
Qualifiers (Joystick Gremlin)
When an alias or a routed binding surfaces on the diagram, Joystick Gremlin's container type becomes a qualifier: a short label that tells you what kind of action it was.
| Gremlin container | Qualifier |
|---|---|
tempo | Short / Long |
double_tap | Single / Double |
smart_toggle | Toggle |
| Any container with an activation condition | Conditional |
basic | no qualifier, bare join |
How Routing Looks on Your Diagram
The most common multi-source case (Joystick Gremlin feeding vJoy, game reading vJoy) is handled by input routing, not aliasing. There's nothing to configure. This section is here so you can see what routing actually produces.
Say you fly DCS, and in Joystick Gremlin you have your stick and a vJoy device configured.
On BUTTON_3 you've added a tempo Remap: a short press passes through, a long press
sends a vJoy button instead. In DCS itself, the physical BUTTON_3 is bound to
Kneeboard Next Page, and that vJoy button is bound to Kneeboard ON/OFF.
When the Joystick Gremlin plugin parses your profile, it records a route from the vJoy button back
to the physical BUTTON_3. The DCS plugin reads its own bindings as usual. Before rendering,
Joystick Diagrams applies the route, so the Kneeboard ON/OFF binding surfaces on the physical button
where you actually press it. The alias conflict strategy decides how the two labels share that one input.
One diagram, one input, both labels. No alias, no setup: the JG plugin broadcast a route and the DCS plugin's binding landed on the physical input.