What Is GPC? The Cronus Zen Scripting Language Explained

GPC is the scripting language that programs the Cronus Zen. A GPC script sits between your controller and your console, reading every input many times per second and, where the script says so, changing what the console receives — pressing buttons for you, reshaping stick values, or firing off timed sequences. It is a small, C-flavored language: if you have seen any C, JavaScript, or Arduino code, the shape of GPC will look familiar. This page explains what the language is, how a script is put together, and — just as importantly — what GPC can and cannot actually do.

GPC at a glance

GPC stands for Game Pad Control (Cronus's own materials have used slightly different expansions over the years; the acronym is what stuck). The essentials:

The single most important idea: GPC is reactive. You do not write a program that runs top to bottom once. You write a main block that the Zen executes over and over, once per controller report, for as long as the script is loaded. Each pass, your code inspects the current state of the controller and decides what the console should see for that instant. The get_val and set_val model is the heart of it.

Where GPC came from — and the GPC2 trap

GPC predates the Zen. It was developed for Cronus's earlier CronusMAX devices, and the Zen inherited the same language and toolchain lineage. That history matters for one practical reason: most GPC documentation and forum code you will find was written across a decade of Cronus hardware, and nearly all of it still applies to the Zen.

There is one major exception to watch for. ConsoleTuner's Titan Two — a competing device — uses a language called GPC2. It looks similar at a glance but is a different language with a different compiler. If you paste GPC2 code into Zen Studio it will not compile.

When you search for script examples, add "Cronus Zen" or "CronusMAX" to the query and sanity-check the vocabulary before assuming a snippet will work.

How a GPC script is structured

A GPC file is organized into a handful of sections. Only main is truly mandatory in practice; the rest appear as needed, conventionally in this order:

1. define statements — named constants, so timing values and thresholds have readable names.
2. Global int variables — the script's memory between passes of the loop.
3. init { } — a block that runs once when the script starts. Used for one-time setup.
4. main { } — the loop. Runs continuously, once per controller report.
5. combo blocks — named, timed sequences of simulated inputs, started from main with combo_run().
6. Functions — reusable helpers you define yourself.

Here is a complete, working illustration of the two sections you will use constantly — main and a combo. It turns a single Square press into a double tap:

// what-is-gpc example: turn one Square press into a double tap.
// Complete script — compiles as-is in Zen Studio.

main {
    // event_press() is true only on the exact pass where the
    // button goes from released to pressed, so the combo starts
    // once per physical press instead of restarting every pass.
    if (event_press(PS4_SQUARE)) {
        combo_run(DoubleTap);
    }
}

combo DoubleTap {
    set_val(PS4_SQUARE, 100);   // press Square fully...
    wait(60);                   // ...hold for 60 ms
    set_val(PS4_SQUARE, 0);     // force it released...
    wait(60);                   // ...for 60 ms
    set_val(PS4_SQUARE, 100);   // press again
    wait(60);
}

Everything between one wait() and the previous one describes what the Zen holds down for that window of time. When the combo reaches its closing brace, the script stops overriding those controls and your physical inputs pass through again. The full timing model is covered in the combos and macros guide, and every keyword above is documented in the GPC syntax reference.

What GPC scripts can do

Because a script sees every input and can rewrite any of it, a surprising range of behavior fits in a few dozen lines:

• Rapid fire — convert a held trigger into timed pulses for semi-automatic weapons.
• Anti-recoil — add a constant counter-pull to a stick axis while firing.
• Combos and macros — execute multi-step sequences (button chains, skill-move inputs, build sequences) from a single press.
• Remapping and layering — swap controls on the fly, or make one button do different things on tap versus hold.
• Toggles and profiles — turn any of the above on and off in-game with button combinations, no menu required.
• Accessibility adjustments — turbo buttons, hold-to-press conversions, sensitivity reshaping for players who need them.

Scripts are stored on the Zen's onboard memory slots, so once a script is flashed the PC can be disconnected entirely.

What GPC cannot do

This is where product marketing tends to blur lines, so to be precise:

• GPC cannot see the game. The Zen has no access to the video feed, game memory, or network traffic. A script knows only what your controller is sending. There is no "aimbot" in the PC-cheat sense — a script cannot know where an enemy is.
• GPC cannot beat server-side rules. If a game caps fire rate or validates action timing on the server, a script cannot exceed those caps, whatever a seller claims.
• Nothing is outcome-guaranteed. Timing-based scripts (shot timing, skill moves, combos) are tuned against a specific game build; a patch can silently change the timings and quietly break a script.
• It does not make automation invisible. Scripted input is still input, and publishers can and do analyze input patterns. Using input-automation devices also violates most games' terms of service and virtually all competitive league rules — that trade-off is yours to weigh, and no script changes it.

From source code to the Zen

The path from a .gpc file to your console runs through Zen Studio:

1. Write or paste the script into Zen Studio's compiler/IDE view.
2. Compile it. Errors stop the build with a line number; a clean compile produces bytecode for the Zen's virtual machine.
3. Program the compiled script to one of the Zen's eight memory slots.
4. Select that slot on the device and play. The script runs on the Zen itself.

Exact button labels in Zen Studio shift between versions, so follow the current documentation in Cronus's guide portal rather than screenshots from old forum posts.

Where to go next

If you learn best by building, start with the first GPC script tutorial — it constructs a rapid-fire toggle line by line and explains every choice. If you prefer a map before the territory, read the syntax reference and the inputs and events explainer first. The full set of scripting guides lives in the GPC scripting category.

FAQ

Is GPC the same as C?

No, only C-shaped. GPC borrows C's braces, semicolons, operators, and if/else, but it has no pointers, no strings, no standard library, and integer-only variables. The structure — a forever-looping main plus timed combo blocks — is specific to GPC.

Do I need programming experience to learn GPC?

No. GPC is a realistic first language because scripts are short, feedback is immediate, and the whole useful vocabulary is a couple dozen functions. Most working scripts are under a hundred lines.

Can GPC scripts run without a PC connected?

Yes. Scripts are compiled in Zen Studio and flashed to the Zen's onboard memory slots; after that the device runs them standalone between the controller and console.

Will a GPC script work on both PlayStation and Xbox?

Generally yes. The PS4_ and XB1_ identifier families refer to the same internal input slots, so a well-written script drives either console. What does change per game is timing — combo and rapid-fire values usually need retuning.

Is using GPC scripts allowed in online games?

Most games' terms of service prohibit input-automation hardware, and competitive leagues ban it outright. Enforcement varies by publisher and changes over time, so research the current stance for your specific game before deciding.