Inventar- und Gewichtsoptimierung: Von items.lua zu Metadaten

Kurz zusammengefasst: Dieser Leitfaden bietet dir produktionsfertige Gewicht-/Slot-Voreinstellungen, Artikelbudgettabellen und kopierbare items.lua Definitionen (ESX/QBCore/ox_inventory) und sichere Migrationshandbücher zwischen beliebten Inventaren. Verwende es, um Überlastungsdrama zu eliminieren, Item-Bloat zu stoppen und deine Wirtschaft kohärent zu halten.

---

Warum Bestandsoptimierung wichtig ist

Eine stabile RP Wirtschaft hängt von Knappheit, Reibung und sinnvollen Entscheidungen ab. Inventarregeln (Slots, Gewicht, Stapelgrenzen, Metadaten wie Haltbarkeit/Seriennummern) sind die Hebel, die diese Entscheidungen real machen. Wenn jeder alles tragen kann, brechen die Preise zusammen und die Schleifen brechen. Stelle zuerst das Inventar ein, dann iteriere deine Preise, Auszahlungen und Senken. Für breitere Wirtschaftsthemen siehe unsere Säule: Gestaltung einer ausgewogenen GTA RP-Wirtschaft: Preise, Senken, Fortschritt.

---

Modelle: Steckplätze vs. Gewicht vs. Hybrid

Nur Slots

• Einfaches kognitives Modell; jedes Element = 1 Slot oder durch Größenklassen definiert.
• Schwach bei der Unterscheidung zwischen schweren und leichten Stapeln; Ausnutzung durch viele kleine, hochwertige Gegenstände.

Nur Gewicht

• Jeder Gegenstand hat ein Gewicht (normalerweise in Gramm). Spieler haben maxGewicht pro Behälter. Starker Realismus; benötigt durchdachte Standardeinstellungen.

Hybrid (empfohlen)

• Globale Gewichtsobergrenze Und Slot-Cap. Verhindert sowohl Micro-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., Wasser = 500 g) und runde Spielerobergrenzen (zB maxWeight = 120.000).

---

Standardvorgaben (kopieren und anpassen)

Unten sind kampferprobte Ausgangspunkte. Passe ±10–20% nach einer Woche Telemetrie in der Stadt an.

Spielerinventar (persönlich)

Serverskalierung	Modell	Max. Gewicht (g)	Spielautomaten	Hinweise
Neu/Klein (≤40 Einwohner)	Hybrid	80,000	30	Schnellere Einarbeitung; weniger anfängliche Schmerzpunkte.
Mittel (40–150)	Hybrid	120,000	35	Ausgewogen für allgemeines RP; gut für verschiedene Jobs.
Hoher Pop (150+)	Hybrid	150,000	32	Straffe die Schlitze, um Hamstern zu verhindern; halte das Gewicht fair.

Fahrzeuge (häufige Standardeinstellungen)

Container	Max. Gewicht (g)	Spielautomaten	Begründung
Handschuhfach	10,000	5	Kleiner Vorrat, fördert die Planung.
Limousinen Kofferraum	80,000	20	Basislinie.
Kofferraum eines SUV/Van	120,000	25	Nutzfahrzeuge gewinnen an Bedeutung.
LKW (Nutzfahrzeug)	180,000	28	Logistik-Gameplay.
Motorradlagerung	8,000	3	Minimale Taschenbildung.

Verstecke und Spezialbehälter

Typ	Max. Gewicht (g)	Spielautomaten	Hinweise
Hausversteck (Stufe 1/2/3)	120.000 / 180.000 / 240.000	40 / 60 / 80	Bietet Anreize für Wohnraumverbesserungen.
Job Locker	80,000	20	Verhindere Carryover-Exploits.
Beweismittelschrank	240,000	120	Komfort für Admin/LEO; Audit-Protokollierung erforderlich.

---

Artikelgewichtsbudgets (nach Klasse)

Verwende dies, um konsistente Gewichte zuzuweisen. Denke daran relative Reibung kein Realismus.

Klasse	Beispiele	Empfohlenes Gewicht (g)
Sehr leicht	Dietrichklinge, USB, SIM	5–50
Licht	Pistolenmunition (10), Verband, Snack	100–250
Medium	Wasserflasche, Burger, Reparaturset	400–800
Schwer	Gewehrmunitionskiste (30), Sauerstofftank, Materialkiste	1.500–4.000
Sehr schwer	Waffenkiste, Geldbeutel (markiert)	6.000–12.000

Munition: Haushalt pro Einheit für gepoolte Stapel (zB 9 mm = 15 g je → 30 Schuss ≈ 450g) oder als Kisten darstellen (zB 9mm Schachtel (30) = 500g).

---

Stapelgrößen und Slot-Strategie

• Rohstoffe (Lebensmittel, Medikamente): Staple 5–20, um die Langeweile zu reduzieren.
• Munition: Stapel 30–60 für Pistolen; 60–120 für Gewehre, wenn verpackt.
• Bastelmatten: stapel 100–250; halte das Gewicht sinnvoll.
• Waffen: Stapel = 1, eindeutige Metadaten (Seriennummer, Haltbarkeit).

---

Metadatenmuster (Haltbarkeit, Seriennummern, Anhänge, Qualität)

Designe Metadaten wie ein kleines Schema. Halte die Felder minimal, typisiert und validiert.

Kanonisches Metadatenschema (Empfehlung)

{
 "serial": "string", // eindeutige Waffen-ID
 "owner": "citizenid|identifier",
 "durability": 0.0, // 0.0–1.0; Abnutzung pro Nutzung/Zeit
 "quality": 100, // 0–100; Reparaturschwelle 25
 "ammo": 0, // Ganzzahl; Waffenmagazine
 "tint": 0, // Ganzzahl (Farbindex im Spiel)
 "attachments": ["flashlight", "scope"],
 "expiry": 0, // Unix-Zeitstempel; verderbliche Gegenstände
 "notes": "" // kurzer Text; Aufblähung vermeiden
}

Haltbarkeit und Verfall

• Waffen: Zerfall 0,5–1,5% pro Magazin; Ladehemmungswahrscheinlichkeit <5% unter 20%-Qualität.
• Werkzeuge (Dietriche, Bohrer): Verbraucht bei Verwendung %; bricht bei 0.
• Verderbliche Waren: Ablauf Kontrolle bei Verwendung; Strafe oder Sperre.

Sicherheit und Leistung

• Validiere die Metadaten serverseitig; vertraue niemals auf Client-Schreibvorgänge.
• Begrenze die Größe der Metadaten (z. B. <512 Bytes). Große Blobs beeinträchtigen das Speichern/Laden und die Netzwerk-Nutzlast.
• Verwende Aufzählungen für Anhänge und Tönungen.

---

Code: items.lua / Artikeldefinitionen nach Framework

ESX (es_extended) Beispiel

-- esx items.lua (Beispiel) — Gewicht in Gramm; negatives Gewicht bedeutet nicht gezählt in Legacy-Modi
['water'] = { label = 'Wasserflasche', weight = 500, stack = true, close = true, description = 'Bleibe hydriert.' },
['bandage'] = { label = 'Verbandsmittel', weight = 150, stack = true, close = true },
['lockpick'] = { label = 'Lockpick', weight = 50, stack = true, close = true },
['pistol_ammo'] = { label = 'Pistolenmunition (30)', weight = 450, stack = true, close = true, description = '9mm, Box mit 30.' },
['weapon_pistol'] = { label = 'Pistole', weight = 1500, stack = false, close = true, degrade = 0.01, unique = true },
,

Für ESX-Varianten, die noch verwenden Limit anstatt Gewicht, Satz Grenze = -1 (unbegrenzt) und schalte die Wirtschaftsbilanz global über das Gewicht um.

QBCore (geteilt/items.lua) Beispiel

-- qb-core gemeinsam/items.lua
['water'] = { name = 'water', label = 'Wasserflasche', weight = 500, type = 'item', image = 'water.png', unique = false, useable = true, shouldClose = true, description = 'Bleib hydriert.',
 combinable = nil },
['bandage'] = { name = 'bandage', label = 'Verband', weight = 150, type = 'item', image = 'bandage.png', unique = false, useable = true, shouldClose = true },
['lockpick'] = { name = 'lockpick', label = 'Dietrich', weight = 50, type = 'item', image = 'lockpick.png', unique = false, useable = true, shouldClose = true },
['pistol_ammo'] = { name = 'pistol_ammo', label = 'Pistolenmunition (30)', weight = 450, type = 'item', image = 'pistol_ammo.png', unique = false, useable = true, shouldClose = true },
['weapon_pistol'] = { name = 'weapon_pistol', label = 'Pistole', weight = 1500, type = 'weapon', image = 'weapon_pistol.png', unique = true, useable = false, shouldClose = true,
 info = { serial = '', durability = 1.0, ammo = 12, attachments = {} } },

ox_inventory (Daten/Elemente.lua) Beispiel

return {
 water = {
 label = 'Wasserflasche',
 weight = 500,
 stack = true,
 client = { status = { thirst = 25000 }, anim = { dict = 'mp_player_intdrink', clip = 'loop_bottle' } },
 },
 bandage = { label = 'Verband', weight = 150, stack = true },
 lockpick = { label = 'Dietrich', weight = 50, stack = true },
 pistol_ammo = { label = 'Pistolenmunition (30)', weight = 450, stack = true },
 weapon_pistol = {
 label = 'Pistole', weight = 1500, stack = false, allowArmed = true,
 consume = 0, -- handled by durability system
 ammo = { type = 'AMMO_PISTOL', count = 12 },
 metadata = { serial = true, durability = true, attachments = true },
 },
}

ox_inventory unterstützt reich Client/Server Verhaltensweisen in Artikeldefinitionen—bevorzuge eingebaute Funktionen gegenüber Ad-hoc-Skripten, um das Verhalten zu standardisieren.

---

Beispiele für hybride Durchsetzung

QBCore-Containerkonfiguration (Beispiel)

-- qb-inventory/server/config.lua (illustrative)
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 und umkehrbar)

Grundsätze

1. Zuerst einen Snapshot der Datenbank erstellen. 2) Elemente/Metadaten mit idempotenten Skripten migrieren. 3) Parallel auf einem Staging-Server ausführen. 4) Rollback-SQL bereitstellen.

A) qb-inventar → ox_inventory

Kartenfelder

• QB items.lua → ox data/items.lua (Name, Etikett, Gewicht, Stapel/einzigartig, Client-/Server-Verhalten).
• Spielerinventar Tabelle: konvertieren Info JSON → Metadaten (Seriennummer, Haltbarkeit, Munition).

Pseudocode (Lua/SQL-Mix)

-- 1) QB-Gegenstände in eine Lua-Tabelle/JSON exportieren
-- 2) ox items.lua-Einträge generieren
-- 3) Inventare umwandeln
for item in qb_inventory_rows do
 local meta = json.decode(item.info or '{}')
 local metadata = {
 serial = meta.serial,
 durability = meta.durability or 1.0,
 ammo = meta.ammo or 0,
 attachments = meta.attachments or {},
 }
 insert_into_ox_inventory(item.name, item.amount, metadata)
end

SQL-Beispiel (PostgreSQL/MySQL-Stil)

-- Sicherung
CREATE TABLE backup_playeritems AS SELECT * FROM playeritems;

-- Transformationsbeispiel für eine einzelne Gegenstandsfamilie
UPDATE playeritems
SET metadata = JSON_OBJECT(
 'serial', JSON_EXTRACT(info, '$.serial'),
 'durability', COALESCE(JSON_EXTRACT(info, '$.durability'), 1.0),
 'ammo', COALESCE(JSON_EXTRACT(info, '$.ammo'), 0),
 'attachments', COALESCE(JSON_EXTRACT(info, '$.attachments'), JSON_ARRAY())
)
WHERE name IN ('weapon_pistol','weapon_pistol_mk2');

Fallstricke

• Einzigartige Gegenstände: durchsetzen Stapel = falsch; stelle sicher, dass Duplikate nicht zusammengeführt werden.
• Munitionssysteme: Versöhnung der boxed vs. loose Ammo-Konventionen.
• Bilder/Symbole: Pfade von Elementbildern anpassen, um den Namenskonventionen von ox zu entsprechen.

B) ESX (limitbasiert) → Gewichtsmodell

1. Global festlegen useWeight = true in der Konfiguration (variiert je nach Fork).
2. Ersetzen pro Artikel Limit mit Gewicht (g). Für Artikel, die früher Grenze = -1, weise realistische Gewichte zu.
3. Migriere Stash/Fahrzeuglimits entsprechend.

Geskripteter Pass

for name, item in pairs(Items) do
 if item.limit and not item.weight then
 item.weight = estimateWeightFromClass(name)
 item.limit = nil
 end
end

C) qs-inventar / lj-inventar → QBCore/ox

• Die Feldzuordnung ist ähnlich wie bei QB: Info → Metadaten.
• Achte auf benutzerdefinierte Schlüssel (Qualität, Bild, erstellt am. Normalisiere auf das kanonische Schema.

---

Arbeitsablauf ausbalancieren (1-Wochen-Sprint)

1. Tag 0: Implementiere Voreinstellungen; migriere Elemente zur Budgettabelle.
2. Tag 1–2: Telemetrie erfassen: durchschnittliches Tragegewicht, verwendete Slots, Artikelverteilung nach Auftrag.
3. Tag 3: Ausreißer verkleinern (+5–10% Gewicht auf den 5 am stärksten gehorteten Artikeln).
4. Tag 4–5: Fahrzeugrollen: Nutzkofferräume verbessern; Handschuhfachmissbrauch abschwächen.
5. Tag 6: Verderbliche Waren: hinzufügen Ablauf für Verbrauchsmaterialien mit hoher Marge.
6. Tag 7: Patchnotizen veröffentlichen; eine zweiwöchige Überprüfung festlegen.

Minimale Telemetrie

• % Zeit belastet, Durchschnittlich genutzte Slots, Top 20 Artikel nach Anzahl und Gesamtgewicht, Perzentile der Vorratsnutzung.

---

QA-Checkliste (versandbereit)

• Alle Artikel haben Gewicht, Stapelund klare Beschriftungen.
• Waffen sind einzigartig/non‑stack und include seriell, Haltbarkeit.
• Container erzwingen beide Gewicht und Steckplätze (sofern unterstützt).
• Fahrzeugklassen entsprechen sinnvollen Kapazitäten.
• Stashes mit Fortschritt abgestuft.
• Migrationen gesichert; Rollback getestet.
• Metadatengröße begrenzt; serverseitig validiert.

---

Herunterladbare Vorlagen (inline)

Gewichtsbudget-CSV (in Google Tabellen kopieren)

Name, Etikett, Klasse, Gewicht_g, Stapel, Stapelgröße Wasser, Wasserflasche, Verbrauchsmaterial, 500, wahr, 10 Verband, Verband, medizinisch, 150, wahr, 5 Dietrich, Dietrich, Werkzeug, 50, wahr, 10 Pistolenmunition, Pistolenmunition (30), Munition, 450, wahr, 5 Waffe_Pistole, Pistole, Waffe, 1500, falsch, 1

Fahrzeugkapazitätstabelle (CSV)

Behälter, Gewicht_g, Steckplätze Handschuhfach, 10000,5 Limousinen-Kofferraum, 80000,20 SUV/Van-Kofferraum, 120000,25 LKW-Kofferraum, 180000,28 Motorrad, 8000,3

---

Häufige Fallstricke und Lösungen

• Spieler immer belastet → Reduziere die Top-3-ubiquitären Artikelgewichte um 15%; erhöhe die Spielergrenze um 10%.
• Endloses Horten von Mikroartikeln → Slot-Cap einführen; Mindestartikelgewicht festlegen (z. B. 25 g).
• Wirtschaftsinflation durch Hamsterkäufe → Verderbliche Waren hinzufügen Ablauf, Reibung beim Herstellungseingangsgewicht oder Lagergebühren.
• DB-Aufblähung → Metadatenschlüssel bereinigen; große vermeiden Anmerkungen Felder.

---

Nächste Schritte

• Wende die Hybrid-Voreinstellungen oben an, dann iteriere mit Telemetrie.
• Passe den Inventarwiderstand an Auszahlungen und Preisen an—siehe unser Wirtschaftsbeitrag für Spülen und Progressionsmodelle, die gut zu diesen Einstellungen passen.

Fragen zu einem bestimmten Framework-Fork oder einem benutzerdefinierten Inventar? Gib die Details an und ich passe die genauen Konfigurationen an.