Inventar & Gewicht optimieren: Von items.lua bis Metadaten

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 maxWeight pro 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 = 15g pro 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 unter 5 % bei 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. unter 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 = {
    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 = {
    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

1. 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_inventory

Felder zuordnen

• QB items.lua → ox data/items.lua (name, label, weight, stack/unique, client/server-Verhaltensweisen).
• player inventory-Tabelle: info JSON → metadata (serial, durability, ammo) konvertieren.

B) ESX (limit-basiert) → Gewichtsmodell

1. Globale useWeight = true in der Konfiguration setzen (variiert je nach Fork).
2. Pro-Item limit durch weight (g) ersetzen.
3. 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)

1. Tag 0: Presets implementieren; Items auf Budget-Tabelle migrieren.
2. Tag 1–2: Telemetrie erfassen: durchschnittliches Tragegewicht, verwendete Slots, Item-Verteilung nach Job.
3. Tag 3: Ausreißer straffen (+5–10 % Gewicht bei den Top 5 gehorteten Items).
4. Tag 4–5: Fahrzeugrollen: Nutzfahrzeug-Kofferräume aufwerten; Handschuhfach-Missbrauch eindämmen.
5. Tag 6: Verderbliches: expiry für hochwertige Verbrauchsgüter hinzufügen.
6. 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, stack und klare Labels.
• Waffen sind unique/nicht-stackbar und enthalten serial, 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 → expiry fü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.