Migrate Inventory
One Inventory ships an in-game wizard that copies definitions (items, weapons, shops, stashes, ...) AND live inventory contents (player slots, vehicle storage, stashes) directly from your old inventory into ours. No SQL editing required.
Supported sources
More sources may be added later.
What the wizard imports
Definitions
- items
- weapons
- weapon components
- ammo types
- animations (e.g. eating, drinking)
- props (item-on-back models, world props)
- stash definitions (locations + restrictions)
- crafting benches (recipes + locations)
- shops (inventory + locations)
- licenses (purchase points)
- vehicle storage settings (per-class + per-model trunk / glovebox capacity, hood storage flag)
Live inventory contents
- player inventories (slots stay where they are; framework money becomes inventory items if you have "money as item" enabled)
- vehicle trunk inventories (keyed by plate)
- vehicle glovebox inventories (keyed by plate)
- stash inventories (keyed by name + owner)
Running a migration
Take a full SQL backup
Always.
Keep the old inventory STARTED
The wizard reads its data files and tables. It does not write to them. Players should not be actively using it during the migration window.
Start one_inventory
It will warn about the running old inventory; that's expected here.
Open the admin panel → Migration
The source adapter card shows the totals it detected (e.g. "1240 items, 87 weapons").
Run "Import definitions"
- Pick which definition categories to import.
- For stashes / crafting / shops that have BOTH marker coords AND target zones, choose per-row which to use (marker is picked by default; flip to target zone where needed).
- Confirm to run the import. Progress shows live in the hacker-console panel.
Run "Migrate inventory contents"
Choose which inventory pools to migrate (players / trunks / gloveboxes / stashes) and type MIGRATE to confirm.
Read the summary
You'll get a summary card per category showing imported / overwritten / failed counts.
Follow the post-migration card
- Remove the old inventory script folder from
resources/. - Move any missing item images into our
web/images/. The summary lists the exact filenames the importer couldn't find, with a Copy button. - Restart the server.
- Have players rejoin.
Conflict strategy
The wizard defaults to overwrite: any of our seeded definitions (or earlier imports) that share a name with an incoming entry are replaced. This is almost always what you want when coming from an existing live server.
Rows with conflicts are flagged in the wizard's data table; deselect any you want to keep as-is before running.
Server lock + restart requirement
- No one (including admins) can open ANY inventory until the server restarts.
- Inventory saves are suppressed in memory so disconnects and resource stops don't overwrite the freshly migrated rows with stale data.
- Every connected client sees a top-of-screen amber banner reminding them a restart is required.
Verification of migrated rows is done after the restart: open the admin panel data tabs, or spot-check via SQL.
Edge cases
Jobs / gangs / licenses on imported definitions
If a stash, shop, crafting bench, or license references a job that doesn't exist on your framework (e.g. an ox stash restricted to mechanic when you don't have that job), the definition still imports with the restriction set. It will simply never be accessible until you either create the job in your framework OR edit the definition in our admin panel to remove / change the restriction. Nothing crashes; it's just gated off.
Items missing when inventory contents migrate
If a player's inventory contains an item slug that doesn't exist in our items table (because you skipped that category during import, or the item name was renamed), the slot still migrates over but the item won't render in the inventory UI and won't be usable.
To recover: import the missing item definition (or create it manually with the same name) and restart. The slots become valid items again. The underlying data is preserved either way.
Animation / prop references on items and weapons
Items and weapons that reference animations or props (e.g. eating, drinking, holster animations) automatically resolve those references after the animations + props have been imported, regardless of which order you ticked the categories in the wizard.
If you skip importing animations / props but keep their referencing items, those items just import with no animation / prop attached (no error).
Shop items with per-item license restrictions
ox supports item.license on individual shop entries. Our shops use a single shop-wide license. The importer aggregates every distinct license seen across an ox shop's inventory into the shop's restrictedLicenses list, so the shop itself becomes gated. If that's too strict for your setup, edit the shop in the admin panel afterwards.
Shops with mixed currencies
ox shops can mix cash and black_money items in one shop; ours pick a single currency per shop. The importer picks the most common currency and drops items that don't match (each drop is logged in the server console). Recreate those items in a second shop if you need them.
Vehicles Storage = 3 (hood / frunk)
ox encodes hood storage as a magic number on a per-model entry. The importer translates that into our hoodStorage boolean. Some defaults (slots / weight) are intentionally filled from our schema defaults because ox computes them at runtime from the class, so re-tune any model you care about after the import.
Source database is read-only
We never DELETE or UPDATE the old inventory's tables. Everything is copied across. If the migration goes wrong you can simply remove our database tables, restart the old script, and you're back where you started.
Concurrency
Only one migration job can run at a time across all admins. A second admin trying to start one gets a clear error message; nothing corrupts.