FiveM load order: why a script can start and still find nothing

The symptom

The resource starts. The console shows it as started. Then nothing happens: the menu never opens, the keybind does nothing, the chat command answers with silence.

This is usually not a broken script. It is a script that asked for something that was not there yet.

start and ensure are not the same

start qb-core
ensure my_housing_script

start starts a resource once, and errors when the resource is not found. ensure starts a stopped resource, or restarts one that is already running.

Both lines run in the order they appear, but only within the configuration block they live in. If a framework is started in one exec file and your scripts in another, the order between the two files is the order of the exec lines — and it is easy to get wrong without noticing.

The dependency list protects only what it lists

A resource with

dependencies { 'qb-core' }

waits for qb-core before it starts. That is a real guarantee, and it is the best fix for load-order bugs.

It is not a general guarantee. If your code calls an export of a resource you did not list, nothing waits for anything. The call returns nil, and in Lua that nil usually travels further than you expect: it becomes a missing field, then a failed if, then a UI that silently never renders.

List every resource whose API you call: ox_lib, your voice library, your map library, the notification library. If you call it, it is a dependency.

The usual order

A configuration that survives contact with a real server looks roughly like this:

1. Framework and database driver.
2. Shared libraries.
3. Resources that only extend the framework — jobs, housing, inventory add-ons.
4. Your own gameplay resources.

The RPScripts server.cfg Builder & Checker can review an existing configuration or generate an annotated starter. It runs in the browser.

Disclosure: this post is from RPScripts. The tool linked above is ours and free to use.

When the order is right and it still fails

Two more causes with the same shape:

OneSync. With OneSync enabled, networked entities, state bags and server-side natives behave differently than in single-player. A resource that expects a client-side entity will start fine and do nothing.

Restart-only success. If it works after a manual ensure but not after a cold start, the order is wrong. A resource that depends on state held by another resource must be restarted after that resource, not merely started once.

A short checklist

• The console shows the framework as started before the resources that use it.
• Every resource whose API you call is in your dependencies list.
• ensure and start are used with intent, not interchangeably.
• The same order works after a full server restart, not only after a manual start.
• The first red line in the console is read before anything is changed.