es_extended
es_extended is the core resource of ESX Legacy. Learn how to get the ESX object, how the resource is structured and how a player loads, with links to every API.
es_extended is the core resource of ESX Legacy. It loads characters from the database, creates the server-side xPlayer object, manages money accounts, jobs, items, weapons and permissions, and exposes all of this through the shared ESX object that every other ESX resource uses.
Overview
| Fact | Value |
|---|---|
| Resource | es_extended |
| Version | ESX Legacy 1.16.4 |
| Side | Server, client and shared |
| Dependencies | oxmysql, esx_lib |
| Export | getSharedObject (and RunStaticPlayerMethod, used by ESX.Player) |
| Database tables | users, jobs, job_grades, items (plus owned_vehicles for extended vehicles) |
| License | GPL-3.0 |
Getting the ESX object
There are two supported ways. Pick one per resource.
Option 1: imports.lua (recommended)
fx_version "cerulean"
game "gta5"
lua54 "yes"
shared_script "@es_extended/imports.lua"
client_script "client/main.lua"
server_script "server/main.lua"imports.lua sets a global ESX and adds extras:
- On the client,
ESX.PlayerDataandESX.PlayerLoadedstay in sync automatically, and an optional globalOnPlayerData(key, value, last)function is called on changes. - On the server,
ESX.Player(source)andESX.ExtendedPlayers()return static players. ESX.require,ESX.loadandESX.loadJsonload modules and JSON files when ox_lib is not installed. See require.
Option 2: the export
ESX = exports["es_extended"]:getSharedObject()The export returns the ESX table at the moment you call it. Functions work normally, but data tables such as ESX.PlayerData on the client are not refreshed in your resource. Use getters like ESX.GetPlayerData() and ESX.GetJobs() instead.
Deprecated pattern
TriggerEvent("esx:getSharedObject", function(obj) ESX = obj end) still works in 1.16.4 for backwards compatibility. Do not use it in new code. See convert old ESX scripts.
Resource structure
| Path | Purpose |
|---|---|
shared/config/ | The only files you should edit. See config. logs.lua is loaded on the server only. |
shared/main.lua | Creates ESX and registers the getSharedObject export. |
shared/modules/ | Shared helpers: config access, weapons, validation, random strings, debug. |
shared/compat.lua | Maps ESX.Table, ESX.Math, ESX.SetTimeout and similar to their esx_lib versions. |
server/classes/ | The xPlayer class (split by topic) and the extended vehicle class. |
server/modules/ | Player sessions and saving, commands, callbacks, jobs, items, pickups, paychecks, OneSync helpers, Discord logging. |
server/bridge/ | Inventory bridges, currently ox_inventory. |
server/migration/ | Automatic database migrations that run on start. |
client/modules/ | Spawning, player data sync, adjustments, admin tools, death handling, UI wrappers. |
client/imports/ | Optional modules loaded by imports.lua on the client. |
locales/ | Translations, selected with the esx:locale convar. |
Server, client and shared
| Side | What you use | Reference |
|---|---|---|
| Server | ESX.GetPlayerFromId, ESX.RegisterCommand, ESX.RegisterServerCallback, ESX.CreateJob, ... | Server functions |
| Server | Player methods: money, items, job, metadata | xPlayer |
| Server | Entity spawning and area searches | OneSync |
| Client | ESX.PlayerData, notifications, ESX.TriggerServerCallback, game helpers | Client functions |
| Both | ESX.GetConfig, ESX.GetWeapon, ESX.Math, ESX.Table, timeouts | Shared functions |
Keep authority on the server. The client may ask, but the server checks distance, money, job and items before changing anything.
Player lifecycle
Connecting
The player joins. es_extended reads their identifier (Config.Identifier, default license). Without multicharacter, the character loads right away. With esx_multicharacter, it waits for the character selection.
Loading
The users row is loaded (or created with the starting money and items), the xPlayer is built and stored in ESX.Players. The server event esx:playerLoaded fires with playerId, xPlayer, isNew.
On the client
The client receives esx:playerLoaded with the player data, spawns the ped and sets ESX.PlayerLoaded = true. From now on events like esx:setJob and esx:setAccountMoney keep ESX.PlayerData in sync.
Playing
The character is saved every 10 minutes and paychecks run every Config.PaycheckInterval.
Leaving
On disconnect (or logout in multicharacter), esx:playerDropped fires with playerId, reason, the character is saved and removed from ESX.Players. On logout the client receives esx:onPlayerLogout.
AddEventHandler("esx:playerLoaded", function(playerId, xPlayer, isNew)
if isNew then
xPlayer.addInventoryItem("phone", 1)
end
end)
AddEventHandler("esx:playerDropped", function(playerId, reason)
print(("Player %s left: %s"):format(playerId, reason))
end)All events with their arguments: server events and client events.
Explore es_extended
xPlayer
Server functions
Client functions
Shared functions
PlayerData
Commands
Config
Events
Related
Frequently asked questions
Independent documentation
Last updated on
Tools for ESX Development
Useful tools for building and running an ESX Legacy server - VS Code extensions, database clients, txAdmin and community web tools for clothing, assets and merging.
PlayerData
What ESX Legacy stores about a character and where to read it. Every field of ESX.PlayerData on the client and the xPlayer object on the server, with types.