> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elementlabs.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Supported server resources

> Which frameworks, inventories, databases and interface resources Element Labs products work with.

Element Labs products do not replace the resources your server already runs. When a product needs a
player's identity, an inventory, a database or a notification on screen, it uses the resource you
already have. This page lists exactly which resources are recognised.

## Contract

A product looks at the resources running on your server and picks one for each capability it needs.
The choice is made once, the first time the product uses that capability, from a fixed order: the
first recognised resource that is running at that moment wins.

You configure nothing. Installing a supported resource is all that is required, and installing two
of them means the one higher in the list is used.

A declared implementation (a resource that names itself for a capability, as described on
[A provider of your own](/sdk/custom-provider)) wins over the list above. The list is used when
nothing is declared.

A product only looks for the capabilities it actually uses. A product that never shows a
notification does not care whether you have a notification resource.

## Inputs

The tables below list resource names exactly as they appear in your `resources` directory, in the
order they are checked.

### Framework

| Order | Resource      | Framework |
| ----- | ------------- | --------- |
| 1     | `es_extended` | ESX       |
| 2     | `qb-core`     | QBCore    |
| 3     | `qbx_core`    | Qbox      |

**Opt-in fallback on the client.** By default a product that needs a framework does not start without
one of these. A product that only needs the player's state on the client — loaded, alive, a name —
may choose to run without a framework: its installation page says so, and it calls the SDK's opt-in
method itself. On such a product, the account name stands in for the character name, and job, gang
and money read as empty. A product that needs framework data **on the server** still does not start
without one of these: the server side has no fallback.

### Inventory

| Order | Resource           |
| ----- | ------------------ |
| 1     | `ox_inventory`     |
| 2     | `qb-inventory`     |
| 3     | `qs-inventory`     |
| 4     | `origen_inventory` |
| 5     | `core_inventory`   |
| 6     | `tgiann-inventory` |

**No fallback.** A product that moves items does not start without one of these.

`qb-inventory` has no hook for watching items move between inventories. A product that needs one
reports it and stops; [the qb-inventory swap hook](/sdk/qb-inventory-swap-hook) adds the export it
asks for. Nothing else on this list needs an edit.

### Database

| Order | Resource      |
| ----- | ------------- |
| 1     | `oxmysql`     |
| 2     | `mysql-async` |

**No fallback.** A product that stores data does not start without one of these. Products that store
nothing do not need a database at all.

### Notifications

| Order | Resource      |
| ----- | ------------- |
| 1     | `ox_lib`      |
| 2     | `qb-core`     |
| 3     | `es_extended` |

**Built-in fallback.** With none of these running, notifications are drawn by the product itself.

### On-screen help text

| Order | Resource     |
| ----- | ------------ |
| 1     | `ox_lib`     |
| 2     | `esx_textui` |

**Built-in fallback.**

### Progress bars

| Order | Resource      |
| ----- | ------------- |
| 1     | `ox_lib`      |
| 2     | `progressbar` |

**Built-in fallback.**

### Fuel

| Order | Resource     |
| ----- | ------------ |
| 1     | `LegacyFuel` |
| 2     | `ox_fuel`    |
| 3     | `cdn-fuel`   |
| 4     | `ps-fuel`    |

**Built-in fallback**, which reports the vehicle's own fuel level.

### Menus

| Order | Resource  |
| ----- | --------- |
| 1     | `ox_lib`  |
| 2     | `qb-menu` |

**No fallback.** A product that opens a menu through your menu resource does not start without one
of these.

### Text input

| Order | Resource   |
| ----- | ---------- |
| 1     | `ox_lib`   |
| 2     | `qb-input` |

**No fallback.**

## Outputs

The selection is made the first time a product uses the capability, from the resources running at
that moment. For most capabilities that is at or shortly after start.

Two consequences:

* Your `server.cfg` order does not have to put these resources before Element Labs products. A
  product started first still picks up a framework, inventory or database that starts after it, as
  long as it has not used that capability yet.
* The choice is made once. Starting a second supported resource, or replacing one, after a product
  has used the capability does not change that product's choice. Restart the product.

## Errors

When a product needs a capability on the server, or a client capability that has no fallback, and
finds no recognised resource, it reports one line naming what it looked for:

```text theme={null}
[ERROR] [FrameworkAdapter] No supported Framework adapter detected. Checked: [es_extended, qb-core, qbx_core]
```

The same shape applies to the other capabilities, with their own resource lists. Install one of the
listed resources and restart, or check the product's installation page to confirm the product suits
your server at all.

For the framework line specifically, it means one of two things: the product needed framework data
on the server, or it is a client-only product that chose not to run without a framework. A product
that is happy without one, such as the map, opts in itself and never prints it.

The line appears when the product first uses the capability, not necessarily at start: a product may
run for a while before it needs your inventory for the first time. A product that never uses a
capability never looks for it and never reports it.

What happens next depends on which side of the server needed it, and it is worth knowing which line you
are reading:

* **A server capability**: `Framework`, `Inventory`, `Database`. The product stops. It finishes
  starting first, because a resource cannot stop itself: it asks the SDK, which stops it on its next
  tick. So the console reports the resource started and then stopped, and the end state is `stopped`
  rather than running without something it needs.
* **A client capability**: `Menu`, `Text input`, `Targeting`. Stopping a resource is a server
  operation, so the line appears in the affected player's own console (`F8`) followed by:

  ```text theme={null}
  [ERROR] [MenuAdapter] 'Menu' is unavailable for the rest of this session; the server side of 'element_map' stops the resource when it needs the same capability.
  ```

  The product keeps running and anything that uses that capability fails where it is used. Install one
  of the listed resources: this state is a missing prerequisite, not a mode the product supports.

In both cases the report is a single line. Older releases raised an error instead, which stopped one
script and left the rest loading, so the console filled with unrelated failures underneath the line that
explained them.

## Example

To confirm which resource a product chose, turn on debug output in `server.cfg`:

```cfg theme={null}
setr el:debug "true"
```

Restart, and each choice is reported once, as the product first uses that capability, so the lines
appear as the product does its work, not all at start:

```text theme={null}
[DEBUG] [FrameworkAdapter] Using "esx" adapter.
[DEBUG] [DatabaseAdapter] Using "oxmysql" adapter.
[DEBUG] [NotifyAdapter] Using "standalone" adapter.
```

`standalone` means no recognised resource was found and the built-in fallback is in use. Turn debug
output off again when you are done. See [Server settings](/sdk/server-settings).

## Related

* [Server requirements](/getting-started/requirements)
* [Server settings](/sdk/server-settings)
* [A product does not start](/support/product-will-not-start)