Set inventory limits around the activities players need to complete: ordinary supplies, a job’s equipment and a meaningful choice about extra cargo. Weight, slots and item metadata solve different problems, so inspect your actual inventory resource before changing values.
Identify the inventory implementation
Record the inventory resource/version, its framework integration and where it defines items, player capacity, vehicle storage and stashes. ESX, QBCore and Qbox do not imply one universal inventory format. Use the installed source or the inventory author’s documentation.
Back up configuration and stored inventories. Test changes on a separate instance; lowering capacity can leave existing containers over their new limit.
Understand the three limits
Weight limits total carried mass using the resource’s units. Slots limit distinct stacks. Stacking rules determine whether identical names with different metadata can share a slot. A container can run out of slots while still having spare weight.
Use the same unit consistently. If your inventory uses grams, an item weighing 500 and a capacity of 20,000 represent 0.5 kg and 20 kg. Those numbers are an illustration, not a recommended server preset.
Build a representative loadout
List what a new player needs for a normal session, then repeat for each job. Calculate quantity × item weight and the required stack slots. Include ammunition, tools and consumables. Test the loadout in game rather than relying on a spreadsheet alone.
Choose vehicle and stash capacities by their intended purpose. A utility vehicle can support logistics without forcing every player to carry an entire warehouse. Server population alone does not determine a sensible carrying capacity.
Edit the resource that owns the setting
In QBCore setups, shared item definitions and the inventory’s container limits may live in different resources. In ox_inventory, ordinary item definitions and weapon definitions are separate concerns. Follow the actual file structure for your installed release.
Do not copy a generic PlayerMaxWeight, useWeight or stash function into a file unless that resource reads it. Search the source for the key and its use. Preserve existing item names and behavior while changing the intended limit.
Preserve metadata
Serial numbers, durability, ammunition and attachments are implementation-specific. Verify ranges and field names before any conversion; a durability scale from 0 to 1 is not interchangeable with 0 to 100. Preserve unique items separately and report unknown fields rather than dropping them.
An inventory migration needs a versioned converter for the exact source and target schema, with counts and metadata compared before and after. Do not run generic SQL against guessed player-item tables.
Test capacity and persistence
- Add and remove a known quantity; confirm the displayed and enforced weight agree.
- Fill slots with distinct stacks, then test a matching stack and an item with different metadata.
- Test transfers between player, vehicle and stash when either destination is full. Confirm failure neither loses nor duplicates items.
- Reconnect and restart the test server. Check quantities, ownership and metadata.
- Test an existing container above the proposed new capacity and decide how players can recover without item deletion.
Roll out understandable changes
Explain changed limits and give players a route to reorganize existing storage. Watch rejected transfers, frequently carried items and player feedback. Adjust the specific bottleneck instead of repeatedly increasing every capacity.
Reference documentation
Source: qbcore-fivem/qb-inventory · Source: overextended/ox_inventory