Running QB and ESX scripts

Many FiveM scripts are written for QB-Core, QBX or ESX. EndCore can run a lot of them without changes: en-core pretends to be those frameworks, answering their exports and player functions with EndCore's own data.

The bridges are a convenience, not a full emulation. Simple scripts (shops, jobs, small utilities) usually work. Scripts that lean on framework-specific systems EndCore doesn't have, such as gangs, societies or billing, need changes.

#How the bridges work

1. en-core declares provides { 'qb-core', 'qbx_core', 'es_extended' }, so a script whose manifest depends on qb-core passes the dependency check.
2. en-core answers exports under those resource names. exports['qb-core']:GetCoreObject() and exports['es_extended']:getSharedObject() both resolve to en-core, even though neither resource is installed.
3. The objects they return are backed by EndCore. A QB player object is the EndCore player, so Player.Functions.AddMoney is EndCore's AddMoney.

Each bridge only turns on if the real framework isn't running. When a bridge is active, the console prints a line such as:

[EndCore] qb-core compatibility bridge active

If the real resource is installed, the console prints qb-core is running; skipping its compatibility bridge instead.

#Before you add a script

• Remove the real framework. Don't run qb-core, qbx_core or es_extended alongside EndCore.
• Define its items in en-inventory. QBShared.Items is empty, and ESX item calls go through EndCore's inventory, so every item the script uses must exist in en-inventory/data/items.lua. See Add an item.
• Check its other dependencies. EndCore does not provide ox_lib, ox_inventory or ox_target, so scripts built on those won't run through the bridges.
• Start it after EndCore in server.cfg.

ensure en-ui
ensure en-core
ensure [encore]

# third-party scripts after EndCore
ensure some-qb-script

#QB-Core

A typical QB script keeps working:

local QBCore = exports['qb-core']:GetCoreObject()

RegisterNetEvent('some-script:payout', function()
    local Player = QBCore.Functions.GetPlayer(source)
    if not Player then return end
    Player.Functions.AddMoney('bank', 200, 'qb-script payout')
end)

#What works

#Gangs become groups

EndCore has no gangs. Its player groups stand in: PlayerData.gang is filled from the player's group.

Functions.SetGang exists so scripts don't crash, but it does nothing and returns false.

#QBX

Many of QBX's other exports are not provided, such as setting jobs or adding money by source, or its group helpers. Scripts that call them fail on that call.

#ESX

local ESX = exports['es_extended']:getSharedObject()

RegisterNetEvent('some-script:reward', function()
    local xPlayer = ESX.GetPlayerFromId(source)
    if not xPlayer then return end
    xPlayer.addAccountMoney('money', 50)   -- 'money' is EndCore cash
    xPlayer.addInventoryItem('bandage', 1)
end)

#What works

ESX.RegisterCommand groups other than user become group.<name> principals, and player arguments are converted to xPlayer objects.

#Known limits

#Usable items and consumption

QB CreateUseableItem and ESX RegisterUsableItem both route to encore.inventory.registerUsable. en-inventory only consumes an item if the handler returns true. QB and ESX handlers normally remove the item themselves and return nothing, so they won't be double-charged.

#Porting a script properly

Bridges are a good way to try a script. For scripts you plan to keep, porting to the EndCore API is worth it: you get the survival stats, groups, content registry and design system, and nothing depends on bridge coverage. Common swaps:

See Writing a resource. If you have a large script library to move over, Fxora takes porting and custom development work.

#Turning the bridges off

If you run only EndCore-native resources, you can switch all three bridges off. Add this to server.cfg above ensure en-core:

setr encore:disablebridge true

Use setr, not set. The client-side bridges read the convar too, and only setr replicates it to players.

With the bridges off, exports['qb-core'], exports['qbx_core'] and exports['es_extended'] calls fail, so any remaining framework script stops working. The global QBShared table is still defined, because the QB shared file always loads.

#Related

• Compatibility bridges: the full reference.
• Core overview and Player API: the native EndCore API.