![Day[Z] Titan Launcher logo](/assets/img/logo2.webp?v=1781090027){kind=logo}
Day[Z] Titan Launcher
Wenn du je eine DayZ-Server-Config geöffnet und ohne Erklärung Tags, Entries, Types, Events und Protos in einem Discord um dich geworfen gesehen hast, ist dieser Guide für dich. Wir gehen die zentralen Economy-XML-Dateien nacheinander durch, kurz und klar, damit du siehst, wie sie zusammenhängen und wo du etwas änderst, wenn du deinen Loot oder deine Zombies „boosten“ willst. Bewusst ein Überblick für Einsteiger - gerade genug, damit die großen Zusammenhänge einrasten.
Arbeite sie der Reihe nach durch. Jede Datei hat eine Aufgabe, und der Trick ist zu sehen, wie ein Name in einer Datei zu einem Namen in einer anderen passt - dieses Passen ist es, was Loot und Events tatsächlich in der Welt erscheinen lässt.
Bevor du irgendetwas anfasst, kläre die Begriffe: Tags, Entries, Types, Events und Protos. Diese fünf Begriffe tauchen ständig auf und sind der ganze Grund, warum die Dateien anfangs verwirrend wirken. Jeder lebt in einer bestimmten Datei und bezieht sich auf eine bestimmte Sache; sobald du sie benennen kannst, folgst du jedem Tutorial oder Discord-Thread, ohne den Faden zu verlieren.
Das Denkmodell, das alles andere einrasten lässt: Die DayZ Central Economy ist ein riesiges Spiel von „Fangen“. Ein in einer Datei definierter Name wird von einem Namen in einer anderen referenziert, und wenn die Namen übereinstimmen, spawnt etwas. Behalte das im Kopf, während du jede Datei unten liest - du lernst meist nur, wo ein Name geboren wird und wo er verwendet wird.
Jeder Eintrag in der types.xml ruft einen Class Name auf. Er heißt Class Name, weil die Spielskripte das Item nach Klasse erstellen - der Eintrag teilt der Economy nur mit, dass diese Klasse existiert und wie sie sich verhalten soll. Diese Datei öffnen die meisten zuerst, wenn sie ändern wollen, wie viel von etwas spawnt.
Die beiden Werte, mit denen die Economy am meisten arbeitet, sind nominal und min: nominal ist die Zielmenge, die die Economy in der Welt halten will, min ist die Untergrenze, die neuen Spawn auslöst. lifetime ist, wie lange in Sekunden das Item vor dem Cleanup bestehen bleibt. quantmin und quantmax legen fest, wie voll ein Item beim Spawnen ist - bei einer Feldflasche etwa irgendwo zwischen null und hundert Prozent.
Um ein Item zu „boosten“, erhöhst du meist nominal und min. Das allein sagt der Economy, mehr davon in der Welt am Leben zu halten, ohne eine andere Datei anzufassen.
All deine Tags, Usage-Flags und Kategorien werden in der cfglimitsdefinition.xml „geboren“. Das ist ihre Definitionsdatei: sobald ein Name hier existiert, erkennt ihn das Spiel in jeder anderen Datei. Diese Namen setzt du dann auf einen types-Eintrag, um festzulegen, wo und wie das Item erscheinen darf.
Usage-Werte sind Dinge wie Military, Medic, Police, Firefighter, Industrial, Farm, Coast, Town, Village, Hunting, Office, School, Prison und Lunapark. Die Kategorien und Tier-Flags (Tier eins bis Tier vier, Area-Flags usw.) liegen ebenfalls hier. Dem Spiel ist es völlig egal, wie du sie nennst - du könntest eine Usage „hostess snack cake“ nennen, und es würde funktionieren, solange der exakte Name später korrekt auf einen Item-Eintrag gesetzt ist.
Wo landen die Type-Einträge also in der Welt? Ein Proto ist die Antwort. Ein Proto benennt ein Item - etwa einen Garbage Pile - und du taggst dieses Item mit den Usage- und Kategorie-Namen, die du in deiner Limits-Datei definiert hast. Das Proto trägt zudem Koordinaten für einzelne Loot-Punkte, die um einen Mittelpunkt des Items gemappt sind.
Ein Proto-Name kann beliebig sein. Wichtig ist der nächste Schritt: dieser Name muss anderswo zu einem Positions-Namen passen - das sehen wir gleich an. Für sich ist ein Proto nur eine Definition, die sagt: „dieses Objekt hält so getaggten Loot“.
Die mapgrouppos.xml hält die Positionen. Solange ein Proto-Name (ein Mapping) zu einem Pos-Namen (einer Position) passt, steht dieses Proto an dieser Position und hält den Loot, der für seine passenden Usages getaggt ist. Das ist das „Fangen“ in Aktion: das Proto ist der Fänger und der Pos der Ort, an dem es steht.
Einfach gesagt: das Proto sagt „ich bin ein Garbage Pile, der Town- und Village-Loot hält“, und der passende Pos sagt „stell diesen Garbage Pile hierhin“. Sind beide Namen identisch, erscheint Loot an dieser Stelle; vertippst du dich bei einem, spawnt nichts. Von hier an folgt alles, was in Events verwendet wird, derselben Abgleich-Logik.
events.xml und cfgeventspawns.xml gehören genauso zusammen wie Proto und Pos. Ein Event hat einen Namen, und dieser Name trägt ein Präfix: Item, Static oder Vehicle. Der passende Event-Spawn-Name listet die Kartenpositionen, an denen das benannte Event existieren darf.
Innerhalb eines Events legst du minimum, maximum und nominal-Ausgabe fest, dazu einen Radius, in dem sich die gespawnten Objekte (oder Zombies) bewegen dürfen, und die Children - die tatsächlichen Dinge, die das Event ausgibt. Drei weitere Felder steuern das Verhalten: safe radius ist, wie nah an einem Spieler das Event spawnen darf, distance, wie weit es von einem anderen Event entfernt sein muss, und cleanup, wie weit du dich entfernen musst, bis es deaktiviert.
Wenn das Child selbst das Limit ist, wird die Ausgabe zwischen dem eigenen minimum und maximum jedes Childs zusammen mit dem übergreifenden nominal gesteuert - ein separates event-weites minimum oder maximum ist nicht nötig.
Ein Event mit Vehicle-Präfix funktioniert genauso - der Event-Name passt zu einem Event-Spawn-Namen, also geht das Event an diese Positionen. Das Neue ist der „a=“-Wert, die Richtung, in die das Fahrzeug zeigt. Die Motorhaube zeigt entlang dieses Winkels: 0 oder 360 ist Norden, 180 ist Süden, und mit etwas Kopfrechnen kommst du auf jede Richtung im Kreis.
Vehicle-Events nutzen meist ein „mixed“-Limit. Statt jedes gelistete Child an jeder exakten Position zu erzwingen (was Autos auftürmen würde), sagst du der Economy, die Gesamtzahl in einem min und max um das nominal zu halten - zum Beispiel insgesamt 11 bis 15 Fahrzeuge, Ziel etwa 13, mit höchstens ein bis drei je Child-Typ im Mix.
Der Rest verhält sich wie bei jedem Event: lifetime bestimmt, wie lange ein Fahrzeug hält, und dieselben Regeln für safe radius, distance und cleanup gelten. Ist ein Fahrzeug ruiniert, entfernt das Event es und setzt bei der nächsten Rotation ein neues.
Ein Infected-Event (Zombie) spricht mit einer Umgebungsdatei, der sogenannten Territory, die festlegt, wohin diese Infected-Gruppe gehört. Die Territory-Seite ist ein tieferes Thema und ein eigenes Tutorial wert, aber die Grundlagen reichen für Änderungen.
Um Zombies einfach zu boosten, erhöhe die minimum- und nominal-Ausgabe des Infected-Events - das maximum musst du dafür selten anfassen. Du kannst auch verschiedene Infected-Children in andere Events mischen, um sie über die Karte zu verteilen, wo immer du mehr davon willst.
Random Presets sind der Mittelsmann zwischen der types.xml und den Spawnable Types. Ein Preset erstellt einen benannten Cargo- oder Attachment-Loot-Pool: eine Liste von Types oder Klassen, jede mit einer Hit Chance. Wenn diese Chance eintritt, wird eines der Children im Pool gewählt.
So bekommst du Vielfalt in oder an einem Objekt - etwa ein Cargo-Preset, das einen Behälter füllt, oder ein Attachment-Preset, das einem Zombie einen Hut oder Rucksack aufsetzt. Das Preset definiert nur den Pool; erst der Spawnable Type, als Nächstes, sagt einem Item, es tatsächlich zu nutzen.
Die cfgspawnabletypes.xml ist das, was einem Type sagt, andere Types angehängt oder in sich zu haben. Sie ist der Konsument der gerade definierten Random Presets: ein Spawnable Type verweist per Name auf ein Cargo- oder Attachment-Preset, und dessen Hit Chances entscheiden dann, was tatsächlich erscheint.
Kurz: die types.xml sagt, dass ein Item existiert, das Random Preset definiert einen Pool möglicher Extras, und der Spawnable Type verdrahtet beide, sodass ein frisch gespawntes Item mit dem richtigen Cargo und den richtigen Attachments ankommt.
Die globals.xml hält die serverweiten Schalter, und sie ist mächtiger, als sie aussieht. Ganz unten steht der übergreifende Infected-Zähler - erhöhe oder senke ihn, um die maximal erlaubte KI festzulegen. Vanilla liegt irgendwo bei 1000 bis 1200; im Quell-Build wurde er auf 850 gesenkt. Daneben findest du den Animal Count und wie schnell eine Leiche aufgeräumt wird.
Ein wichtiges Wertepaar sind die Idle-Einstellungen. Setze beide Idle-Werte auf null, und deine Economy rotiert weiter, selbst wenn niemand online ist, sodass Loot und Events auf einem 24/7-Server frisch bleiben. Weitere Schalter hier steuern, wie viele Loot-Stücke anfangs spawnen, und erlauben das Ein- und Ausschalten von Systemen wie wet, world und tents.
Das ist nur der Einsteiger-Überblick - es gibt mehr Dateien und weit tiefere Videos zu jeder. Aber zu wissen, wie diese Kern-Dateien aufeinander verweisen, reicht, um sicher mit dem Tuning von Loot und Zombies deines Servers zu beginnen.
Beginne in der types.xml und erhöhe nominal und min des gewünschten Items. nominal ist die Zielmenge, die die Economy in der Welt hält, min ist die Untergrenze, die frischen Spawn auslöst.
Für ein Gesamt-Cap erhöhe den Infected-Zähler in der globals.xml. Um ein bestimmtes Gebiet belebter zu machen, erhöhe minimum und nominal des passenden Infected-Events in der events.xml - das maximum musst du meist nicht anfassen.
Fast immer ein Namens-Mismatch. Ein Proto-Name muss exakt zu einem Pos-Namen passen und ein Event-Name exakt zu einem Event-Spawn-Namen. Prüfe Schreibweise und Groß-/Kleinschreibung auf beiden Seiten.
Ein Random Preset (cfgrandompresets.xml) definiert einen benannten Pool möglicher Cargo- oder Attachment-Inhalte mit Hit Chances. Ein Spawnable Type (cfgspawnabletypes.xml) sagt einem echten Item, diesen Pool zu nutzen - das Preset ist also der Mittelsmann zwischen der types.xml und dem, was ein Item beim Spawn trägt.
Setze in der globals.xml beide Idle-Werte auf null. Die Economy rotiert dann rund um die Uhr, sodass ein 24/7-Server mit frischem Loot und Events bestückt bleibt.