Konventionen und Quellen

Konventionen und Quellen — wie dieses Wiki mit Zahlen umgeht

← Home

Dieses Wiki dokumentiert einen Server für ein Spiel, zu dem der Hersteller The Indie Stone (TIS) keine vollständigen offiziellen Betriebs-Specs publiziert. Deshalb gilt eine strenge Regel: Jede Zahl und jede behauptete Größe trägt ein Label, das sagt, woher sie kommt. Diese Seite definiert das Label-System, die Quellen-Hierarchie und die Redaktionskonventionen.

Das Label-System

Drei Labels, die direkt hinter dem Wert oder der Aussage stehen:

1. (Community-Quelle: <woher>) — extern belegt

Wert wurde außerhalb des Repos recherchiert und ist nachvollziehbar belegt; die Herkunft wird immer mitgenannt (z. B. pzwiki, Steam-Community-Diskussionen, map.projectzomboid.com, verifizierte Server-Konfigurationen anderer Betreiber).

Beispiel aus diesem Wiki: die Zell-Rechtecke von Raven Creek (Block A: x=16–23, y=59–69 / Block B: x=24–25, y=56–69) auf Spawn-System — Community-Quelle: offizielle map_info.json der Karte, dokumentiert in docs/08 und im Repo-Changelog 0.2.1.

2. (Repo-Default) — der Quellcode setzt genau diesen Wert

Der Wert steht 1:1 so im Repo (Template, Skript, YAML oder Makefile). Er ist autoritativ für die Frage „was macht dieses Repo?" — aber er ist eine Entscheidung der Repo-Autoren, keine TIS-Vorgabe.

Beispiel aus diesem Wiki: die vier Coop-Spawnpunkte (worldX 17–24, worldY 58–68) auf Spawn-System — Repo-Default, 1:1 aus spawns.yaml.

3. (Heuristik) — begründete Eigen-Empfehlung

Kein externer Beleg, sondern eine schlüssig begründete Empfehlung der Projekt-Community/dieses Wikis. Heuristiken sind Diskussionsgrundlage, keine Garantie — sie sollten immer mit ihrer Begründung stehen.

Beispiel aus diesem Wiki: die Port-Freigabe „16261 in UDP und TCP" (siehe Quellen-Konflikt unten und Ports-und-Netzwerk) — Heuristik, weil die Quellenlage widersprüchlich ist und die Doppel-Freigabe harmlos aber robust ist.

Warum diese Strenge?

• TIS publiziert keine offiziellen Storage-, IOPS- oder Performance-Specs für Dedicated Server. Vendor-Zahlen (Hoster-FAQs, Benchmark-Tabellen) und Foren-Angaben sind deshalb nie TIS-Anforderungen — sie dürfen nur als Community-Quelle zitiert werden.
• Es kursieren Fake-Optionen: erfundene ini-Einträge, die in keinem Spiel-Build existieren, werden in Foren und KI-Antworten verbreitet und führen zu still ignorierten Konfigurationen. Der Mythos-Kasten auf Server-Konfiguration listet neun solcher erfundenen Optionsnamen namentlich auf — genau deshalb dürfen sie nirgendwo sonst im Wiki als echte Option erscheinen.
• Zahlen ohne Herkunft werden über kurz oder lang zu „Steuer-Explorer-Fakten": Sie werden zitiert, skaliert und mit anderen unbekannten Zahlen verrechnet. Das Label stoppt das an der Wurzel.

Quellen-Typen

Nach Autorität geordnet:

Quelle	Was sie belegt	Beispiel-Wert
Repo-Quellcode (höchste Autorität für Repo-Verhalten)	alles, was dieses Repo tut: Defaults, Skriptlogik, Make-Targets	die generierte WorkshopItems=-Zeile auf Mods-Referenz (Repo-Default, 1:1 aus scripts/mods-generate.sh)
pzwiki (Community-Wiki)	Spielmechanik, Befehle, Ports, Branch-Status	B42.20 = Stable- und Default-Branch, kein -beta-Opt-in nötig (Community-Quelle: pzwiki)
Steam-Community-Diskussionen	Bugs, Workarounds, Versionierung	steam_appid.txt mit Inhalt 108600 im Server-Verzeichnis behebt „Illegal termination of worker thread" (Community-Quelle: Steam-Diskussionen)
Community-Konsens	über viele Quellen stabile Praxis-Empfehlungen	„Heap-Tiers" (klein/mittel/groß-modded) und „beide Zeilen nötig: Mods= + WorkshopItems=" (Community-Quelle: pzwiki/Konsens)

Bekannte Quellen-Konflikte

Beispiel Port 16261 (der relevante Fall dieses Wikis):

• pzwiki listet 16261 und 16262 als UDP (Community-Quelle: pzwiki).
• Die Storage-/Streaming-Recherche dieses Projekts fand 16261 als TCP (Community-Quelle: Storage-Guide-Recherche).
• Auflösung als Heuristik: 16261 in beiden Protokollen freigeben plus 16262/udp — ein falsch freigegebenes Protokoll kostet nichts, ein fehlendes verhindert Verbindungen. Diese Entscheidung ist auf Ports-und-Netzwerk so dokumentiert.

Umgangsregel bei Konflikten generell: beide Quellen nennen, die Auflösung als Heuristik labeln und begründen — niemals stillschweigend eine Seite gewinnen lassen.

Zahlen pflegen

• Repo-Werte immer aus dem Clone lesen, nie aus Erinnerung oder aus diesem Wiki abschreiben. Wenn mods.yaml sich ändert, ziehen die betroffenen Wiki-Seiten nach (Mods-Referenz, Runbook-Raven-Creek).
• Wiki ↔ docs/-Beziehung: das Wiki ist eigenständig nutzbar und wiederholt alle nötigen Inhalte; die docs/-Ordner im Repo sind die jeweils tiefere/original Quelle. Jede Wiki-Seite mit docs/-Entsprechung verweist unten darauf („Vertieft in Repo: docs/<datei>"). Ändert sich ein Doc, ändert sich die Wiki-Seite — nicht umgekehrt.
• Fakten mit Datum (z. B. „verifiziert am 2026-08-15") behalten ihr Datum; bei neuer Verifikation wird es ersetzt, nicht ergänzt.

Sprach- und Stil-Konventionen

• Sprache: Deutsch im Inhalt; Fachbegriffe, Datei-, Feld- und Zielnamen bleiben Englisch (workshop_id, make mods, enabled).
• Format: GitHub-Flavored Markdown (GFM); Tabellen für Referenzdaten, Code-Blöcke für Befehle und Konfiguration; als Fence-Sprachen bash, ini, yaml, lua verwenden.
• Keine Emoji. Kurze Absätze, Zwischenüberschriften statt Textwände.
• Dateinamen ohne Umlaute/ß (z. B. Konventionen-und-Quellen.md); Umlaute im Inhalt sind erlaubt.
• Links: GitHub-Wiki-Links [[Seitenname]] mit exaktem Dateinamen ohne .md. Jede Seite beginnt mit der Zurück-Zeile > ← [[Home]] und endet mit „Weiter"-Links zu Nachbarseiten plus dem docs/-Verweis, wo eine Repo-Entsprechung existiert.
• Keine erfundenen Optionen, Flags oder Befehle. Was nicht belegt ist, wird als unverifiziert markiert oder weggelassen — nie geraten.

---

Weiter: Home