Paper: Sichtweite und Simulationsweite gezielt testen
Teste auf einem Paper-Server view-distance und simulation-distance getrennt. Übernimm eine Änderung erst, wenn sie das gemessene Problem verbessert und die benötigten Spielabläufe deiner Community erhalten bleiben. Ein allgemein gültiges Zahlenpaar gibt es dafür nicht. Das Ziel ist eine begründete Konfiguration mit nachvollziehbaren Prüfungen und einem Rückweg.
Dieser Ablauf richtet sich an etablierte Java-Communitys, die eine Optimierung beauftragen oder deren Ergebnis prüfen. Er ist ein vorgeschlagener Testplan, kein Benchmark. Für diesen Artikel wurden keine Servertests durchgeführt. Die später genannten Beispielwerte sind keine Kapazitätsempfehlung.
Zwei unterschiedliche Entscheidungen treffen
view-distance begrenzt die Reichweite, in der der Server Weltdaten an Spieler sendet. simulation-distance betrifft den Bereich, in dem nahe lebende Entitäten aktualisiert werden. Beide Angaben verwenden Chunks. Die Definitionen stehen in Papers Referenz zu server.properties.
Sichtbares Gelände beweist nicht, dass dort jede Spielmechanik funktioniert. Formuliere deshalb den tatsächlichen Bedarf: Ein Bauwerk muss von der Eventplattform aus sichtbar sein, oder eine bestimmte Farm muss vom vorgesehenen Standort aus arbeiten. Prüfe diese Anforderungen direkt, statt das Ergebnis aus dem Namen einer Einstellung abzuleiten.
Diese Anleitung bezieht sich auf Paper. Für ein Modpack mit eigenen Lademechaniken brauchst du einen Kapazitätstest mit dem tatsächlichen Pack. Ein Paper-Ergebnis lässt sich nicht als Zusage für andere Serversoftware übernehmen.
Die wirksame Konfiguration feststellen
Notiere Minecraft-Version, Paper-Build, Java-Version, Pluginliste und aktuelle Distanzen. Sichere die ursprünglichen Konfigurationsdateien. Prüfe jede relevante Welt: Die Einstellungen der Hauptwelt müssen nicht überall gelten.
Paper dokumentiert Distanzüberschreibungen unter world-settings in der Datei spigot.yml. Mit default oder -1 wird der Wert aus server.properties übernommen. Abschnitte für benannte Welten können die allgemeinen Welteinstellungen überschreiben. Prüfe dazu die Spigot-Konfigurationsreferenz. Erfasse auch Plugins, die Distanzen gezielt verändern.
Verlange für den Auftrag eine kurze Gegenüberstellung der geänderten Dateien und eine Erklärung, woher der wirksame Wert stammt. Die gewünschte Zahl in einer Datei reicht als Nachweis nicht aus, wenn eine andere Einstellung sie überschreibt. Wende jeden Kandidaten durch einen kontrollierten Neustart der Testumgebung an und dokumentiere die resultierende Konfiguration.
Benötigte Spielabläufe vorab festlegen
Vereinbare die Prüfungen mit dem Communityteam, bevor ihr Messkurven bewertet. Eine mögliche Auswahl:
| Anforderung | Wiederholbare Prüfung | Aufzubewahrender Nachweis |
|---|---|---|
| Sicht beim Event | Gleicher Aussichtspunkt und gleiche Clienteinstellungen | Screenshot und Bestätigung, dass benötigte Kulissen sichtbar sind |
| Bestehende Farmen | Benannte Farm vom üblichen Spielerstandort betreiben | Beobachtetes Verhalten im gleichen Zeitraum |
| Reisen | Gleiche Strecke im gleichen Tempo zurücklegen | Geländeaufbau, Pausen und Beobachtungen der Spieler |
| Verteiltes Spielen | Gleiche Teilnehmer an denselben getrennten Basen einsetzen | Tätigkeitsprotokoll und Servermessungen |
Wähle die Anforderungen eures Projekts aus, statt sämtliche Minecraft-Mechaniken abzudecken. Halte Welt, Koordinaten, Aufgaben und Dauer fest. Für den Sichtvergleich bleiben die Clienteinstellungen gleich. Lässt sich ein gemeldetes Problem nicht reproduzieren, bleibt der Fall offen. Fehlende Reproduktion ist keine erfolgreiche Abnahme.
Einen kontrollierten Vergleich durchführen
Bereite eine isolierte Weltkopie vor und trenne externe Integrationen von der Produktion. Der Probelauf zur Backup-Wiederherstellung hilft beim Aufbau eines wiederherstellbaren Ausgangspunkts. Plane den späteren Eingriff am produktiven Server gesondert.
Halte Maschine, Ressourcenlimits, Weltzustand, Plugins, Teilnehmer und Ablauf gleich. Trenne Start und Aufwärmphase vom Messzeitraum. Ändere nicht gleichzeitig Arbeitsspeicher, Plugins und Distanzen. Sonst bleibt unklar, welcher Eingriff eine Verbesserung verursacht hat.
Dieses hypothetische Beispiel trennt die Variablen:
| Lauf | Sicht | Simulation | Fragestellung |
|---|---|---|---|
| A | 10 | 8 | Wie verhält sich die Ausgangskonfiguration? |
| B | 8 | 8 | Verbessert eine geringere Sichtweite das beobachtete Problem? |
| C | 10 | 6 | Hilft weniger Simulationsweite bei weiterhin funktionierenden Spielabläufen? |
Die Zahlen erklären nur den Versuchsaufbau. C geht von A aus, nicht von B. Falls beide Änderungen sinnvoll erscheinen, prüfe ihre Kombination als weiteren Kandidaten. Stelle zwischen Läufen einen vergleichbaren Weltzustand her. Das ist besonders wichtig, wenn eine Strecke neues Gelände erzeugt: Eine erneute Fahrt durch bereits erzeugte Chunks stellt eine andere Last dar.
Problem und spielerische Folgen messen
Erfasse pro Lauf TPS, Verteilung der Tickzeiten, Pausen, Fehler und Ergebnisse der Spielprüfungen. Bei 20 TPS beträgt das durchschnittliche Zeitbudget 50 ms pro Tick; ein Mittelwert kann Spitzen verdecken. Die spark-Erklärung zu TPS und MSPT erläutert den Zusammenhang. Eine stabile TPS-Anzeige ersetzt die Funktionsprüfung der Farm oder die Sichtprüfung beim Event nicht.
Erstelle bei reproduzierbarem Problem während der betreffenden Tätigkeit ein Profil anhand von Papers Profiling-Anleitung. Bewahre Messzeitraum und Tätigkeitsnotizen zusammen auf. Ein Profil des leeren Servers erklärt keine Pause, die ausschließlich beim Reisen auftritt. Geht es um verspätet sichtbares Gelände, dokumentiere dieses Symptom ebenfalls. Tickzeiten allein beschreiben nicht die gesamte Erfahrung am Client.
Wiederhole den maßgeblichen Vergleich. Bewahre fehlgeschlagene und abgebrochene Läufe samt Begründung auf. Schwankt der Nutzen ohne erkennbare Ursache, veröffentliche keinen prozentualen Leistungsgewinn. Ein einzelner günstiger Lauf belegt auch keine bestimmte Spielerzahl.
Freigabe und Übergabe vereinbaren
Akzeptiere einen Kandidaten, wenn sich das gemessene Problem wiederholt verbessert und alle vereinbarten Spielprüfungen bestehen. Verwirf oder überarbeite ihn, wenn dafür eine benötigte Funktion verloren geht. Hilft keiner der Kandidaten, nutze das Profil für den nächsten Untersuchungsschritt, statt die Distanzen ohne neue Erkenntnisse weiter zu senken.
Zur Übergabe gehören Ausgangsdateien, freigegebene Änderungen, Versionen, Szenarien, Messungen, offene Einschränkungen und die zuständige Person für das Zurücksetzen der Konfiguration. Plane nach der Umstellung eine Kontrolle bei repräsentativem Spielbetrieb. Alte Einstellungen wieder einzutragen macht zwischenzeitliche Änderungen in der Welt nicht rückgängig. Deshalb findet die Probe in einer isolierten Kopie statt.
Für eine beauftragte Prüfung der verwalteten Infrastruktur bringst du das Symptom, die benötigten Community-Abläufe und vorhandene Nachweise mit. Mineando vereinbart kostenpflichtige Projekte individuell. Anpassung, Prüfung und Übergabe gehören in den Leistungsumfang; laufender Support wird gesondert vereinbart.
