Getting Started
Install, start, and verify sure-es_extended from the current resource structure.
Getting Started
This page covers the current bootstrap and first-run expectations observed in the sure-es_extended resource.
If you are wiring this resource into a fresh server, focus on dependency order, the settings review, and the database check first. Those three areas shape most early startup issues.
Dependencies
oxmysqlox_lib
- state bags
- OneSync-related entity helpers
- server callbacks routed through
ox_lib - NUI for the notification application
Resource entrypoints
Shared
shared/main.luashared/imports.luaimports.lua
Client
client/main.lua- all client modules loaded from
client/functions.lua,client/modules/, andclient/classes/
Server
server/main.luaserver/common.luaserver/classes/player/init.lua- method files under
server/classes/player/methods/ - supporting modules under
server/functions.lua,server/modules/, andserver/classes/
UI
ui_page 'nui/dist/index.html'
The built NUI output in nui/dist/ is what the game loads at runtime.
Startup behavior
At startup, the server boot flow performs a predictable sequence:
Load configuration
The framework reads its runtime behavior from settings/ before the main services come online.
Build the shared object
The shared ESX object is created and extended by shared, server, and client bootstrap code.
Prepare persistence and caches
Database-related state is initialized, then jobs and items are loaded into runtime memory.
Register services
Callbacks, commands, and compatibility helpers are registered so other resources can safely interact with the framework.
Accept player joins
Once the runtime is prepared, the resource can start loading player records and constructing ExtendedPlayer instances.
On the client side, startup loads ESX modules, waits for player state to become available, and wires UI, callback, spawn, and gameplay helpers.
Recommended start order
Start oxmysql
Persistence must be available before the framework tries to read or write player state.
Start ox_lib
Callback routing and other shared utilities depend on it.
Start es_extended
This resource should come online before anything that expects the shared ESX object.
Start dependent resources
Gameplay and integration resources that rely on ESX helpers or lifecycle events should load afterward.
First configuration review
Before running this fork in a real server environment, review:
settings/public.luasettings/locale.luasettings/ui.luasettings/adjustments.luasettings/weapons.luasettings/weapon-tints.luasettings/addons/optimize.lua
The Configuration page explains each file in detail.
Database bootstrap note
Database note
The codebase includes both SQL assets and runtime schema creation logic. One important implementation detail is that startup code references a users_test table in bootstrap checks, while persistence and the provided SQL file are centered around users.
Treat this as an observed implementation detail that you verify in your environment before production rollout.
See Database for the full persistence discussion.
Compatibility import surface
The fork still exposes the shared object export expected by older integrations:
ESX = exports['es_extended']:getSharedObject()That export is defined in shared/main.lua.
For player access, this fork also keeps compatibility helpers through imports.lua, documented in Architecture and Server API.
Verification checklist
Support path
This docs site is now the primary written reference for the fork. For operational troubleshooting, pair it with direct inspection of the resource logs and the live database schema in your server environment.