Modpack fürs Event: Die Version vor der Verteilung prüfen
Bevor ihr ein Minecraft-Modpack für ein Event verteilt, legt eine eindeutig bezeichnete Version fest. Bereitet Client und dedizierten Server getrennt vor und lasst eine weitere Person das Spielerpaket in einer frischen Instanz installieren. Gebt die Version erst frei, wenn dieser Client die wesentlichen Event-Abläufe mit dem vorgesehenen Server durchlaufen hat. Ein erfolgreicher Start auf dem Rechner des Modpack-Autors reicht dafür nicht aus.
Diese Checkliste richtet sich an Community-Betreiber, Veranstalter und Teams, die ein eigenes Modpack beauftragen. Sie behandelt eine nachvollziehbare Auslieferung und die Abnahme der Installation. Sie liefert keine Aussage zur Spielerzahl, die ein Server bewältigt. Das Beispiel beschreibt einen vorgeschlagenen Probelauf; für diesen Artikel wurden keine Minecraft-Tests ausgeführt.
Eine eindeutige Version für die Übergabe festlegen
Vergebt eine Kennung wie event-pack-r3 und verändert die zugehörigen Downloads anschließend nicht mehr. Eine Korrektur wird zu r4; sie ersetzt nicht unbemerkt den Inhalt des Downloads von r3. Verwendet dieselbe Kennung in der Anleitung, im Bereitstellungsprotokoll und in den Testergebnissen. Sie dient eurem Team als Referenz und ist keine Minecraft-Kompatibilitätseinstellung.
Fordert für die Übergabe ein kurzes Versionsprotokoll mit folgenden Angaben:
- Genaue Minecraft- und Modloader-Version sowie die Java-Anforderung dieser Kombination.
- Client-Paket, Installationsverfahren für den Server und freigegebene Downloadquellen.
- Dateiliste mit Versionen und Prüfsummen, einschließlich Event-Konfiguration und Skripten.
- Pflichtbestandteile und optionale Komponenten sowie eine eigene Soll-Liste für jede Umgebung.
- Bekannte Einschränkungen, Installationsanleitung, Änderungsverlauf und zuständige Person für eine neue Freigabe.
Haltet fest, welcher Launcher und welche Betriebssysteme tatsächlich geprüft wurden. „Funktioniert mit allen Launchern“ ist kein ausreichend bestimmtes Abnahmekriterium. Nutzt ein Teilnehmer einen anderen Launcher, entscheidet ausdrücklich über einen zusätzlichen Test oder den Ausschluss aus dem vereinbarten Umfang.
Eine Prüfsumme ermöglicht den Vergleich heruntergeladener Bytes mit einem freigegebenen Artefakt. Sie belegt weder Sicherheit noch Kompatibilität oder eine Erlaubnis zur Weiterverteilung. Bezieht das Versionsprotokoll über den vereinbarten vertrauenswürdigen Kanal. Ein Hash neben einem unbekannten Download bietet keine unabhängige Absicherung.
Client und Server brauchen eigene Dateilisten
Verlangt keine identische Dateianzahl auf beiden Seiten. Entscheidend sind die erwarteten Inhalte pro Umgebung und die Begründung jeder beabsichtigten Abweichung. Prüft die Angaben der jeweiligen Mod-Autoren und die Abhängigkeiten. Aus dem Dateinamen allein lässt sich der richtige Installationsort nicht zuverlässig ableiten.
Die NeoForge-Dokumentation zu Client und Server erklärt, warum ein funktionierender Einzelspielermodus keine Kompatibilität mit einem dedizierten Server belegt: Dort fehlen reine Client-Klassen. Nehmt deshalb einen echten dedizierten Server in den Probelauf auf.
Bei .mrpack beschreibt die Modrinth-Formatspezifikation Abhängigkeitsversionen, Datei-Hashes und Umgebungsangaben sowie gemeinsame und umgebungsspezifische Zusatzdateien. Lasst prüfen, wie die gewählten Installationswerkzeuge diese Vorgaben umsetzen. Das Archivformat allein belegt noch keine funktionierende Bereitstellung.
Das Versionsprotokoll soll den freigegebenen Zustand beschreiben. Erfasst auch Konfigurationsänderungen außerhalb des Pakets und deren Verantwortliche. Private Server-Zugangsdaten und projektfremde lokale Dateien gehören nicht in den Teilnehmerdownload. Kontrolliert den Archivinhalt vor der Verteilung.
Die Installation aus Teilnehmersicht proben
Gebt das Kandidatenpaket samt Anleitung an eine Person, die es nicht zusammengestellt hat. Sie richtet eine separate Instanz ein und übernimmt keine Dateien aus der Arbeitsinstallation des Autors. Vorhandene Spielstände und persönliche Einstellungen bleiben erhalten.
Dokumentiert Paketkennung, Launcher, Java-Laufzeit, Betriebssystem und Testzeitpunkt. Anschließend folgt die Testperson dem vorgesehenen Teilnehmerweg: herunterladen, importieren, erforderliche Downloads abschließen, starten, verbinden und die erste Event-Aktion ausführen. Jede manuelle Reparatur gehört ins Protokoll. Ist ein undokumentierter Eingriff erforderlich, verbessert die Lieferung und wiederholt die betroffenen Schritte.
Verwendet eine entbehrliche Testumgebung mit dem vorgesehenen Serverstand und repräsentativen Event-Inhalten. Bei einer vorhandenen Welt arbeitet ihr mit einer isolierten Kopie. Die Anleitung zur Probe einer Backup-Wiederherstellung behandelt die zusätzliche Frage, ob der Wiederherstellungsstand tatsächlich nutzbar ist.
Eine zweite Testperson mit einer anderen unterstützten Rechnerkonfiguration kann verdeckte Annahmen aufdecken. Das erweitert die Prüfung, bestätigt aber nicht automatisch alle Geräte, Internetverbindungen oder Betriebssysteme der Teilnehmer.
Eine überschaubare Abnahmematrix verwenden
Für ein fiktives Event könnt ihr die folgenden Fälle vor dem Probelauf vereinbaren. Ersetzt „Event-Mechanik“ durch die konkrete Aktion, etwa das Betreten einer eigenen Dimension, das Herstellen eines Wettbewerbsgegenstands oder die Nutzung der Anmeldung.
| Testfall | Erforderlicher Nachweis zur Freigabe |
|---|---|
| Frische Installation des vorgesehenen Clients | Die Anleitung funktioniert ohne undokumentierte Dateiänderungen. |
| Verbindung zum vorgesehenen dedizierten Server | Die Testperson erreicht den richtigen Event-Startpunkt. |
| Wesentliche Event-Mechanik | Die geplante Aktion funktioniert; das beobachtete Ergebnis ist protokolliert. |
| Trennen und erneutes Verbinden | Der vereinbarte Spielerzustand bleibt korrekt erhalten. |
| Regulärer Serverneustart | Dieselbe Version startet erneut; der wesentliche Ablauf funktioniert weiterhin. |
| Vorherige Teilnehmerversion | Das Verhalten ist dokumentiert; das Team kann die Abweichung erkennen und beheben. |
Geht nicht davon aus, dass ein älterer Client immer abgewiesen wird. Das hängt von den konkreten Komponenten ab. Prüft die Vorgängerversion ausschließlich in der Testumgebung. Legt fest, wie das Team eine nicht unterstützte Installation erkennt, selbst wenn sie sich verbinden kann.
Zu jedem Ergebnis gehören Versionskennung, Sollverhalten, tatsächliches Verhalten und ein relevanter Logauszug. Noch nicht ausgeführte Fälle bleiben als „nicht getestet“ gekennzeichnet. Übernommene Häkchen aus einer älteren Version belegen nichts über geänderte Dateien.
Späte Änderungen als neue Version behandeln
Angenommen, r3 besteht die Prüfung, doch am Vorabend muss ein eigenes Rezept geändert werden. Erstellt r4, nennt die geänderten Dateien, bestimmt die betroffenen Tests und holt eine neue Freigabe ein. Prüft mindestens die frische Installation, die Verbindung und dieses Rezept erneut. Berührt die Änderung weitere Mechaniken, erweitert den Probelauf entsprechend. Das ist ein vorgeschlagenes Vorgehen und keine gemessene Zeitplanung.
Bewahrt die vorherigen Artefakte und einen dokumentierten Wiederherstellungsstand auf. Ein älteres Paket macht Änderungen an der Welt oder extern gespeicherten Daten nicht automatisch rückgängig. Wurde die Wiederherstellung noch nicht geprobt, dokumentiert diese Einschränkung und entscheidet, ob das Update warten kann.
Vereinbart einen Verteilungsschluss und eine Person, die die freigegebene Version bekannt gibt. Entfernt veraltete Downloadlinks aus Teilnehmeranleitungen, behaltet aber ein kontrolliertes Archiv für den Betrieb. Vermeidet spontane Einzelreparaturen, durch die mehrere undokumentierte Varianten entstehen.
Freigabe und verbleibende Prüfungen trennen
Gebt die Lieferung frei, wenn die Version eindeutig feststeht, beide Installationen ihrer jeweiligen Soll-Liste entsprechen, die wesentlichen Abläufe funktionieren und keine blockierenden Installationsfehler offen sind. Haltet akzeptierte Einschränkungen und Verantwortliche für offene Punkte fest. Die Leistungsprüfung bleibt eine eigene Aufgabe: Eine saubere Installation und eine erfolgreiche Verbindung belegen keine Event-Kapazität.
Für die Entwicklung eines Modpacks oder Launchers bringt ihr Versionsprotokoll, unterstützte Teilnehmerumgebungen, zentrale Mechaniken und Termin mit. Mineando kalkuliert bezahlte Projekte nach individuell vereinbartem Umfang. Umfasst der Auftrag eine technische Event-Probe, klärt auch Paketverteilung, Installationshilfe und die Freigabe später Änderungen. Wartung und Live-Betreuung werden gesondert vereinbart.
