Start with the recommended baseline, change one value at a time, and test each adjustment under consistent conditions.
If you've opened the menu of a Cronus Zen script and found a setting called VM Speed, you may wonder whether it controls controller sensitivity, input lag, polling rate or something else entirely.
VM Speed refers to the timing of the Cronus Zen virtual machine running the GPC script.
In simple terms, it determines how frequently the Zen runs another iteration of the script's main loop.
What Does VM Mean?
VM stands for Virtual Machine.
A GPC script runs repeatedly while its memory slot is active. During each iteration, it can check controller inputs, update variables, activate programmed features and modify controller output.
The time between those iterations is what the VM Speed setting controls.
What Is the Default Cronus Zen VM Speed?
The standard Cronus Zen virtual machine interval is 10 milliseconds.
That means the script's main loop normally runs approximately once every 10 ms.
Some scripts leave this setting untouched, while others use the GPC vm_tctrl() function to alter the interval.
Common VM Speed Values
Across GPC scripts, you may see menu choices such as:
| Displayed VM Speed | Main Loop Interval |
|---|---|
| 10 ms | Standard/default timing |
| 8 ms | Runs more frequently than default |
| 6 ms | Runs more frequently |
| 4 ms | Fast script-loop timing |
| 2 ms | Very fast script-loop timing |
| 1 ms | Very frequent script iterations |
The exact choices depend on how the individual GPC developer built the script.
How VM Speed Appears in GPC Code
GPC scripts can change their VM timing with the vm_tctrl() function.
The standard virtual-machine base interval is 10 ms. Many scripts therefore use negative offsets to reduce that interval.
Common examples include:
-
vm_tctrl(0)— 10 ms -
vm_tctrl(-2)— 8 ms -
vm_tctrl(-4)— 6 ms -
vm_tctrl(-6)— 4 ms -
vm_tctrl(-8)— 2 ms -
vm_tctrl(-9)— 1 ms
These patterns appear across a number of the GPC scripts in the current CzenScripts library.
Is a Lower VM Speed Faster?
Yes, when you're looking at the interval in milliseconds.
A 1 ms VM interval means the script attempts another main-loop iteration more frequently than a 10 ms VM interval.
For example:
- 10 ms = roughly 100 iterations per second
- 5 ms = roughly 200 iterations per second
- 2 ms = roughly 500 iterations per second
- 1 ms = roughly 1,000 iterations per second
Those numbers describe the theoretical script-loop frequency, not the controller's hardware polling rate or the game's frame rate.
Does VM Speed Reduce Controller Input Lag?
Not in the simple way that the name might suggest.
VM Speed changes how often the GPC code is evaluated. It does not directly change your:
- Console frame rate
- Display refresh rate
- Internet latency
- Game server latency
- Controller hardware polling rate
A faster VM loop can allow script logic to be evaluated at shorter intervals, but that should not be confused with magically removing every form of gameplay delay.
Why Do Some Scripts Use a Faster VM?
Some GPC developers use shorter VM intervals because their scripts contain features that depend on relatively frequent timing updates.
This can include programmed systems involving:
- Stick movement
- Button timing
- Rapid input sequences
- Recoil correction
- Movement combinations
- Shot-timing routines
- Menu or state updates
The important point is that VM Speed affects the execution timing of the whole script loop, not just one individual mod.
Why Do Some Scripts Stay at 10 ms?
Because faster is not automatically better.
The normal 10 ms timing provides a stable baseline and may be completely adequate for the logic used by a particular script.
If the developer designed and tested the GPC around 10 ms, lowering the VM interval may change the behaviour of features that depend on timing.
Can VM Speed Change How a Script Feels?
It can.
If a script repeatedly adjusts controller output or checks for certain input conditions, changing the loop interval changes how frequently that code executes.
This can make some programmed behaviour feel different even if none of its visible strength or timing values have changed.
The extent of the difference depends entirely on how the script was written.
VM Speed and Anti-Recoil
An anti-recoil system generally checks whether its activation conditions are true and then applies programmed right-stick correction.
If that logic runs every main-loop iteration, changing the VM interval changes how frequently the script evaluates and applies its calculations.
That does not mean lowering VM Speed automatically gives stronger or better recoil correction.
A script's recoil system may already have been designed around a specific VM timing.
VM Speed and Aim-Related Scripts
A similar principle applies to scripts that produce programmed aim-related stick movement.
If the movement is updated during every main-loop iteration, changing VM Speed can alter the frequency at which those stick calculations are performed.
It does not make the Cronus Zen see targets or analyze the game screen. The GPC is still processing controller inputs and generating programmed outputs.
VM Speed and NBA 2K Shot Timing
Shot-timing scripts often contain carefully timed combinations measured in milliseconds.
Changing VM behaviour without understanding the script can therefore be particularly unhelpful if you already have a timing configuration that works consistently.
If you're adjusting an NBA 2K script, change the actual shot-timing values first unless its instructions specifically tell you to change VM Speed.
VM Speed and Movement Combos
Movement-heavy scripts can contain several timed button and stick actions.
For example, a combo might:
- Move a stick.
- Wait for a specific period.
- Press another controller input.
- Release it.
- Move the stick again.
The GPC virtual machine controls the environment in which this programmed logic executes.
Changing VM timing may therefore affect a complicated script differently from a simple one.
Does VM Speed Change Combo Wait Times?
Do not assume changing VM Speed is equivalent to simply subtracting the same number of milliseconds from every wait() value.
Combo timing and VM iteration timing are related parts of script execution, but they are not the same setting.
If a combo has a timing value you need to tune, adjust the intended timing variable rather than using VM Speed as a substitute unless the script documentation specifically says otherwise.
Why Can Very Fast VM Settings Cause Problems?
Cronus' own GPC documentation warns that changing the VM timeout can introduce script instability.
A complex script has more calculations, menu logic and controller processing to complete during each cycle.
Running the VM more frequently gives the device less time between iterations.
That is one reason you should not assume 1 ms is automatically the ideal setting for every GPC.
Is 1 ms VM Speed Always Best?
No.
This is probably the most important point to understand about VM Speed.
A lower number means a more frequent VM loop, but it does not automatically mean:
- Better settings
- Better recoil correction
- Better aim behaviour
- Lower internet latency
- Better game performance
- A more stable script
The best VM configuration is generally the one the script was designed and tested to use.
Should You Change VM Speed?
If a script provides VM Speed as a normal OLED-menu setting, you can test the available configurations carefully.
If the script does not expose VM Speed as a normal user setting, there is usually little reason to edit the GPC simply to make the number lower.
Follow the individual script's supplied configuration first.
How to Test Different VM Speeds
If your script intentionally provides several VM choices, test them like any other setting:
- Record the current VM setting.
- Keep your other script settings unchanged.
- Change VM Speed by one available step.
- Test the same script functions again.
- Watch for inconsistent or unexpected behaviour.
- Return to the original value if the new setting performs worse.
Do not change VM Speed, recoil, aim values and controller settings simultaneously or you will not know which change produced the difference.
How to Check VM Speed in Zen Studio
Zen Studio's Device Monitor can display the current VM Speed while your Cronus Zen is connected through its programming connection.
The Device Monitor also provides information such as:
- CPU load
- Controller inputs
- Processed outputs
- Active memory slot
- Rumble information
- Connected USB and Bluetooth devices
This makes it useful when testing or debugging a GPC script.
VM Speed vs CPU Load
VM Speed and CPU load are related concepts, but they are not the same measurement.
VM Speed describes how frequently the virtual machine runs another iteration.
CPU load describes how much computational work the Zen is performing.
A complicated script running at a very frequent interval can place different demands on the device than a simple script running at the default interval.
VM Speed vs VM Speed Menu Setting
Not every script presents VM Speed in the same way.
One script might display:
- 10 ms
- 8 ms
- 4 ms
- 2 ms
- 1 ms
Another might present numbered modes such as:
- Default
- Fast
- Faster
Another GPC may simply hard-code a VM timing without showing any setting to the user at all.
Always interpret the option using the particular script's instructions.
Why Does One Script Use 1 ms and Another Use 10 ms?
Different GPC developers structure their code differently.
A script with complex repeated stick calculations may have been designed around one interval, while another script with simple controller shortcuts may work perfectly at the normal VM timing.
The fact that two scripts use different values does not by itself mean one is more advanced or better.
Common VM Speed Mistakes
Avoid these common assumptions:
- “Lower always means better.” It doesn't.
- “1 ms removes input lag.” VM timing is only one part of script execution.
- “VM Speed is controller polling rate.” They are different concepts.
- “Changing VM Speed only affects one mod.” It can affect the entire GPC loop.
- “Every script should use the same VM setting.” Different scripts are written around different timing assumptions.
What Setting Should You Use?
For most users, the safest answer is straightforward:
Use the VM Speed recommended or configured by the script developer unless you have a specific reason to change it.
If a script exposes several choices, test them individually and keep the setting that allows that particular GPC to behave consistently.
If the script does not expose VM Speed at all, there is usually no need to modify it manually.
What If a Script Acts Strangely After Changing VM Speed?
Restore the previous VM setting first.
If the problem disappears, leave the script at the configuration it was designed around.
If the problem continues, check the rest of your setup using the CzenScripts Cronus Zen Troubleshooting Wizard.
Learn Your Script Before Changing Advanced Settings
VM Speed is an advanced script-level setting, so it is worth understanding the rest of your GPC before experimenting with it.
Use the CzenScripts script instructions by game page to find configuration information for supported scripts.
You can also read the complete Cronus Zen guide if you're still learning how Zen scripts, memory slots and controller configuration work.
Final Thoughts
VM Speed controls how frequently a Cronus Zen GPC script's virtual-machine loop runs.
The normal Cronus Zen VM timing is 10 ms, while GPC scripts can change that interval. A lower millisecond value means the script loop is evaluated more frequently.
But faster is not automatically better.
VM Speed can affect how frequently script logic is processed, and changing it can alter the behaviour or stability of a GPC that was designed around another interval.
Use the setting supplied by the script first, change it only when there is a reason to do so, and test one adjustment at a time.
For more setup help, visit the CzenScripts Complete Cronus Zen Guide.
