Verify examples inside FiveM
Website tests, JavaScript mocks and C# compilation do not prove that an example loads or behaves correctly in FiveM. Run this procedure on an isolated development server and record separate results for each supported client track. This page is a test procedure; it does not claim that these in-game checks have passed.
Prepare the environment
Use disposable server data and two authorized Windows game clients. Follow the two-client procedure for the selected track. Keep license keys, account identifiers and tokens outside the evidence and repository. Do not change a public production server to perform these checks.
Record the exact server artifact, game build, Legacy or Enhanced track, example source commit, resource manifest and toolchain versions. For C#, compile against the selected track’s documented assemblies. The runtime lab targets Legacy/Mono; it must not be marked Enhanced-compatible without a reviewed port and a separate run. See Enhanced migration.
Run the acceptance cases
For each row, record pass, fail or not run. Include the steps, expected behavior, actual behavior and redacted client/server logs. A missing client or incompatible assembly is a blocked case, not a pass.
| Case | Action | Required observation |
|---|---|---|
| First resource: Lua | Follow the Lua first-resource guide; start, stop and restart it. | The documented command works once per action; restart produces no duplicate handler or relevant F8/server error. |
| First resource: JavaScript | Follow the JavaScript project, including its build and manifest. | The compiled resource loads in its intended runtime and the documented command works after restart. |
| First resource: C# | Follow the C# project for the intended track. | The assembly loads, the documented command works and logs contain no assembly/binding exception. |
| NUI completion | Use the NUI callbacks example; submit valid, empty and oversized input, then cancel. | Each request completes once; validation matches the guide and focus is released. |
| Resource lifecycle | Open the runtime-lab form, stop/restart the resource and repeat. | No stuck focus, stale response, duplicate listener or orphaned timer. |
| Secure events | Exercise the secure event procedure with valid, malformed, repeated and unauthorized requests. | The server rejects invalid requests without modifying authoritative state; valid work happens once. |
| Async disconnect | In the runtime lab, disconnect while a response is pending, then reconnect. | A delayed response is never delivered to a new session reusing an ID. |
| State bags | Follow the state-bag guide with clients A and B; change scope, reconnect and restart. | Authorized state reaches the intended observers; a client cannot overwrite server-authoritative state. |
| Entity ownership | Use the platform migration procedure; create with no nearby client, bring A into scope, then disconnect A. | Server creation and client simulation are recorded separately; owner-dependent setup recovers without duplicate creation. |
Use the runtime lab commands /fd_banner, /fd_timer, /fd_timer_cancel and
/fd_form as described in its guide. Grant its narrow docs.banner ACE only to
the development tester. Repeat /fd_banner without that grant and verify denial.
Revoke the temporary ACE and restore fixtures when finished.
Keep a reproducible result
Create one record per track and example revision:
Date:
Example source commit:
Track (Legacy / Enhanced):
Server artifact:
Game build:
Runtime / compiler / assembly versions:
Environment (isolated server, clients A/B):
Case:
Status (pass / fail / not run):
Steps:
Expected:
Observed:
Redacted evidence file:
Limitation or failure:
Cleanup completed:Keep failures and blocked cases visible. A successful Legacy run does not certify Enhanced, a same-machine run does not certify internet conditions, and a native signature check does not certify entity simulation. Re-run affected cases after changing the example, artifact, runtime target or ownership behavior.