DEV Community: RPScripts

Debug a FiveM resource in three passes: configuration, code, then runtime

RPScripts — Thu, 22 Oct 2026 15:49:17 +0000

A resource can have valid Lua and still fail on a FiveM server. The server might not have discovered its folder, a dependency might be missing, or the code might expect a framework API your installation does not provide.

Treat these as separate checks. It makes the next change easier to choose and the result easier to explain.

Disclosure: this post is from RPScripts. The two browser tools linked below are ours and free to use. You can also follow the workflow manually.

Pass 1: Check what the server is being asked to start

Before editing code, write down the resource's exact folder name, required framework, dependencies and installation instructions. Compare that list with the resources actually installed on your test server.

Look for an accidental extra directory level after extracting a ZIP. The resource folder should contain its manifest; a download folder containing another folder containing the manifest deserves a closer look. Check path casing when moving files between Windows and Linux.

Read the active configuration, including any files it loads. Keep dependencies ahead of the resources that use them, according to the resource author's instructions. A line in server.cfg does not install a framework or create database tables.

The RPScripts server.cfg Builder & Checker can help review an existing configuration or create an annotated starter. It runs in the browser. A clean report cannot confirm that your resource files, database or license are correct; those still need a local check. Use placeholders when sharing configuration for support.

Pass 2: Inspect the resource before loading it into your server

Separate syntax problems from integration problems. A parser can identify malformed Lua, but it cannot establish that a database exists or that a particular vehicle appears correctly in the game.

For each resource, check:

Does the manifest reference the scripts and UI files you actually shipped?
Are client scripts and server scripts assigned to the intended side?
Do required dependency names match the installed folders?
Does an integration call an API supported by your installed framework version?
Does server code validate permissions and derive important values itself, rather than trusting values supplied by a client?

The RPScripts FiveM Script Tester accepts a resource ZIP, a Lua file or pasted code. Its static checks and CfxLua sandbox run in the browser. The separate "Open in RPScripts AI" action sends files to your account, so distinguish that optional action from the local checks.

Read the scope of the result. Simulated frameworks and events help isolate some failures, but game-world natives, OneSync and real database behaviour still require a real server. A successful simulation is one piece of evidence, not a deployment certificate.

Pass 3: Run one controlled test on a staging server

Back up the resource and configuration first. Use a staging server with the dependencies and framework version you intend to deploy.

The official Cfx server-command reference distinguishes these operations:

refresh rescans resource manifests so newly added resources can be discovered.
start resource_name starts a stopped resource.
ensure resource_name starts a stopped resource or restarts one that is already running.

That last distinction matters when other resources depend on state held by the resource you restart. Use a controlled maintenance or staging workflow instead of repeatedly issuing commands on a busy server.

Capture the first relevant server-console error and the corresponding client F8 output. Reproduce one action, change one cause, and repeat the same action. If it works, restart the staging server and test again: success after a manual start does not establish that a cold start has the right order.

Keep a short test record

Record the artifact version, framework and dependency versions, the action you tried, the result and the relevant log lines. Redact credentials before sharing anything.

Configuration checks answer whether the setup looks consistent. Resource checks answer what the code and simulation reveal. A staging test answers what happens in your actual environment. Keeping all three results makes support requests clearer and future updates easier to verify.

Your FiveM resource won't load? Check these fxmanifest.lua fields first

RPScripts — Thu, 22 Oct 2026 15:38:51 +0000

Every FiveM server owner has seen it: ensure my_resource prints Could not find resource, or the resource starts and then does nothing. Before you touch a single line of Lua, check the manifest — most of these failures live there, and the console error rarely points at the actual line.

These are the six things I check first, in this order.

1. `fx_version` is missing or misspelled

fx_version 'cerulean'
game 'gta5'

No fx_version, no resource. It is not optional, it is not inferred, and a typo (fx_verison) gives you the same generic failure as a missing file. cerulean is the current value; older manifests use adamant or bodacious and still load, but there is no reason to start a new resource on a retired version.

2. The `game` line is absent

Without game 'gta5' the resource may load and then behave strangely: natives resolve, entities spawn, and nothing works the way it does in every tutorial you followed. Cheap to check, expensive to debug.

3. Path casing in `client_scripts` and `server_scripts`

The classic "works on my machine". You develop on Windows, where client/Client.lua and client/client.lua are the same file, and deploy to a Linux host where they are two different paths and only one exists.

client_scripts {
    'client/main.lua',   -- must match the real filename exactly
    'client/ui.lua'
}

Same rule for shared_scripts, files and server_scripts. If a resource loads but one feature silently never runs, suspect casing before logic.

4. `lua54` is still in the manifest

lua54 'yes'

This flag does nothing today — every FiveM Lua script runs on Lua 5.4 and the manifest documentation marks the opt-in as deprecated. It is not the bug itself, it is a fossil: a manifest nobody has revisited. Where it shows up, look for the neighbours of an old setup — a __resource.lua that was renamed instead of converted, node_version values that no longer exist, or code that still assumes Lua 5.3 number semantics.

5. `dependencies` instead of hoping for the best

dependencies {
    'ox_lib',
    'oxmysql'
}

Without it, your resource starts in whatever order server.cfg happens to load, and every call into a dependency that has not started yet throws at runtime. Declaring dependencies makes FiveM refuse the start with a clear message instead of letting you debug a nil export at 2 a.m.

Two gotchas: the name must match the dependency's folder, not its display name, and an optional integration should not be listed — declare only what the resource cannot run without.

6. `escrow_ignore` when the resource is sold

If the resource is protected with escrow, any file a customer is supposed to edit — config.lua, locale files, framework bridges — has to be listed in escrow_ignore. Miss one and the customer edits a file that never executes, reports a bug, and nobody can reproduce it because the developer's own copy is unencrypted.

The two-minute pre-flight

Before every restart:

fxmanifest.lua sits at the resource root, and is not secretly fxmanifest.lua.txt.
fx_version and game are present and spelled correctly.
Every path in client_scripts, server_scripts, shared_scripts and files exists with exact casing.
A glob in files matches at least one file — an empty glob is silent.
Dependencies are declared by folder name, not assumed.
Escrow-protected resources list every editable file.

I got tired of checking this by hand, so I wrote a dependency-free linter that reads manifest syntax as text and never executes Lua: fivem-fxmanifest-lint. Python 3.10+, no third-party packages, no network access, non-zero exit code for CI.

For a quick check in the browser without cloning anything, there is a hosted fxmanifest.lua validator and generator.

Either way: fix the manifest first. Most of the time, the Lua was fine.