The FiveM Runtime Test Methodology
A runtime reading only counts as a measurement if it states what produced it: artifact version, framework, real player count, duration, and both idle and active resmon values, backed by a dated capture. Vice Drip has not published one for any product. This document sets the exact bar we are committing to be held to when we finally do.
There's a difference between a target and a measurement. Our own idle and active performance budgets — 0.00 to 0.02ms idle, under 0.10ms active — are design goals, stated as targets until a real reading exists. This document is about what turns a number into a measurement: the conditions that have to be stated alongside it before anyone should trust it.
'Runtime proof,' as we use the term across this site, means a resource's core loop completing in a live, populated FiveM world, evidenced by a log or a capture. That's a narrower and different claim than a resmon idle reading, and different again from a controlled economy race or crash test run on a staging harness — those prove something real, but not this. Conflating the three is exactly the kind of vagueness this document exists to close off.
This is the specification we're publishing before we have a result that passes it. As of this writing, no Vice Drip product has a published runtime capture — this document defines the bar we will be held to when one exists, not a description of one we already have.
Reproducible, step by step.
- 01State the environmentHost type (dedicated, VPS, or local), operating system, and the hardware the FXServer process actually ran on. The same resource can read differently on different hardware.
- 02State the exact artifact versionThe FXServer build number, not 'latest' — 'latest' means something different every week and can't be reproduced later.
- 03State the framework and versionQbox, QBCore, or ESX Legacy plus the specific version or commit, and roughly what else was running alongside it. A near-empty resource list understates real-world cost.
- 04State the player count and how it was reachedReal connected clients versus simulated or bot connections, disclosed explicitly. A bot rarely reproduces real interaction patterns, and the difference matters to anyone comparing numbers.
- 05State the durationA 60-second snapshot and a multi-hour session are different claims. Report both the idle observation window and the length of the active session.
- 06Exercise the actual core loopDefined per resource — for a garage script, that means repeatedly retrieving, storing, and transferring vehicles under load, not leaving the resource idle and calling that a runtime test.
- 07Record resmon twiceIdle (no interaction, 60+ seconds) and active (sustained use across the duration above) — a single number with no label for which state produced it is ambiguous.
- 08Capture the artifactA server console log excerpt or a timestamped screen recording showing the resmon reading and the core loop completing, kept on file.
- 09Publish everything together, datedThe reading, every condition above, and the capture. A number missing any of these fields is not a measurement by this methodology's own pass condition — including if the number is ours.
What this measures — and what it does not.
The second column is the one that matters. A method that only advertises its reach is a brochure; the limits are what let you judge whether a result means anything for your server.
What it measures
- Client and server CPU cost, in milliseconds per frame, under a stated artifact version, framework, player count, and duration.
- Whether the resource's core loop actually completes against real player interaction in a live world.
- Whether a published number carries enough stated conditions for someone else to attempt the same reading.
What it does NOT measure
- Network bandwidth, database load at production scale, or behavior under packet loss — resmon reads CPU time only.
- Long-session memory growth beyond whatever duration was actually observed and stated — a ten-minute capture says nothing about hour six.
- Subjective smoothness or player-perceived lag — resmon is a per-resource CPU figure, not a full picture of client frame time.
- Economy correctness — dupes or drift. That's the separate economy integrity checklist; a resource can read 0.00ms idle and still be able to duplicate money.
What counts as a pass, and what does not.
| Criterion | Pass | Fail |
|---|---|---|
| Stated conditions | Artifact version, framework and version, player count (and whether real or simulated), and duration are all stated alongside the number. | Any one of the four is missing or vague — 'latest,' 'a full server,' 'a few players.' |
| Idle vs. active | Idle and active values are both reported, each labeled as such. | A single number is presented without saying which state produced it. |
| Corroborating artifact | A log excerpt or a timestamped recording exists on file supporting the reading. | The number has no corroborating artifact behind it — it's an assertion, not a capture. |
| Live, populated core loop | The resource's actual feature loop was exercised under the stated player count, not left idle. | The resource sat idle, or was exercised with a call pattern that doesn't resemble real use. |
Our own results against this method.
- Vice Drip has not published a runtime capture for any product — every performance figure on the site reads [measured-pending] / Pending Shadow bench rather than a dated number.
- Measured against this document's own pass conditions, every product in the catalog fails the runtime-proof criterion today — including the one product with other measured evidence. MoneyTrail's race and crash results are real, dated, and specific, but they are not a runtime capture: they were run on a controlled test harness, not exercised as a core loop against real players in a live world.
- The idle 0.00–0.02ms and active under 0.10ms figures published elsewhere on this site are stated as design targets, not measurements, precisely because no reading meeting this methodology's pass conditions exists yet for any product.
- We're publishing this specification before we have a result that passes it. That ordering is deliberate — it's easier to hold a claim to a bar that was written after the fact. This one was written first.
- When a capture is produced, this document is what it will be checked against before it's allowed to replace a [measured-pending] label anywhere on the site.
What counts as a real runtime measurement versus a target?
A target is a design goal stated with no reading behind it — our own 0.00–0.02ms idle budget is one, until it's measured. A measurement states the artifact version, framework, player count, duration, and date, and is backed by a log or capture someone else could ask to see.
Why isn't a resmon screenshot enough on its own?
A screenshot shows a number but not the conditions that produced it. Without artifact version, framework, player count, and duration, the number can't be reproduced or compared to anything else, which is what separates a measurement from a claim.
Has any FiveM store actually published a runtime capture like this?
We haven't surveyed the market on this specific question with dated data, so we won't claim a market-wide answer. What we can state is our own status, plainly: none published, as of this writing.
Does Vice Drip have any measured results at all?
Yes, but not a runtime capture. MoneyTrail's (vf_banking) race and crash tests are dated, measured results from a controlled test harness. They answer whether the money math survives concurrency and crashes, not whether the resource runs cleanly on a live, populated server — which is what this methodology is specifically about.
Published 2026-09-02 · Last reviewed 2026-09-02 · All methodology