Titan Two GPC2 scripting: design a first controller test

Write down the behavior before the code

Decide what should happen when the test button is pressed, held and released. Specify the expected behavior of all other controls. A small experiment makes it easier to see whether the wrong button identifier, an overlapping translator or a script branch produced an unexpected result.

Use the GPC Input Reference in Gtuner IV to check the control identifiers for your controller. Physical labels vary by platform. Selecting the corresponding identifier is more reliable than guessing from a different controller diagram or copying a Titan One example.

Keep the first build small

Open a fresh project in the Script IDE and compile after introducing the first input change. Keep a copy of that building version. Add the next behavior only after the output is predictable. If an identifier depends on a header, use the one that matches the project and keep it in the project’s documented location.

Consider whether the whole task is only a static remap. An Input Translator can be a simpler fit for a layout with fixed mappings. GPC2 becomes useful when the outcome depends on state, timing or a conditional response that a static layout cannot express.

Observe the output outside the editor

Connect the device and use Gtuner IV’s testing tools in an offline test environment. In Device Monitor, compare the button you pressed with the output that changed. Repeat the sequence with the script unloaded. Also hold and release the button so you know the output returns to its expected idle state. Save the source with a note describing which device and inputs you tested.