Username or email Password Join now

Input Configuration Info

Using the H-shifter gearbox


The H-shifter support is intended to be used with Logitech G27 and compatible wheels. It will not work with normal buttons!

The shifters that are part of common commercial racing wheels are designed to mimic the layout of the manual shifters in cars that usually have up to six gears for forward movement. The trucks on the other hand tend to have much more gears. Having separate position for each gear would be not practical so an additional control is used to select an active gear set. Then a single gear from the set is selected by standard H-shifter pattern. For more information about available patterns see Wikipedia.

The gearbox simulated in the game has twelve forward gears and one reverse gear. In the default configuration the in-game H-shifter gearbox behaves as a "Range transmission" (see link above) where the "Shifter Toggle 1" button switches between gear set 1-6 and gear set 7-12. (see Controller options in the game, on the G27 it is mapped to the leftmost red button on the H-shifter by default).

Gear shifting example

You have a gear 6 selected and you want to shift up to the gear 7 - you need to press the "Shifter Toggle 1" button to switch to gear set 7-12 and then move the H-shifter stick to the position 1.

In similar way, to shift down from gear 7 to gear 6, press the "Shifter Toggle 1" to switch to gear set 1-6 and move the H-shifter stick to the position 6.

Prepared configurations

You can use another predefined layout by downloading a one from zip files referenced below and extracting its content into the profile directory (remember to replace the PROFILE_ID with your real profile identifier):

My Documents\SCANIA Truck Driving Simulator\profile\PROFILE_ID

Range transmission

This is the default configuration used by the game. The "Shifter Toggle: 1" selects between gears set 1-6 and gear set 7-12.

Download configuration files.

Splitter transmission

The "Shifter Toggle: 1" selects between odd-numbered gears (1,3,5,7,9,11) and even-numbered (2,4,6,8,10,12) gears.

Download configuration files.

Range-Splitter transmission

This configuration tries to emulate a layout of a real Scania H-shifter. Note that the game does not simulate the second reverse gear nor the two crawling gears so corresponding positions are not used.

This case is a combination of both preceding transmission types where the "Shifter Toggle: 1" switches between gear ranges and "Shifter Toggle: 2" switches between splitted gears.

Download configuration files.

Advanced configuration

The default H-shifter layout was selected to fit the most players, however with some tweaking of the gearbox configuration file it is possible to create a more realistic layout matching the range-splitter on some Scania trucks.

The gearbox configuration file can be found in your profile directory (remember to replace the PROFILE_ID with your real profile identifier):

My Documents\SCANIA...Simulator\profile\PROFILE_ID\gearbox.sii

The file contains a list of entries that map the condition triplet (h shifter position, selector 1 state, selector 2 state) to the concrete gear to use.

direct_gearbox_gear : _nameless.0F5B.B220 {
	gear_impulse_index: 0
	selector_1: -1
	selector_2: -1
	gear: 0

Name Description

Defines which position should the H-shifter be in:

  • 0 - neutral
  • 1 - "Shifter Position: Reverse"
  • 2 - "Shifter Position: 1"
  • 3 - "Shifter Position: 2"
  • ...
  • N - "Shifter Position: N"
Take care when editing the input configuration (see below). The game does not check if your H-shifter hardware supports the position you've entered.

Defines the state of the first selector:

  • -1 - ignore the selector state
  • 0 - the selector should be off
  • 1 - the selector should be on

Defines the state of the second selector.
See selector_1 for list of possible values.


The gear to shift in when the three conditions above are met.

Custom hardware

It is possible to use a custom H-shifter hardware provided that it reports the position as continuous press of some button. With more complex custom configuration of the input a position reported as axis value (e.g. aircraft throttle) can be also supported.

If the hardware has the ability to differentiate both positions of the range or splitter toggles, an additional inputs gearsel1on / gearsel2on and gearsel1off / gearsel2off, which are not accessible through the UI, can be configured instead of the toggling one.

Using multiple controllers with the game

Since version 1.2.0 the game UI supports use of up to three controllers.

The game is able to simultaneously use of more than three controllers, however such setup can not be configured through the game user interface and manual tweaking of the game's configuration files is required.

This section describes how an advanced user can manually tweak the configuration file to be able to use more than three controllers or create even more complex setups.

Note that the 1.0.0 version contains a known bug where the game might crash if controller does not provide X or Y axis. This bug was fixed in 1.1.0 patch.

Configuration file

The controller configuration is stored in profile directory (remember to replace the PROFILE_ID with your real profile identifier):

My Documents\SCANIA...Simulator\profile\PROFILE_ID\controls.sii

The file gets created when the controller or keyboard option screen is opened for the first time and contains a set of configuration lines which describe various components of the configuration.


This is an example how to use accelerator and brake pedal from a secondary controller and a horn button from a third controller without using the in-game UI available from 1.2.0. The same mechanism can be used if more than three controllers should be used.

  1. Using the steps described in the Input identification section determine the identification of the accelerator input on the secondary controller.
    Example identification: di8.'{C0002222-0000-0000-0000-000000000000}|{00000000-0000-0000-0000-000000000000}'.y
  2. Determine the identification of the brake pedal input on the secondary controller.
    Example identification: di8.'{C0002222-0000-0000-0000-000000000000}|{00000000-0000-0000-0000-000000000000}'.rz
  3. Determine the identification of the button input on the third device.
    Example identification: di8.'{C0003333-0000-0000-0000-000000000000}|{00000000-0000-0000-0000-000000000000}'.b4
  4. Restore the default configuration on both keyboard and controller options pages in the game (not strictly necessary, just for purpose of this example) and configure the primary device in a normal way using UI.
  5. To connect the accelerator pedal from the secondary controller to the in-game throttle input:
    Find the text "input j_throttle `joy.y`" in the configuration file and change the input identification so in our example it so it reads
    "input j_throttle `di8.'{C0002222-0000-0000-0000-000000000000}|{00000000-0000-0000-0000-000000000000}'.y`"
  6. To connect the brake pedal from the secondary controller to the in-game brake input:
    Find the text "input j_brake `joy.y`" in the configuration file and change the input identification to the secondary controller brake pedal identification so in our example it reads
    "input j_brake `di8.'{C0002222-0000-0000-0000-000000000000}|{00000000-0000-0000-0000-000000000000}'.rz`".
  7. In this case the pedals are reported as two separate axes so you need to turn off the combined axis by changing the value in "constant c_jcombined 1.000000" to "constant c_jcombined 0.000000"
  8. Depending on the device you might want to configure the deadzone for those inputs by changing values in "constant c_throt_dz 0.000000" and "constant c_brake_dz 0.000000"
  9. To connect the button from the third controller to the in-game horn input:
    Find the text "mix horn `keyboard.h?0`" in the configuration file and change the input identification so in our example it reads
    "mix horn `di8.'{C0003333-0000-0000-0000-000000000000}|{00000000-0000-0000-0000-000000000000}'.b4`".

Input identification

The game identifies individual inputs on the controllers using a name composed from several parts in following format:


The SYSTEM_ID will be almost always set to di8 indicating that DirectInput8 is used.

The DEVICE_ID is a string identifying the specific controller device. There are two ways to determine identification of the desired device. You can select the device as active in the UI and check what the game has stored in the "joy" device alias (find line containing text device joy) in configuration file. Alternatively you can look inside the game.log file for lines with following format:

[di8] Initializing device 'DEVICE_NAME' as 'DEVICE_ID'
The corresponding identification to use in the configuration file is then di8.'DEVICE_ID'

The INPUT_ID identifies a concrete input (e.g. axis, button) on the device. The best way to determine it is to use the game UI to create binding using that input and to check what the game has stored in the configuration file. For controllers it is usually b1 - b128 for buttons, x, y, z, rx, ry, rz for axes, sl1 or sl2 for sliders and pov_(1|2|3|4)_(up|down|left|right) for POVs

Sometimes the input identification is followed by an additional specification of the component of the input (e.g. "di8.rel_position.x" which represents X component of the mouse position delta). At other times a defined alias might be used to shorten part of the input name.

Component types

Device alias

Example format: device joy `di8.'{A76B60D0-A8FD-11E1-8002-444553540000}|{C29B046D-0000-0000-0000-504944564944}'`
User-creatable: Yes

The device alias defines a new name ("joy") which can be used in other parts of the configuration file as a shortcut to reference a specific input device without having to always use its full identification. Defining and using the device alias also allows simple switch to a different compatible device by changing the alias target without having to update the rest of the configuration. By default the game creates three aliases keyboard, mouse and joy to identify keyboard, mouse and joystick device selected in the UI.

Input alias

Example format: input j_steer `joy.x`
User-creatable: Yes

The input alias defines a new name ("j_steer") which can be used in other parts of the configuration file as a shortcut to reference a specific input (axis, button) from input device without having to specify the longer name. Same as with the device aliases case, input aliases also allow easy configuration changes. The game axis configuration UI works by changing input aliases to point to the selected axes.


Example format: constant c_steer_dz 0.000000
User-creatable: Yes

The constant defines a named ("c_steer_dz") numeric value which might be used by calculations in other parts of the configuration file or directly by the game itself (e.g. FF strength).


Example format: mix dsteerleft `keyboard.larrow?0 | keyboard.a?0`
User-creatable: No

The mix defines an expression which is used to calculate value of a single game input. The game can use this value as an analog input (e.g. fraction of the rotation of the steering wheel) or as a logical value (e.g. wipers toggle).

The interpretation and additional configuration of the individual mixes (in what situations they are evaluated) is hardcoded in the game and it is not possible to create additional mixes in the configuration file.

In the simplest form the expression returns value of a single input. The more complex forms can use several mathematical and logical functions (see below) to derive the results from more than one input. Note that the UI input configuration screens directly supports only a very limited subset of the expressions and will display "Complex" message if they can not handle the expression.

User-created components

For some component types it is possible to create additional components simply by using additional component definition line in the configuration file. Names of such components must meet following requirements:

  • Must be unique within the configuration file.
  • Must have at most 12 characters.
  • Only alphanumeric characters and underscore character are allowed.


The expressions are used to combine device inputs and apply deadzones or a non-linear functions to them. Several types of values can be used in the expression:

  • A reference to a constant value (e.g. 2.0)
  • A reference to a named constant (e.g. c_steer_dz).
  • A reference to a controller inputs using its full (e.g. or aliased form (e.g. In cases of some special inputs an additional component selector (.x, .y, .z, .yaw, .pitch, .roll) might be needed. In the default configuration file you will see that alternative syntax is used. That syntax indicates that if the input can not be found, the sub-expression should behave as if a constant 0 was returned from the device instead of reporting error and failing entire expression.
  • A reference to some other mix (e.g. dforward). Note that circular references are not allowed, however it is possible to reference the mix this expression belongs to. In that case a previous value is returned. Note that there are no guarantees no frequency or time between calls.
  • A special name unbound which resolves to constant zero. It is used to preserve information if no key is assigned to the primary binding slot.

The values can be combined using arithmetical (+, -, *, /) and logical (&, |, !) operators. Note that operator precedence rules are very simple so use of the brackets is highly recommended. When a value is interpreted in a logical context (e.g. during logical OR or AND operations or when it is used as logical value by the game), values greater than or equal to 0.5 evaluate to true and other values evaluate to false. Logical operators return 1.0 for true and 0.0 for false and have a short-circuit evaluation.

Following set of functions is also available. The range in brackets indicate allowed number of parameters to the function:

Function Description
max(1..) Returns biggest from the parameters.
min(1..) Returns smallest from the parameters.
abs(1) Absolute value of the parameter.
sign(1) Returns -1 if parameter is negative number, 1 if the parameter is positive number and 0 for zero.
gt(2) Returns 1.0 if the first parameter is greater than the second one.
gte(2) Returns 1.0 if the first parameter is greater than or equal to the second one.
lt(2) Returns 1.0 if the first parameter is lower than the second one.
lte(2) Returns 1.0 if the first parameter is lower than or equal to the second one.
sel(3) Returns the second parameter if the first parameter evaluates to true (see above), for false returns the third parameter.
bool(1) Returns 1.0 if the first parameter evaluates to true (see above) and zero otherwise.
normalize(2-3) Returns normalized position of the first parameter in the range formed by <second parameter, third parameter>. If the value is outside of the range, it will be clamped to it. If third parameter is not provided, 1.0 will be used. If the second and third parameter do not form valid non-empty range, zero will be returned.
deadzone(2-3) Applies a zero-symmetrical deadzone. Similar to the normalize, however it applies symmetrically to the negative values as well. If the second parameter is negative, it is set to zero.