GPC Debugging in Zen Studio: Device Monitor and Traces

GPC debugging on the Cronus Zen comes down to two tools, both built into Zen Studio: the compiler output, which catches problems before a script ever reaches the device, and the Device Monitor, which shows you what a running script is actually doing to your inputs in real time. GPC has no console or print statement, so the standard technique is writing values into the six TRACE fields and watching them live. This guide covers the full workflow: reading compiler errors correctly, using the Device Monitor's panels, and instrumenting a script with traces.

Compile-time vs. run-time: two different problems

Before touching any tool, be clear about which kind of bug you have, because the fix lives in a different place for each.

The Zen Studio compiler is a full editing environment with syntax highlighting, find and replace, and real-time error reporting. When you press Compile (F7), the output panel reports errors, warnings, bytecode size, stack usage, and the percentage of slot memory used. Build and Run (F5) goes one step further: it compiles the active script and loads it directly into the device's RAM, which is the fastest loop for live testing because you skip programming a memory slot entirely. For flashing a finished script to a permanent slot, see how to load a GPC script.

Common GPC compile errors and how to fix them

Compiler errors almost always reference a line number. Two habits save the most time: fix the first error before reading the rest (one early mistake, like a missing brace, cascades into dozens of phantom errors below it), and remember the real mistake is often on the line above the reported one, since the compiler flags where parsing failed, not where you made the typo.

Older scripts written for earlier toolchains may also need the legacy 16-bit compiler option, found in Zen Studio's Device panel, before they compile cleanly. If a script from a reputable source throws errors on a fresh, unedited copy, suspect your environment first — an outdated Zen Studio or firmware build is the usual culprit, and the firmware changelog explains how versions and script support relate.

The Device Monitor: watching a script run

The Device Monitor is Zen Studio's real-time diagnostic view, and it only works while the Zen is connected to your PC through the PROG USB port. It shows everything moving through the device:

• Input area — the live state of every button, stick, trigger, and sensor on the connected controller, before your script touches anything. Any field can be selected for plotting.
• Output area — the values the Zen is actually sending to the console after your script has processed them, plus six trace debug fields reserved for script feedback.
• CPU load — how hard the script is working the Zen's processor. As a rule of thumb, sustained values under 80% are acceptable; scripts that pin the CPU can stutter or drop inputs.
• VM speed — the virtual machine's loop interval, adjustable from 1 ms to 40 ms with a default of 10 ms. Timing-sensitive combos assume a loop rate, so changing this changes behavior.
• Active slot, battery, rumble, and LED status — quick confirmation of which slot is running and what the device is telling the controller.

The single most useful diagnostic move: compare the Input area against the Output area while pressing the button your script hooks. If input changes but output does not (or vice versa in a way you didn't intend), you have localized the bug to your script logic rather than cables, slots, or the console.

TRACE output: GPC's substitute for print

GPC provides six trace channels — TRACE_1 through TRACE_6 — that you write with set_val() like any output. TRACE_1 to TRACE_3 are 32-bit fields and TRACE_4 to TRACE_6 are 16-bit, so put large counters in the first three. Their values appear live in the Device Monitor's Output area, which makes them the closest thing GPC has to a print statement.

Here is a complete rapid-fire script instrumented with traces. Flash it (or use Build and Run), open the Device Monitor, and you can watch the toggle state and the outgoing trigger value in real time:

// Rapid fire with live trace instrumentation.
// Toggle: D-pad Up. Fire: R2 (RT on Xbox layout).
// Watch TRACE_1 and TRACE_2 in Device Monitor's Output area.

int rapid_on = 0;   // 1 = rapid fire enabled
int hold_ms  = 40;  // trigger held this long per shot
int rest_ms  = 30;  // trigger released this long per shot

main {
    // Toggle the feature on/off with D-pad Up.
    if (event_press(PS4_UP)) {
        rapid_on = !rapid_on;
    }

    // While enabled and the trigger is held, run the combo.
    if (rapid_on && get_val(PS4_R2)) {
        combo_run(RapidFire);
    }

    // Debug traces: these do nothing in game, but show live
    // in the Device Monitor so you can verify script state.
    set_val(TRACE_1, rapid_on);          // toggle state: 0 or 1
    set_val(TRACE_2, get_val(PS4_R2));   // trigger value being sent
}

combo RapidFire {
    set_val(PS4_R2, 100);  // press trigger fully
    wait(hold_ms);
    set_val(PS4_R2, 0);    // release
    wait(rest_ms);
}

If TRACE_1 never flips to 1, your toggle condition is wrong or the wrong slot is active. If TRACE_1 is 1 but TRACE_2 never pulses, the combo isn't firing. Each trace answers one specific question — that is the discipline: decide what question you're asking, then trace exactly the variable that answers it.

The Device Monitor can also plot up to four selected fields at once on a scrolling graph, with controls to pause the graph and capture screenshots. Plotting is the right tool for timing problems — watching a trigger's trace as a waveform makes it obvious whether your hold/rest timing actually produces the rhythm you intended, in a way raw numbers never will.

A repeatable GPC debugging workflow

1. Compile (F7) and clear every error and warning. Fix the first error, recompile, repeat. Note the memory percentage while you're there.
2. Build and Run (F5) to load into RAM for a fast test loop — no slot programming needed.
3. Open the Device Monitor and confirm the active slot/script name is the one you think you're testing. A surprising share of "my script is broken" reports are actually "the wrong slot is active."
4. Compare Input vs. Output for the buttons involved. This splits the problem in half immediately.
5. Add TRACE lines at the decision points — toggle states, computed values, combo entry — and watch them while reproducing the bug.
6. Check CPU load and VM speed if behavior is erratic rather than wrong. Heavy math in main every loop, or a VM speed the script's timing wasn't written for, both show up here.
7. When it works, remove debug traces, recompile, and flash the slot properly.

Scripts you downloaded rather than wrote deserve the same treatment — trace fields will tell you whether a script's mod is even activating before you blame its logic. If you're still hunting for a script worth debugging, start with the sources in where to find GPC scripts, and see the rest of the GPC scripting guides for language fundamentals.

FAQ

How do I open the Device Monitor in Zen Studio?

Connect the Zen to your PC via the PROG USB port and open the Device Monitor from within Zen Studio. It is unavailable over the console-side connection — no PROG connection, no monitor. If it appears but shows no data, reseat the PROG cable and confirm Zen Studio detects the device.

What are TRACE_1 to TRACE_6 in GPC?

Six debug output channels you write with set_val(TRACE_1, value) and read live in the Device Monitor's Output area. TRACE_1–TRACE_3 hold 32-bit values, TRACE_4–TRACE_6 hold 16-bit values. They don't affect gameplay; they exist purely for GPC debugging and can also be plotted graphically.

Why does my script compile but do nothing in game?

The usual causes, in order: the wrong memory slot is active on the Zen, the script's toggle is off (many scripts start disabled), or your button layout differs from what the script expects. The Device Monitor settles it fast — check the active slot, then trace the toggle state.

What does high CPU load on the Cronus Zen mean?

The script is doing too much work per loop. Sustained load under roughly 80% is considered acceptable; above that, expect stutter or dropped inputs. Reduce per-loop math, avoid redundant combo runs, and re-test. VM speed changes also shift load, but they alter combo timing, so adjust with care.

Can I debug a script without flashing it to a memory slot?

Yes. Build and Run (F5) compiles the active script and loads it straight into device RAM for immediate testing. It's temporary — flash the script to a slot when you're done so it survives normal use.