Mods Referenz

Mods-Referenz — mods.yaml, Load-Order und alle Mods im Repo

← Home

Diese Seite ist die vollständige Referenz der Mod-Verwaltung: Schema von mods.yaml, alle im Repo geführten Mods mit exakten IDs, die vom Generator erzeugten ini-Zeilen und die typischen Stolperfallen. Der prozedurale Ablauf („wie füge ich eine Mod hinzu?") steht auf Modding-Workflow.

Vertieft in Repo: docs/04-modding-workflow.md

Prinzip

mods.yaml ist die Single Source of Truth für alle Mods (Repo-Default). Dort steht deklarativ, welche Mods existieren, welche aktiv sind, was voneinander abhängt und welche Karten geladen werden. Alles andere entsteht automatisch:

make mods

make mods führt zwei Skripte hintereinander aus (Repo-Default, 1:1 aus dem Makefile): zuerst scripts/mods-validate.sh (bricht bei Fehlern mit Exit 1 ab), dann scripts/mods-generate.sh (erzeugt config/generated/workshop-items.txt).

Daraus folgt die Kernregel für die per envsubst gerenderten Werte: Die Server-ini wird für diese Werte nie von Hand gepflegt. Die drei Zeilen WorkshopItems=, Mods= und Map= werden allerdings nicht von make render in die servertest.ini injiziert — scripts/render-config.sh rendert nur die Templates unter config/templates/*.tmpl, und im Template servertest.ini.tmpl sind die drei Zeilen auskommentiert (Repo-Verhalten, render-config.sh + Template). Statt dessen erzeugt make mods (scripts/mods-generate.sh) die drei Zeilen in config/generated/workshop-items.txt, und das Skript weist im Log ausdrücklich darauf hin, sie in ${SERVER_NAME}.ini zu übernehmen — das heißt mit dem Repo-Default SERVER_NAME=servertest in ${PZ_DATA_DIR}/Server/servertest.ini (Repo-Stand: kein Automatismus; Details siehe Architektur unter „Datenfluss (a)").

Achtung: make render allein nimmt die WorkshopItems=/Mods=/Map=- Zeilen nicht in die servertest.ini mit. Wer die Zeilen nicht von Hand aus config/generated/workshop-items.txt in die Ini kopiert, hat nach dem nächsten Render- und Restart-Schritt eine Ini ohne diese drei Zeilen — die Mods liegen dann auf der Platte, werden aber nie geladen (häufigster Fehler laut docs/10, Community-Quelle: PZ-Community-Doku). Konkrete Schrittfolge mit dem manuellen Ini-Schritt steht in Modding-Workflow und Runbook-Raven-Creek.

Schema von mods.yaml

Jeder Eintrag unter mods: hat folgende Felder (alle Bedeutungen Repo-Default, 1:1 aus mods.yaml-Kopf und scripts/mods-generate.sh):

Feld	Typ	Bedeutung	Pflicht?
name	Text	Anzeigename der Mod (frei, nur Doku)	ja
workshop_id	Zahl	Steam-Workshop-ID aus der URL — landet in WorkshopItems=	ja
mod_id	Text	Interne ID aus der mod.info der Mod — landet in Mods=; der Generator setzt automatisch den B42-Backslash davor	ja
category	Text	Kategorie = bestimmt die Load-Order (siehe unten)	ja
enabled	bool	true/false — steuert, ob der Generator die Mod aufnimmt	ja
requires	Liste	mod_ids, die vor dieser Mod geladen sein müssen	nein
map_name	Text	nur bei Karten: interner Map-Ordnername für die Map=-Zeile	nur bei category: map

Kategorien = Load-Order

Die Reihenfolge der Kategorien ist fest im Generator verdrahtet (ORDER = ["library", "framework", "map", "gameplay", "qol"], Repo-Default aus scripts/mods-generate.sh):

library  ->  framework  ->  map  ->  gameplay  ->  qol

Innerhalb einer Kategorie zählt die Eintragsreihenfolge in mods.yaml (Repo-Default). Warum diese Reihenfolge: Libraries und Frameworks müssen geladen sein, bevor Content und QoL-Mods sie nutzen — die Eintragsreihenfolge in Mods= ist die Ladereihenfolge, Frameworks zuerst (Community-Quelle: PZ-Community-Doku, konsistent mit Repo-Workflow).

Alle Mods im Repo

Die komplette Liste, 1:1 aus mods.yaml (alle Werte: Repo-Default; Stand der Workshop-Verifikation laut mods.yaml-Kommentar: 2026-08-15). Workshop-Link- Muster: https://steamcommunity.com/sharedfiles/filedetails/?id=<Workshop-ID>.

Mod	mod_id	Workshop-ID	Kategorie	Aktiv
that DAMN Library	damnlib	3171167894	library	ja
NeatUI Framework [B42]	NeatUI_Framework	3508537032	framework	ja
Raven Creek B42	RavenCreekB42	3484263516	map	ja
West Point Expansion B42	WestPointExpansionB42	3475754603	map	nein
Common Sense	CommonSense	2875848298	gameplay	ja
Firearms B42	FirearmsB42	2256623447	gameplay	nein
Spawn Selector [B42 Stable]	SpawnSelector	3772052709	qol	ja
Neat Crafting	Neat_Crafting	3502080466	qol	ja
Neat Building	Neat_Building	3536052310	qol	nein
Project Cook	Project_Cook	3490188370	qol	ja
Proximity Inventory (B42.13 Fix, inoffiziell)	ProximityInventory4213	3624308198	qol	ja

Abhängigkeiten im Repo (Repo-Default)

Mod	benötigt (requires)
Raven Creek B42	damnlib
West Point Expansion B42	damnlib
Neat Crafting	NeatUI_Framework
Neat Building	NeatUI_Framework
Project Cook	NeatUI_Framework

Was enabled: false bedeutet

Der Generator in scripts/mods-generate.sh filtert vor der Erzeugung: mods = [m for m in data.get("mods", []) if m.get("enabled")] (Repo-Default). Eine deaktivierte Mod erscheint also in keiner der drei Zeilen — sie wird weder heruntergeladen noch geladen. Der Eintrag bleibt in mods.yaml erhalten und kann jederzeit durch enabled: true wieder aktiviert werden.

Die drei deaktivierten Mods und ihre Begründungen (Repo-Default aus den mods.yaml-Kommentaren):

Mod	Grund für enabled: false
West Point Expansion B42	B42-Populations-Bug in den Expansions-Zellen gemeldet (Aug 2026) — vor Aktivierung Workshop-Kommentare prüfen
Firearms B42	nicht mit anderen Waffen-Overhauls mischen — Doppel-Items (Community-Quelle: docs/04 sinngemäß)
Neat Building	Stabilität: mehrere Server-Reports Aug 2026 — „Invalid SpriteConfig object!"-Warnungs-Spam korreliert mit Server-Lag; nach Fix durch Autor wieder aktivieren

Generierte Zeilen

make mods erzeugt config/generated/workshop-items.txt. Mit dem aktuellen Repo-Stand (8 aktive Mods, Repo-Default — identisch mit dem Beispiel in docs/10-runbook-raven-creek.md) entsteht exakt:

WorkshopItems=3171167894;3508537032;3484263516;2875848298;3772052709;3502080466;3490188370;3624308198
Mods=\damnlib;\NeatUI_Framework;\RavenCreekB42;\CommonSense;\SpawnSelector;\Neat_Crafting;\Project_Cook;\ProximityInventory4213
Map=Raven Creek B42;Muldraugh, KY

Was jede Zeile steuert (Repo-Default aus docs/10):

Zeile	Inhalt	Steuert
WorkshopItems=	numerische Workshop-IDs (Reihenfolge egal)	nur den Download
Mods=	Mod-IDs mit führendem \ (Backslash ist B42-Pflicht)	Laden + Load-Order
Map=	interne Map-Ordnernamen, semikolongetrennt	welches Terrain die Welt nutzt

Die Map=-Regeln

Karten-Mods tragen in mods.yaml ein map_name:; alle aktiven Karten landen in der Map=-Zeile. Die Regeln (Community-Quelle: Repo-Changelog 0.3.0, im Repo als verifiziert dokumentiert):

• Frühere Maps gewinnen: der Server liest von links nach rechts; bei Zell-Überlappungen setzt sich der zuerst gelistete Eintrag durch.
• Muldraugh, KY immer zuletzt: die Vanilla-Basismap steht ans Ende, sonst überschreibt sie Mod-Karten komplett. Der Generator hängt sie automatisch an (maps + ["Muldraugh, KY"], Repo-Default aus mods-generate.sh).
• Einträge sind interne Ordnernamen — nicht der Anzeigename und nicht die Mod-ID. Trennzeichen ist nur das Semikolon (Map-Namen dürfen Kommas enthalten: Muldraugh, KY).

Wie der verbindliche Ordnername auf dem Server verifiziert wird, steht auf Spawn-System und Runbook-Raven-Creek.

Mods verwalten

Neu hinzufügen

1. Workshop-Seite öffnen, workshop_id aus der URL kopieren
2. mod_id aus der Workshop-Beschreibung oder der mod.info der Mod kopieren
3. Eintrag in mods.yaml anlegen — Kategorie wählen (bestimmt die Load-Order), enabled: true setzen, bei Karten map_name eintragen
4. make mods — validiert und generiert die neuen drei Zeilen
5. Manuell in die Ini übernehmen: die Zeilen WorkshopItems=/Mods=/Map= aus config/generated/workshop-items.txt in ${PZ_DATA_DIR}/Server/servertest.ini kopieren (mit SERVER_NAME=servertest als Repo-Default) — bevor make render läuft, weil render-config.sh die Zeilen nicht selbst injiziert (Repo-Stand, siehe Architektur „Datenfluss (a)"; ohne diesen Schritt laden die Mods still nicht).
6. make render und Server-Neustart (make restart)

Die ausführliche Variante mit Verifikation im Log steht auf Modding-Workflow.

Deaktivieren

Zwei Wege mit unterschiedlicher Wirkung (Repo-Default):

• enabled: false — Empfehlung für alles, was später vielleicht wieder kommt: Eintrag bleibt dokumentiert, requires-Beziehungen bleiben sichtbar, die Mod verschwindet nur aus den generierten Zeilen.
• Eintrag entfernen — nur bei endgültigem Ausstieg. Nachteil: Historie und Begründung gehen verloren; früher oder später tippt jemand die IDs neu ab.

In beiden Fällen: make mods, dann die neu generierten WorkshopItems=/Mods=/Map=-Zeilen aus config/generated/workshop-items.txt manuell in die servertest.ini übernehmen (kein Automatismus, siehe Prinzip oben) und zuletzt make render && make restart.

Abhängigkeiten

requires: ["<mod_id>", ...] deklariert, dass eine Mod andere Mod-IDs braucht. scripts/mods-validate.sh prüft das beim Validieren (Repo-Default, 1:1 aus dem Skript):

• Für jede aktivierte Mod muss jede ihrer requires-IDs selbst aktiviert sein — fehlt sie oder ist sie deaktiviert, gibt es einen ERROR und Exit 1.
• Deaktivierte Mods werden nicht auf ihre Abhängigkeiten geprüft (man kann also z. B. Neat Building deaktiviert lassen, ohne NeatUI_Framework zu verlieren — das braucht Neat Crafting weiterhin).

FAQ und Stolperfallen

Symptom	Ursache	Fix
Mod lädt still nicht	Eintrag fehlt in Mods= (nur WorkshopItems= gesetzt) — Download ohne Mods=-Eintrag heißt: Mod liegt auf der Platte, wird aber nie geladen (Community-Quelle: PZ-Community-Doku; häufigster Fehler laut docs/10)	make mods, Mods=-Zeile prüfen, neu rendern
IDs verwechselt	workshop_id (Zahl aus der URL) und mod_id (Text aus mod.info) vertauscht oder identisch vergeben	beide Felder einzeln von der Workshop-Seite/mod.info ablesen
B41-Mod installiert	Build 41-Mods sind mit B42 inkompatibel (Repo-Regel aus mods.yaml-Kopf und README)	nur B42-Mods aufnehmen; B41-Eintrag entfernen
Validierung warnt bei neuer Mod mit Platzhalter-ID	workshop_id im Bereich 3600000000–3600000099 — dieser Bereich ist als TODO-Platzhalter markiert und erzeugt nur eine WARNung, keinen Abbruch (Repo-Default aus mods-validate.sh)	echte Workshop-ID von der Steam-Seite eintragen
Doppelte Fehlermeldungen beim Validieren	dieselbe workshop_id oder mod_id zweimal in mods.yaml — beides ist ein ERROR (Repo-Default)	Duplikat entfernen, make mods erneut
Mod nach Aktivierung instabil	wie bei Neat Building: Community-Reports korrelieren Mod-Warnungen mit Lag (Repo-Default-Begründung in mods.yaml)	enabled: false, Workshop-Seite beobachten

Zwei mod_ids im Repo sind laut mods.yaml-Kommentar noch nach dem ersten Download zu verifizieren (FirearmsB42, SpawnSelector — beide derzeit deaktiviert bzw. aktiv, Repo-Default-Hinweis in der YAML). Nach dem ersten Download gilt: mod_id gegen die tatsächliche mod.info prüfen.

---

Weiter: Spawn-System · Modding-Workflow · Updates-und-Rollback