> For the complete documentation index, see [llms.txt](https://atiysus-organization.gitbook.io/aty-scripts/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atiysus-organization.gitbook.io/aty-scripts/inventory/getting-started/installation.md).

# Installation

## Installation

#### 1. Dependencies first

`aty_inventory` declares exactly one hard dependency: **`aty_lib`**. That is the bridge that tells it which framework it is running on. Install and start it before this resource.

You also need a MySQL wrapper — `oxmysql`, `mysql-async` or `ghmattimysql`. Any of the three works; the resource detects which one is present.

#### 2. Drop the resource in

Extract to your resources folder and add it to `server.cfg`:

```cfg
ensure aty_lib
ensure aty_inventory
```

{% hint style="warning" %}
`aty_lib` must start **before** `aty_inventory`. If your `server.cfg` uses a folder-wide `ensure [aty]`, list `aty_lib` explicitly first — a resource that loads before its bridge cannot resolve the framework and falls back to standalone.
{% endhint %}

#### 3. The database

**There is no import step.** The resource applies its own schema at boot, every start, idempotently — seven tables, created if missing and left alone if not.

`sql/schema.sql` ships for DBAs who want to review or pre-create the two core tables by hand. Running it is optional.

See Database for what each table holds.

#### 4. Remove the old inventory — and take over its name

Two inventories cannot both own the inventory keys and the item API, so the old one has to stop. What is easy to miss is the second half: every other script on your server calls the inventory **by resource name**, and stopping the old resource takes that name with it.

So the old resource stops and a small proxy from `compat/` starts in its place, under the same name. Which one depends on your framework:

| Framework                      | Stop this                           | Start this instead    |
| ------------------------------ | ----------------------------------- | --------------------- |
| **Qbox** (`qbx_core`)          | `ox_inventory` — it ships with Qbox | `compat/ox_inventory` |
| **qb-core**                    | `qb-inventory`                      | `compat/qb-inventory` |
| **ESX** with ox\_inventory     | `ox_inventory`                      | `compat/ox_inventory` |
| **ESX**, no inventory resource | nothing                             | nothing               |
| **Standalone**                 | nothing                             | nothing               |

{% hint style="danger" %}
On **Qbox this step is not optional**. Qbox ships `ox_inventory` and its own core calls it by name, so leaving it installed means your server keeps using it: `aty_inventory` starts, appears in the loading screen, and F2 still opens the old inventory. Two folders cannot share the name either — if the console says `ox_inventory exists in more than one place` at startup, one of them has to go.

Qbox also reads the item list while its core starts, so `ensure aty_inventory` must come **before** `ensure qbx_core`.
{% endhint %}

Full detail, including what the proxy does and does not forward: Compatibility.

#### 5. Verify

Start the server and run this in the console:

```
invdoctor
```

It checks the install end to end — database reachable, framework detected, items loaded, images present, name collisions, config sanity — and prints each problem with the command that fixes it. A clean install reports **0 problems**.

{% hint style="success" %}
`invdoctor` is the single command to run after any change to config, items or dependencies. It changes nothing — the one file it writes is the list of items with no picture, `data/missing-images.txt` — and is safe on a live server.
{% endhint %}

#### Next

* Dependencies — what each one is for and what breaks without it
* Configuration — the settings you actually need to touch
* Database — schema, growth and retention