> For the complete documentation index, see [llms.txt](https://corex-zombies.gitbook.io/corex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://corex-zombies.gitbook.io/corex-docs/start-here/add-a-resource.md).

# Add a resource

## 1. Read its installation contract <a href="#id-1-read-its-installation-contract" id="id-1-read-its-installation-contract"></a>

Use the script author's README and `fxmanifest.lua`. Record the framework/version, hard dependencies, SQL files, item definitions and any direct exports it calls.

| The script expects                                | CoreX provides                                                               |
| ------------------------------------------------- | ---------------------------------------------------------------------------- |
| `exports['qb-core']:GetCoreObject()`              | QBCore facade under the exact name `qb-core`                                 |
| `exports.qbx_core:...`                            | Supported Qbox exports under `qbx_core`                                      |
| `@es_extended/imports.lua` or `getSharedObject()` | ESX facade under `es_extended`                                               |
| `exports.ox_inventory:...` or `@ox_lib/init.lua`  | A dependency on the real resource, not an automatic alias to CoreX Inventory |

Do not change a script's framework to `corex` unless that script actually ships a CoreX integration. Keep its QBCore/Qbox/ESX option when using the matching facade.

## 2. Install one copy <a href="#id-2-install-one-copy" id="id-2-install-one-copy"></a>

Put the resource in a separate group such as `resources/[my-server]/`. Keep the exact folder name required by its manifest. Avoid nested folders such as `my_script-main/my_script/fxmanifest.lua`.

Install and start its actual companions before it. CoreX's named UI proxies cover specific APIs; they are not a complete replacement for `ox_lib`, `esx_lib`, target, phone, housing, banking or vehicle-key systems.

## 3. Add the required data <a href="#id-3-add-the-required-data" id="id-3-add-the-required-data"></a>

Follow [Add items](/corex-docs/start-here/add-items.md) for item definitions and [Database setup](/corex-docs/start-here/database.md) for SQL. These are separate operations. Adding an item definition does not create a shop, grant a license or import a vehicle database.

## 4. Start and exercise it <a href="#id-4-start-and-exercise-it" id="id-4-start-and-exercise-it"></a>

From the server console, run `refresh`, then `ensure` followed by the resource's exact name. Check the first error, not only the final “Started resource” line.

Test the normal player action end to end: item delivery, a full-inventory refusal, payment, UI completion/cancellation and reconnect. If the script grants rewards, verify the server checks eligibility and replay attempts. Compatibility does not make an unsafe third-party reward event safe.

## Target systems: what can you change? <a href="#target-systems" id="target-systems"></a>

There is no framework-wide setting that translates every target library. First identify the interaction you want to change:

| Interaction                                                         | Current implementation                                                                  | What changing it involves                                                                                 |
| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Native inventory shop NPCs                                          | CoreX's own client `AddTarget` interaction in `corex-core/client/cl_interact.lua`       | Change the native interaction or adapt the shop consumer; a target-library swap alone does not replace it |
| Portable-vehicle look-at pickup                                     | Direct `ox_target:addGlobalVehicle` call in `corex-inventory/client/rental_bicycle.lua` | Keep `ox_target`, or implement that consumer's equivalent against your chosen library                     |
| An external script using `qb-target`, `ox_target` or another target | That script's actual exports/configuration                                              | Use a provider it explicitly supports, with its required version and setup                                |

For a new **client-side** CoreX interaction, register an existing entity through the native export:

```lua
local registered = exports['corex-core']:AddTarget(existingPed, {
    text = 'Open my menu',
    icon = 'fa-hand-paper',
    distance = 2.5,
    callback = function()
        -- Open your menu here. Validate purchases/rewards separately on the server.
    end,
})
```

`existingPed` must be a valid entity you already created. `AddTarget` accepts a callback or a client event name plus `data`, and returns `false` when the entity or action is invalid. Use `exports['corex-core']:RemoveTarget(existingPed)` when your resource removes the interaction. This API is not an alias for the full QB/OX target API.

Missing `ox_target` disables the native portable-vehicle look-at option, not the whole inventory. Start it before Inventory when using that option. Changing the selected inventory through [Change inventory](/corex-docs/start-here/change-inventory.md) is a separate operation and does not translate target calls.

## Real examples <a href="#real-examples" id="real-examples"></a>

**`sm_hunting` (QBCore):** its included content pack registers `meat`, `leather` and `feathers`. The installed script's deer reward path has been exercised through the real QBCore facade and native inventory in the integration harness. The installed client has local compatibility fixes; it is not an unmodified-upstream gameplay certification.

**`qbx_binoculars` (Qbox):** start the real `ox_lib`, then the resource. Its pack adds `binoculars` and checks that the usable handler is actually registered. The handler was executed through the Qbox facade; rendering and GTA camera behavior still require a connected client.

**`esx_sit` (ESX):** the pinned normal server path uses ESX callbacks and has no SQL setup. Callback occupancy/release was tested. The resource's debug-only drawing helpers and in-game seating are separate checks.

For exact evidence and dependency limits, see [Compatibility](/corex-docs/start-here/compatibility.md).