Inventar & Gewicht optimieren: Von items.lua bis Metadaten
Schritt-für-Schritt-Tutorial zur Inventar- und Gewichtsoptimierung in FiveM. Enthält idempotente Skripte, fertige Presets und Migrationsleitfäden. Vollständiger Guide für 2026.
Einführung: TL;DR – Dieser Guide liefert produktionsreife Einstellungen
TL;DR: Dieser Guide liefert dir produktionsreife Gewichts-/Slot-Presets, Item-Budget-Tabellen, copy-paste-fertige items.lua-Definitionen (ESX/QBCore/ox_inventory) und sichere Migrations-Playbooks zwischen gängigen Inventaren. Nutze ihn, um Überlastungs-Drama zu eliminieren, Item-Bloat zu stoppen und deine Wirtschaft kohärent zu halten.
Dieser Guide ist Teil unserer umfassenden FiveM-Skripte-Ressource, wo du alle unsere Skriptempfehlungen, Framework-Vergleiche und Kaufratgeber findest.
Warum Inventar-Tuning wichtig ist
Eine stabile RP-Wirtschaft hängt von Knappheit, Reibung und bedeutungsvollen Entscheidungen ab. Inventarregeln (Slots, Gewicht, Stack-Limits, Metadaten wie Haltbarkeit/Seriennummern) sind die Hebel, die diese Entscheidungen real machen. Wenn jeder alles tragen kann, brechen Preise ein und Loops funktionieren nicht mehr. Optimiere zuerst das Inventar, dann iteriere Preise, Auszahlungen und Sinks. Für eine breitere Wirtschaftsperspektive, siehe unser Pillar: Designing a Balanced GTA RP Economy: Prices, Sinks, Progression.
Modelle: Slots vs. Gewicht vs. Hybrid
Nur Slots
- Einfaches kognitives Modell; jedes Item = 1 Slot oder definiert durch Größenklassen.
- Schwach bei der Unterscheidung schwerer vs. leichter Stacks; Exploits durch viele kleine hochwertige Items.
Nur Gewicht
- Jedes Item hat ein Gewicht (üblicherweise Gramm). Spieler haben
maxWeightpro Container. Starker Realismus; braucht durchdachte Standardwerte.
Hybrid (empfohlen)
- Globale Gewichtsgrenze und Slot-Grenze. Verhindert sowohl Mikro-Item- als auch Mega-Item-Exploits. Funktioniert am besten für RP.
Tipp: Halte Zahlen menschenlesbar. Wenn du in Gramm modellierst, verwende ganze Zahlen (z.B.
water = 500g) und runde Spielergrenzen (z.B.maxWeight = 120.000).
Standard-Presets (kopieren & anpassen)
Unten sind battle-tested Ausgangspunkte. Passe ±10–20 % nach einer Woche In-City-Telemetrie an.
Spieler-Inventar (am Körper)
Server-Größe
Modell
Max. Gewicht (g)
Slots
Hinweise
Neu/Klein (≤40 Pop)
Hybrid
80.000
30
Schnelleres Onboarding; weniger frühe Frustrationspunkte.
Mittel (40–150)
Hybrid
120.000
35
Ausgewogen für allgemeines RP; gut für diverse Jobs.
Groß (150+)
Hybrid
150.000
32
Slots straffen, um Horten zu begrenzen; Gewicht fair halten.
Fahrzeuge (häufige Standardwerte)
Container
Max. Gewicht (g)
Slots
Begründung
Handschuhfach
10.000
5
Kleiner Stauraum, fördert Planung.
Limousinen-Kofferraum
80.000
20
Basiswert.
SUV/Van-Kofferraum
120.000
25
Nutzfahrzeuge werden bedeutungsvoll.
LKW (Nutzfahrzeug)
180.000
28
Logistik-Gameplay.
Motorrad-Stauraum
8.000
3
Minimales Pocketing.
Stashes & spezielle Container
Typ
Max. Gewicht (g)
Slots
Hinweise
Haus-Stash (Stufe 1/2/3)
120k / 180k / 240k
40 / 60 / 80
Anreize für Wohnungs-Upgrades.
Job-Spind
80.000
20
Übertragungs-Exploits verhindern.
Beweismittelkammer
240.000
120
Admin/LEO-Komfort; Audit-Logging erforderlich.
Item-Gewichtsbudgets (nach Klasse)
Verwende dies, um konsistente Gewichte zuzuweisen. Denke in relativer Reibung, nicht in Realismus.
Klasse
Beispiele
Empfohlenes Gewicht (g)
Sehr leicht
Dietrich-Klinge, USB, SIM
5–50
Leicht
Pistolenammo (10), Verband, Snack
100–250
Mittel
Wasserflasche, Burger, Reparatur-Kit
400–800
Schwer
Gewehrammo-Box (30), Sauerstoffflasche, Materialkiste
1.500–4.000
Sehr schwer
Waffenkiste, Geldtasche (markiert)
6.000–12.000
Ammo: Budget pro Einheit für gepoolte Stacks (z.B.
9mm = 15gpro Stück → 30 Schuss ≈ 450g) oder als Boxen repräsentieren (z.B.9mm-Box (30) = 500g).
Stack-Größen & Slot-Strategie
- Verbrauchsgüter (Essen, Medizin): Stack 5–20, um Monotonie zu reduzieren.
- Ammo: Stack 30–60 für Pistolen; 60–120 für Gewehre wenn gebündelt.
- Crafting-Materialien: Stack 100–250; Gewicht bedeutungsvoll halten.
- Waffen:
stack = 1, einzigartige Metadaten (Seriennummer, Haltbarkeit).
Metadaten-Muster (Haltbarkeit, Seriennummern, Attachments, Qualität)
Entwirf Metadaten wie ein kleines Schema. Halte Felder minimal, typisiert und validiert.
Kanonisches Metadaten-Schema (Empfehlung)
{
"serial": "string", // Waffen-Eindeutige-ID "owner": "citizenid|identifier", "durability": 0.0, // 0.0–1.0; Verfall pro Nutzung/Zeit "quality": 100, // 0–100; reparierbare Schwelle 25 "ammo": 0, // Ganzzahl; Waffenmagazine "tint": 0, // Ganzzahl (Spiel-Tint-Index) "attachments": ["flashlight", "scope"], "expiry": 0, // Unix-Timestamp; verderbliche Items "notes": "" // kleiner Text; Bloat vermeiden
}
Haltbarkeit & Verfall
- Waffen: Verfall 0,5–1,5 % pro Magazin; Klemm-Chance <5 % unter 20 % Qualität.
- Werkzeuge (Dietriche, Bohrer): % bei Nutzung verbrauchen; bei 0 kaputt.
- Verderbliches:
expiry-Prüfung bei Nutzung; abgelaufene Strafe oder Blockade.
Sicherheit & Performance
- Metadaten server-seitig validieren; Client-Schreibvorgänge niemals vertrauen.
- Metadaten-Größe begrenzen (z.B. <512 Bytes). Große Blobs verlangsamen Speichern/Laden und Netzwerk-Payloads.
- Enumerationen für Attachments und Tints verwenden.
Code: items.lua / Item-Definitionen nach Framework
ESX (es_extended) Beispiel
-- esx items.lua (Beispiel) — Gewicht in Gramm; negatives Gewicht bedeutet nicht gezählt in Legacy-Modi
['water'] = { label = 'Water Bottle', weight = 500, stack = true, close = true, description = 'Stay hydrated.' }, ['bandage'] = { label = 'Bandage', weight = 150, stack = true, close = true }, ['lockpick'] = { label = 'Lockpick', weight = 50, stack = true, close = true }, ['pistol_ammo'] = { label = 'Pistol Ammo (30)', weight = 450, stack = true, close = true, description = '9mm, Box mit 30.' }, ['weapon_pistol'] = { label = 'Pistol', weight = 1500, stack = false, close = true, degrade = 0.01, unique = true },
Für ESX-Varianten, die noch limit statt weight verwenden, setze
limit = -1(unbegrenzt) und schalte das Wirtschaftsgleichgewicht global über Gewicht um.
QBCore (shared/items.lua) Beispiel
-- qb-core shared/items.lua
['water'] = { name = 'water', label = 'Water Bottle', weight = 500, type = 'item', image = 'water.png', unique = false, useable = true, shouldClose = true, description = 'Stay hydrated.', combinable = nil }, ['bandage'] = { name = 'bandage', label = 'Bandage', weight = 150, type = 'item', image = 'bandage.png', unique = false, useable = true, shouldClose = true }, ['lockpick'] = { name = 'lockpick', label = 'Lockpick', weight = 50, type = 'item', image = 'lockpick.png', unique = false, useable = true, shouldClose = true }, ['pistol_ammo'] = { name = 'pistol_ammo', label = 'Pistol Ammo (30)', weight = 450, type = 'item', image = 'pistol_ammo.png', unique = false, useable = true, shouldClose = true }, ['weapon_pistol'] = { name = 'weapon_pistol', label = 'Pistol', weight = 1500, type = 'weapon', image = 'weapon_pistol.png', unique = true, useable = false, shouldClose = true,
info = { serial = '', durability = 1.0, ammo = 12, attachments = {} } },
ox_inventory (data/items.lua) Beispiel
return {
water = { lua
label = 'Water Bottle',
weight = 500,
stack = true,
client = { status = { thirst = 25000 }, anim = { dict = 'mp_player_intdrink', clip = 'loop_bottle' } },
},
bandage = { label = 'Bandage', weight = 150, stack = true },
lockpick = { label = 'Lockpick', weight = 50, stack = true },
pistol\_ammo = { label = 'Pistol Ammo (30)', weight = 450, stack = true },
weapon\_pistol = { ```lua
label = 'Pistol', weight = 1500, stack = false, allowArmed = true,
consume = 0, -- wird durch Haltbarkeitssystem behandelt
ammo = { type = 'AMMO_PISTOL', count = 12 },
metadata = { serial = true, durability = true, attachments = true },
},
}
ox_inventory unterstützt umfangreiche
client/server-Verhaltensweisen in Item-Definitionen – bevorzuge Eingebautes gegenüber Ad-hoc-Skripten, um das Verhalten zu standardisieren.
Hybrid-Durchsetzungs-Beispiele
QBCore Container-Konfiguration (Beispiel)
-- qb-inventory/server/config.lua (illustrativ)
Config.PlayerMaxWeight = 120000
Config.PlayerMaxSlots = 35
Config.Vehicle = {
glovebox = { weight = 10000, slots = 5 }, trunk = function(class)
if class == 'sedan' then return 80000, 20 end
if class == 'suv' or class == 'van' then return 120000, 25 end
if class == 'truck' then return 180000, 28 end
return 60000, 18
end
}
ox_inventory Stash-Setup (Beispiel)
-- ox_inventory/server/custom/stashes.lua
lib.addstash('house_tier1', 40, 120000) lib.addstash('house_tier2', 60, 180000) lib.addstash('house_tier3', 80, 240000)
Migrations-Playbooks (sicher & reversibel)
Prinzipien
- Zuerst DB-Snapshot. 2) Items/Metadaten mit idempotenten Skripten migrieren. 3) Parallel auf einem Staging-Server laufen. 4) Rollback-SQL bereitstellen.
A)
qb-inventory→ox_inventoryFelder zuordnen
QB items.lua→ox data/items.lua(name,label,weight,stack/unique,client/server-Verhaltensweisen).player inventory-Tabelle:infoJSON →metadata(serial, durability, ammo) konvertieren.B) ESX (limit-basiert) → Gewichtsmodell
- Globale
useWeight = truein der Konfiguration setzen (variiert je nach Fork).- Pro-Item
limitdurchweight(g) ersetzen.- Stash/Fahrzeug-Grenzen entsprechend migrieren.
C)
qs-inventory/lj-inventory→ QBCore/ox
- Feldzuordnung ist ähnlich wie QB:
info→metadata.- Auf benutzerdefinierte Schlüssel achten (
quality,image,createdAt). Zum kanonischen Schema normalisieren.
Balancing-Workflow (1-Wochen-Sprint)
- Tag 0: Presets implementieren; Items auf Budget-Tabelle migrieren.
- Tag 1–2: Telemetrie erfassen: durchschnittliches Tragegewicht, verwendete Slots, Item-Verteilung nach Job.
- Tag 3: Ausreißer straffen (+5–10 % Gewicht bei den Top 5 gehorteten Items).
- Tag 4–5: Fahrzeugrollen: Nutzfahrzeug-Kofferräume aufwerten; Handschuhfach-Missbrauch eindämmen.
- Tag 6: Verderbliches:
expiryfür hochwertige Verbrauchsgüter hinzufügen. - Tag 7: Patch-Notes veröffentlichen; zweiwöchige Review festlegen.
Minimale Telemetrie
% Zeit überlastet,Durchschnittlich genutzte Slots, Top 20 Items nach Anzahl und Gesamtgewicht, Stash-Auslastungs-Perzentile.
QA-Checkliste (versandbereit)
- Alle Items haben
weight,stackund klare Labels. - Waffen sind
unique/nicht-stackbar und enthaltenserial,durability. - Container erzwingen sowohl Gewicht als auch Slots (wo unterstützt).
- Fahrzeugklassen entsprechen sinnvollen Kapazitäten.
- Stashes gestaffelt mit Progression.
- Migrationen gesichert; Rollback getestet.
- Metadaten-Größe begrenzt; server-seitig validiert.
Herunterladbare Vorlagen (inline)
Gewichtsbudget-CSV (in Google Sheets kopieren)
name,label,class,weight_g,stack,stack_size water,Water Bottle,consumable,500,true,10 bandage,Bandage,medical,150,true,5 lockpick,Lockpick,tool,50,true,10 pistol_ammo,Pistol Ammo (30),ammo,450,true,5 weapon_pistol,Pistol,weapon,1500,false,1
Fahrzeugkapazitäts-Tabelle (CSV)
container,weight_g,slots Glovebox,10000,5 Sedan Trunk,80000,20 SUV/Van Trunk,120000,25 Truck Trunk,180000,28 Motorcycle,8000,3
Häufige Fallstricke & Lösungen
- Spieler immer überlastet → Gewicht der Top 3 allgegenwärtigen Items um 15 % reduzieren; Spielergrenze um 10 % erhöhen.
- Endloses Horten von Mikro-Items → Slot-Grenze einführen; Mindest-Item-Gewicht setzen (z.B. 25g).
- Wirtschaftsinflation durch Vorratshaltung →
expiryfür Verderbliches hinzufügen, Crafting-Input-Gewichtsreibung oder Stash-Gebühren. - DB-Bloat → Metadaten-Schlüssel bereinigen; große
notes-Felder vermeiden.
Nächste Schritte
- Die Hybrid-Presets oben einführen, dann mit Telemetrie iterieren.
- Inventarreibung mit Auszahlungen und Preisen abstimmen – siehe unser Wirtschafts-Post für Sinks und Progressionsmodelle, die gut zu diesen Einstellungen passen.
Hast du Fragen zu einem spezifischen Framework-Fork oder einem benutzerdefinierten Inventar? Nenn die Details und ich passe die genauen Konfigurationen an.
