Convert FiveM scripts between QBCore, ESX and Qbox

What the converter does

The converter lives in ScriptForge's Convert mode. Attach the resource as a .zip — or paste a single file — pick the framework it is written for and the one you want, and see the price before you start. A single file and a whole resource are priced differently, but a whole resource is one charge however many files it has.

A whole resource is converted in one pass, so the files stay consistent with each other: event names still match between client and server, fxmanifest.lua dependencies and imports switch to the new framework, every config key another file reads is still defined, and money and item calls change the same way in every file.

A port, not a rewrite

The goal is the same script on another framework, not a new one. Every conversion is given the same rules. They are instructions to the model, not a promise, so compare the result with your original:

• It is told to keep every check the source makes — job, grade, on-duty, money and items, distance, cooldowns, input validation — and to add no new gameplay restriction.
• Notifications go to the same players with the same text, and keep their type (QBCore primary = ESX info = Qbox inform).
• An on-duty check is never dropped: QBCore's job.onduty becomes job.onDuty ~= false on ESX.
• The resource's own event names stay as they are; only framework events change, such as QBCore:Client:OnPlayerLoaded to esx:playerLoaded.
• SQL files pass through unchanged. Job grade definitions switch between string keys (QBCore), number keys (Qbox) and ESX's job_grades table.

Your files stay yours

A zip is unpacked in your browser and only the source files are sent for conversion. Images, sounds and fonts never leave your computer; when the manifest lists them, the README names them under "Files From Your Original Resource" so you copy them into the converted folder. The converted code then goes through the same automatic checks as a new build — Lua 5.4 compile, FiveM security rules, manifest and NUI wiring — with one correction pass when something fails, and a conversion that does not come out complete is not charged.

Example: what changes in a purchase handler

A Convert-mode request: attach the zip, pick From ESX and To QBCore, and add a note if you like:

“My server uses ox_target too, keep the counter on it.”

Part of a resource you might convert — the start of an ESX purchase handler that ScriptForge wrote:

ESX.RegisterServerCallback('coffee_counter:buy', function(source, cb)
    local src = source
    local xPlayer = ESX.GetPlayerFromId(src)
    if not xPlayer then return cb({ ok = false, code = 'failed' }) end
    -- … cooldown lines skipped …
        if not nearCounter(src) then code = 'too_far'; break end

        local price = Config.Price
        local cash = xPlayer.getMoney()
        if cash < price then code = 'not_enough_cash'; break end
        if not xPlayer.canCarryItem(Config.Item, 1) then code = 'cannot_carry'; break end
    -- … the rest of the purchase skipped …

On QBCore and Qbox the handler keeps its distance check, its cooldown and its order of checks; the framework calls change. The table below lists the equivalents conversions use, checked against each framework's source.

The same operation in each framework

Frequently asked questions