Skip to content

13. Starter items

Config.StarterItems — what a brand new character is holding the first time it spawns. It runs once, on the first load of a character this resource created; selecting an existing character never gives anything.

One block per framework, and only the block for the framework this server is running is read:

Config.StarterItems = {
esx = { enabled = true, items = "auto" },
qbcore = { enabled = true, items = "auto" },
qbox = { enabled = true, items = "auto" },
}
Option Notes
enabled false and this resource gives nothing on that framework, whatever items says. On esx that is only this resource’s half — es_extended still writes its own Config.StartingInventoryItems into the row itself, so empty that too
items "auto", or a list
Value Behaviour
"auto" Leave the list where that framework already keeps it, so editing it there is enough
A table Replaces that framework’s list entirely

Under "auto":

Framework Where the list comes from
qbox qbx_core/config/shared.luastarterItems
qbcore QBCore.Shared.StarterItems
esx Config.StartingInventoryItems in es_extended — ESX writes it into the users row as the character is inserted, so it has already happened and nothing extra is given

Both list forms are accepted:

items = { { name = "phone", amount = 1 }, { name = "id_card", amount = 1 } }
items = { phone = 1, id_card = 1 }

The inventory underneath is worked out at runtime, so ox_inventory, qb-inventory and the ESX default all work without being named. metadata on an entry is passed straight to ox_inventory, and is used as the info table on qb-inventory — where id_card and driver_license still get the character’s name and date of birth filled in on top. On the ESX default inventory a weapon_ name is given as a weapon, with amount as its ammo.

Older configs kept one list at Config.QB.starterItems, QB and Qbox only. That key is still read when your framework’s block has no items, so an old config.lua keeps working — but this section replaces it.