NeoForge-Konfiguration: Welche Einstellungen nutzt eure Welt?
Wenn sich ein NeoForge-Modpack auf dem Eventserver anders verhält als auf dem Rechner eines Teilnehmers, klärt zuerst die Zuständigkeit für die Einstellung, ihren Konfigurationstyp und die tatsächlich verwendete Datei. Gleiche Mod-JARs belegen noch kein gleiches Verhalten. Prüft die gewünschte Regel vor der Abnahme mit einer Kopie der vorgesehenen Welt, einem frischen Client und einer bereits benutzten Installation.
Diese Anleitung richtet sich an Community-Betreiber und Teams, die ein Modpack oder einen eigenen Mod beauftragen. Sie beschreibt einen vorgeschlagenen Abnahmetest; Mineando hat diese Tests nicht durchgeführt. Das Beispiel ist fiktiv. Behandelt werden Einstellungen im Konfigurationssystem von NeoForge. Für Mods mit eigenen Systemen ist deren Dokumentation maßgeblich.
Beschreibt zuerst die Regel aus Spielersicht
Formuliert eine beobachtbare Anforderung, bevor ihr über Ordner sprecht. Zum Beispiel: „Das beauftragte Teleport-Item darf während seiner Abklingzeit nicht erneut verwendet werden.“ Benennt die Aktion, die erwartete Reaktion und die Person, die das Ergebnis abnimmt. Ein Screenshot aus einem Konfigurationseditor belegt diese Anforderung nicht.
Lasst den Verantwortlichen den Mod, seine genaue Version, den Schlüssel, den gültigen Wert und die zugehörige Dokumentation oder Codestelle nennen. Haltet auch Minecraft- und NeoForge-Version fest. Übernehmt keinen vermuteten Schlüssel aus einem ähnlichen Mod. Geht nach einem Update auch nicht ungeprüft davon aus, dass eine Option weiterhin dasselbe bedeutet.
Die Checkliste zur Modpack-Übergabe hält fest, welches Paket geliefert wird. Ergänzt sie um einen eigenen Konfigurationsnachweis für die wesentlichen Eventregeln. So lässt sich getrennt prüfen, ob die richtige Version installiert wurde und ob das gewünschte Verhalten tatsächlich zu beobachten war.
Klärt, welche Seite die Einstellung bestimmt
Die NeoForge-Dokumentation zur Konfiguration unterscheidet CLIENT, COMMON und SERVER: Clienteinstellungen bleiben lokal, gemeinsame Einstellungen werden nicht automatisch synchronisiert, Servereinstellungen dagegen an Clients übertragen. Diese Framework-Typen garantieren weder, dass jeder Mod sie verwendet, noch dass gleich benannte Dateien dieselben Werte enthalten.
Lasst für jede wichtige Regel folgenden Nachweis ausfüllen:
| Feld | Benötigte Information |
|---|---|
| Verhalten | Aktion und beobachtbares Ergebnis für die Abnahme. |
| Zuständigkeit | Mod und verantwortliche Person. |
| Quelle | Tatsächlicher Dateipfad, Schlüssel und dokumentierter Konfigurationstyp. |
| Aktivierung | Unterstütztes Neustart- oder Neuladeverfahren für diese Option. |
| Nachweis | Prüfung des wirksamen Werts und des resultierenden Verhaltens. |
Bleibt die Quelle unklar, ist der Fall offen. Den gesamten Konfigurationsordner eines Clients auf den Server zu kopieren, ersetzt diese Klärung nicht. Persönliche Anzeige- und Steuerungseinstellungen sollten außerhalb der verbindlichen Eventkonfiguration bleiben, sofern es keinen dokumentierten Grund für ihre Verwaltung gibt.
Prüft die vorgesehene Welt zusätzlich zur Installation
Die NeoForge-Referenz für 1.21–1.21.1 dokumentiert weltbezogene serverconfig-Overrides für SERVER-Konfigurationen. Eine vorhandene Welt ist deshalb für die Untersuchung relevant. Prüft die Dokumentation eurer genauen Loader-Version und lasst bestätigen, welche Datei in dieser Installation Vorrang hat.
Erfasst die vorgesehene Serverinstallation und die Welt, die ihr öffnen wollt. Notiert alle relevanten Kopien einer Einstellung samt Speicherort und Wert. Weichen Vorlage und bereitgestellte Welt voneinander ab, entscheidet ausdrücklich, welcher Wert gelten soll. Löscht weder die Welt noch ihren Konfigurationsordner, um einen sauberen Start zu erzwingen.
Untersucht das Verhalten auf einer isolierten Kopie. Bewahrt die ursprünglichen Dateien und ein Änderungsprotokoll auf, damit der Ausgangszustand wiederherstellbar bleibt. Die Anleitung zur Wiederherstellungsprobe behandelt die Rückkehr zu dieser Umgebung. Eine Konfigurationsänderung allein ist kein Wiederherstellungsplan für Weltdaten.
Erprobt eine absichtliche Abweichung
Angenommen, ein beauftragter Teleport-Mod soll beim Event eine Abklingzeit von 30 Sekunden durchsetzen. In einer älteren Teilnehmerinstallation steht lokal noch ein Wert von 5 Sekunden. Das sind beispielhafte Anforderungen, keine gemessenen Zeiten und keine empfohlenen Standardwerte eines bestehenden Mods.
Lasst erklären, wo die verbindliche Entscheidung fällt und wie der Client sie darstellt. Prüft anschließend folgende Fälle, ohne gleichzeitig andere Variablen zu verändern:
- Startet den vorgesehenen Server mit der Weltkopie und der dokumentierten Konfiguration. Haltet Version und Ausgangsdateien fest.
- Verbindet einen frischen Client. Verwendet das Item und versucht es während der Abklingzeit erneut. Prüft die vereinbarte Reaktion.
- Wiederholt den Ablauf mit der älteren Clientkonfiguration. Notiert getrennt, was die Oberfläche anzeigt und ob der Server die Aktion akzeptiert.
- Trennt die Verbindung während der Abklingzeit und verbindet euch erneut. Prüft das vereinbarte Verhalten, statt ein Zurücksetzen oder Fortsetzen des Timers vorauszusetzen.
- Führt den dokumentierten Neustart durch und wiederholt die relevanten Fälle. Bestätigt, welche Einstellungen danach wirksam bleiben.
Bei diesem vorgeschlagenen Design darf eine veraltete Anzeige keine Umgehung der serverseitigen Regel ermöglichen. Widersprechen sich Anzeige und Aktion, erfasst beide Beobachtungen. Die Korrektur kann die Dateiverteilung, Synchronisierung oder Implementierung des Mods betreffen. Das Symptom allein belegt die Ursache noch nicht.
Vergleicht frische und bestehende Installationen
Verwendet eine kleine Matrix: frischer und bestehender Client, jeweils mit einer neuen Testwelt und mit einer isolierten Kopie der Eventwelt. Dokumentiert jede Kombination separat. Haltet die Packversionen während der Untersuchung konstant. Werden gleichzeitig Mods ausgetauscht, lässt sich eine Veränderung schlechter zuordnen.
Tritt die Abweichung nur mit der Eventwelt auf, untersucht ihre spezifischen Einstellungen und den relevanten gespeicherten Zustand. Betrifft sie nur den bestehenden Client, prüft dessen beibehaltene Einstellungen und Updateverlauf. Das sind sinnvolle Untersuchungspfade, keine Beweise gegen eine bestimmte Datei. Ändert einen einzelnen dokumentierten Wert, wiederholt den Fall und bewahrt die Ergebnisse auf.
Bei einem eigenen Launcher erläutert die Abnahme von Launcher-Updates, warum erhaltene Spielerdateien eine ausdrückliche Regelung brauchen. Definiert die Grenze zwischen verpflichtenden Packeinstellungen und persönlichen Vorlieben. Setzt nicht stillschweigend alle Teilnehmerinstallationen zurück, um eine einzelne Abweichung zu beheben.
Verlangt eine nachvollziehbare Übergabe
Nehmt die Konfigurationsarbeit ab, wenn ein anderer Operator die wirksamen Einstellungen finden, das dokumentierte Verfahren anwenden und die wesentlichen Regeln reproduzieren kann. Bewahrt Weltkennung, Ausgangszustände der Clients, Dateiänderungen, Beobachtungen und offene Ausnahmen zusammen mit der Version auf. Nicht ausgeführte Fälle erhalten ausdrücklich den Status „nicht getestet“.
Diese Prüfung belegt weder eine Spielerzahl noch die Kompatibilität mit jedem Mod oder die Korrektheit sämtlicher Spielmechaniken. Wählt zunächst die Regeln, deren Fehler das Event verhindern könnten. Erweitert die Prüfung bei Änderungen am Release. Zusätzliche Arbeit für eigene Konfigurationsformate muss gegebenenfalls gesondert vereinbart werden.
Für die Entwicklung eigener Mods und Modpacks bringt ihr die benötigten Regeln, unterstützten Versionen und diesen Abnahmenachweis mit. Mineando bietet kostenpflichtige Projekte mit individuell vereinbartem Umfang und Angebot an. Wartung und Eventbetreuung werden separat vereinbart, einschließlich der Zuständigkeit für Änderungen nach der Probe.
