Dependencies & Compatibility
The matrix
| Resource | What it is for | |
|---|---|---|
ox_lib | required | menus, notifications, callbacks, the locale system |
oxmysql | required | courts, placed props, map removals, profiles, career stats and teams |
ox_target | optional | the referee, ball cart and cool box prompts. Without it, walk up and press E |
ox_inventory | optional | the volleyball item and the three drinks |
| Framework | not needed | ESX, QBCore, Qbox or none; it behaves identically |
Start oxmysql and ox_lib before vs-volleyball.
Why the database is required
Everything the script remembers is in it: the courts you build, the props and peds placed on them, the map objects removed to make room, player profiles, career stats and the leaderboard, and teams with their rosters and banners.
There is nothing to import. The script creates its own tables on first boot. install.sql in the resource root is the same schema written out for a backup, a restore or a migration.
Without oxmysql the resource starts, prints that it cannot reach a database, and then refuses every save. It is not a soft dependency.
Why ox_target is optional
Every in-world interaction (the referee desk, the ball cart, the cool box) is defined once and rendered by whichever front end exists: a target option when ox_target is running, a proximity E prompt when it is not. Neither is the fallback, and the feature is identical either way. ox_target is deliberately not in the resource manifest's dependencies, so it never becomes a hard requirement for a server that does not run it.
Why ox_inventory is optional, with one exception
Without an inventory you lose exactly two things: the volleyball item, and the beach circle that using it opens. Matches, training, courts, teams and the leaderboard are untouched; the cool box is simply scenery.
For the beach circle, ox_inventory is a hard requirement: the one exception to how the rest of the resource degrades. Using an item is the entry point, and a server with no inventory has no item to use.
The four item rows are in inventory/ox_inventory_items.lua, ready to paste, and the four icons are in inventory/images/ to copy into ox_inventory/web/images/. See Beach circle & drinks.
Why no framework is needed
There is nothing to bridge. A volleyball match has no payouts, no job grades and no character data; it is a court, some players and a ball. The only money in the resource is the price of a can of pop, and that transaction is ox_inventory's own shop, not ours.
So it runs unchanged on ESX, QBCore, Qbox, a custom framework, or no framework at all. The one place a framework is read, if you have one, is the admin check: Config.Admin.groups can name ESX/QB groups as an alternative to the ace.
Assets
Everything ships inside the resource. Nothing goes in your stream folder and no .meta is edited.
| Asset | |
|---|---|
| Court floors | Six models: 1v1, 2v2 and 3v3, each in sand or concrete |
| Net and poles | wx_volleyball_net · wx_volleyball_poles |
| Ball | prop_beach_volball02 |
| Ball cart | wx_volleyball_props_utilitycart |
| Animations | wx_volleyball_anims: custom mocap |
| Audio | dlc_wxvolley/volleyball_sounds: 21 waves, with its own dat54 |
The beach circle's inflatable ball and the cool box are stock GTA props.
Other scripts
There is no interference to configure. The script owns nothing global: no keys are stolen (every binding is a real FiveM key mapping, rebindable in Settings → Key Bindings → FiveM), no HUD is replaced, and nothing runs at all until a player is at a court or in a ring.
The one place it touches your map is removing world objects to clear space for a court, which is explicit, admin-only, reversible, and never edits a .ymap. See Courts & the builder.