Skip to main content
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) 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

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

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 adds the export it asks for. Nothing else on this list needs an edit.

​
Database

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

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

​
On-screen help text

Built-in fallback.

​
Progress bars

Built-in fallback.

​
Fuel

Built-in fallback, which reports the vehicle’s own fuel level. No fallback. A product that opens a menu through your menu resource does not start without one of these.

​
Text 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:
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:
    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:
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:
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.