Skip to content

Troubleshooting

Troubleshooting

Using the item does nothing

The bag has to be registered as a usable item before the placement mode can start.

  • On ox_inventory, the entry needs server = { export = 'bupa-weaponbag.useBag' }. Without it the inventory never tells the resource the item was used.
  • On QBox, QB-Core and ESX the resource registers the handler itself through the core; the item only needs useable = true. If it could not, the console prints "could not register the bag item automatically" and points you at the install/ folder.
  • Check that Config.Bag.Item matches the item name you actually added.

The bag disappears when I cancel the placement

That is ox_inventory consuming the item on use. Add consume = 0 to the item entry. The resource removes the item itself, but only once the bag has genuinely been put down.

"The bag model is missing on this server"

None of the models existed in your build. On start the resource prints which model it settled on, or lists everything it tried. Put a model you know exists in Config.Bag.Model, or set Model = false to pick from Config.Bag.ModelFallbacks.

I cannot place the bag here

The preview dims when the spot is refused. Placement needs ground under the preview, and is blocked while you are in a vehicle (Config.Bag.BlockInVehicle), in water (Config.Bag.BlockInWater), falling or ragdolled. If the bag also has to land within Config.MaxPlaceDistance of you — 6 m by default — and somehow does not, the server refuses it and hands the item back with its contents intact.

No third-eye option on the bag

Config.Target is 'auto' and detects ox_target, qb-target or qtarget from the started resource. If you run a renamed fork, name it explicitly. Both options are limited to Config.InteractDistance (2 m).

"This bag is not yours"

A bag belongs to whoever placed it. To widen access, turn on Config.Permissions.PublicAccess, add the player's job to Config.Permissions.InspectJobs, or grant the ACE with Config.Permissions.UseAce = true. Picking a bag up is judged separately — see AnyoneCanPickUp.

"You are too far away"

The server allows Config.InteractDistance plus Config.DistanceTolerance (2 m + 1.5 m by default). Raising the tolerance absorbs more lag, but also lets players drift away from the bag and keep using it.

"Empty the bag before picking it up"

Contents are stored in the bag item's own metadata, so this appears when Config.KeepWeaponMetadata is off, or when the detected inventory has no metadata support. An empty bag always picks up.

"That does not fit in this pocket"

The weapon's category is not in that pocket's accepts list. Check how it was categorised:

  • Config.CategoryOverrides wins over everything — put addon weapons there.
  • Otherwise the name is matched against Config.CategoryRules, top to bottom, first match wins.
  • A weapon matching nothing falls back to Config.DefaultCategory, or is refused outright if that is false.
  • Only items whose name begins with weapon_ (and ammunition) are ever offered to the bag at all.

The weapon picture is blank, or looks stuck on

  • Pictures come from your inventory's own image folder. On a renamed fork, set Config.UI.ImagePath.
  • A weapon squeezed into a sliver in the middle of a pocket is a missing ui.rotate on that pocket — see Pockets & Categories.

"The bag is full" or "cannot take any more weight"

Config.Capacity.MaxItems (10) and Config.Capacity.MaxWeight (30 kg) are both checked on the server. Item weights come from your own inventory, so the kilogram figure matches what players already see.

Placed bags vanished after a restart

They should not — bags live in the Config.Table table (bupa_weaponbags), which is created on first start, and are restored and rebroadcast when the server comes back up. Check that oxmysql starts before the resource and that the console shows no database errors.

Config.Debug prints the detected framework, inventory and bag model on start, how many bags were restored, and a line for every place, pickup, store and take. Turn it off once everything is working.