Test a FiveM resource with two clients

Two clients expose replication bugs that a one-player test cannot show. They are still running on one machine and may share account identifiers. Use an isolated development server, a disposable database and test data; never use the extra instance to simulate an independent paying player or to test grants against a production economy.

Prepare a reproducible session

Record the client track, game build, server artifact, resource revision and the test server address. Ensure the machine has spare CPU, GPU and memory for both clients. A background window can behave differently from the focused window; this setup is not a fair performance benchmark or a substitute for a second physical machine on another network.

Start only the required resources. Give the clients distinct temporary labels in your test notes, such as A and B, but do not assume they receive distinct permanent account/license identifiers. For account-dependent flows, use explicitly isolated test fixtures or separately authorized accounts. Do not turn off authentication or grant production admin permissions to work around shared identity.

Legacy: primary instance first, then -cl2

Create two shortcuts to the same verified FiveM executable. Leave A unchanged and add -cl2 to B, outside the quoted executable path. Start A and wait for it to load before starting B. Connect both to the development server and confirm the server sees two active sessions. See shortcut setup for quoting and rollback.

If B only focuses A, verify the correct shortcut and the supported client track. If a framework rejects the second account/session, do not defeat its production safeguards: use a separate test environment or a second authorized account/machine appropriate to that framework.

Enhanced: development mode and Debug action

The current Enhanced instructions replace the old -cl2 recipe. In the isolated development server’s configuration, add:


sv_devMode true

Restart that development server, connect the Enhanced client, open F8, and use Debug → Launch Additional Client. Confirm the additional client joins the same intended environment. This flag enables development behavior; it is not a setting to add casually to a public production server. Remove it or restore its previous value and restart after the test.

The official two-client guide and Enhanced changes define the track-specific procedure. Missing Debug controls should send you back to the track, artifact and dev-mode checks—not to an unsupported command-line bypass.

A useful acceptance matrix

Action	Observe on A	Observe on B and the server
Trigger one resource action on A	One response, no duplicate input	Only the intended replicated effect; server decides authorization.
Move out of range, then return	Local streamed entity may disappear and return	Persistent server state remains coherent; no duplicate ownership record.
Disconnect A while an async request is pending	No requirement for a final response to a disconnected client	No delayed reply delivered to a later session reusing A’s ID.
Restart the resource while its NUI is open	Owned focus is released or recovered	No stale UI subscriptions, timers or duplicate events.
Move A to another routing bucket	Expected scoped game state	B does not receive unrelated instance state; entities are assigned deliberately.
Rejoin after a state change	Current authoritative state is fetched	No reward replay or second initialization side effect.

The runtime lab provides a request correlation/session-reuse example. The OneSync guide and state bags explain the replication primitives; opening two clients does not make an unsafe client event authoritative.

End the test

Close B and A, restore the normal shortcut/configuration, disable the temporary Enhanced dev mode, remove test permissions and reset disposable data. Record pass/fail observations and errors with identifiers redacted. If only one machine was tested, say so: a same-machine pass does not certify internet latency, packet loss, independent identities or production load.