Ein Paper-Server mit TPS, die Sie erklären können

Die Linie lautet CraftBukkit, Spigot und Paper. Weil Paper die API von Bukkit und Spigot bewahrt, startet das JAR eines für Spigot kompilierten Plugins ohne Neukompilierung. Deshalb funktioniert der Bestand an EssentialsX, LuckPerms, Vault und WorldGuard nach dem Wechsel weiter.

Was Paper hinzufügt, ist Implementierung, keine neue inkompatible API: neu geschriebene Chunks, Lichtmotor, Entity-Tracking, Trichter. Nichts davon macht den Tick parallel, der Gewinn kommt daraus, dass jeder Tick weniger kostet. Der Wechsel des JAR bringt eine echte, aber begrenzte Verbesserung, der Rest hängt an der Konfiguration und daran, welche Plugins Sie laden.

TPS ist bei 20 gedeckelt. Ein Server, der 45 Millisekunden pro Tick verbraucht, zeigt 20,0 und wirkt gesund, obwohl er nur 5 Millisekunden Luft hat. Eine Explosion oder jemand, der neues Gelände erkundet, reicht, um über 50 zu gehen und die Zahl abstürzen zu lassen. Wer nur die TPS beobachtet, erfährt vom Problem nach dem Spieler.

Schauen Sie auf die Verteilung, nicht auf den Durchschnitt. Niedriger Median mit hohem 95. Perzentil deutet auf eine periodische Spitze, und der übliche Verdächtige ist Autosave, ein geplanter Task oder Geländeerzeugung. Hoher Durchschnitt mit enger Verteilung deutet auf konstante Last, fast immer Entities, Trichter oder Code, der bei jedem Bewegungsereignis läuft.

Es lohnt sich außerdem, Tick-Lag von Netzwerk-Lag zu trennen. Ist das mspt entspannt und der Spieler spürt weiterhin Verzögerung, hilft kein Schlüssel in einer yml.

Ab Paper 1.19 wurde die Konfiguration in zwei Dateien im Ordner config aufgeteilt: paper-global.yml für alles, was für den ganzen Server gilt, und paper-world-defaults.yml für die Standardwerte der Welten. Jede Welt kann weiterhin in ihrer eigenen paper-world.yml überschreiben, was sie will. Alte Anleitungen verlangen immer noch, eine paper.yml im Stammverzeichnis zu bearbeiten, die es in diesen Versionen nicht mehr gibt.

In der globalen Datei bleibt fast alles beim Standard, und was eine Änderung rechtfertigt, sind Proxy-Anbindung, Paketbegrenzer und Chunk-Laden. Die Gewinne, nach denen alle suchen, stehen in der Weltdatei: Despawn-Bereiche, Mobs pro Spieler, Kollision, Trichter und die Redstone-Implementierung.

Das Überschreiben pro Welt ist die am wenigsten genutzte Möglichkeit. Eine Minenwelt verträgt aggressives Despawn und kurze Simulation, ohne dass sich jemand beschwert, während das Haupt-Survival konservativ bleibt. Dieselbe aggressive Konfiguration auf alle Welten anzuwenden, macht aus Optimierung ein Support-Ticket.

Jene optimierte Datei, die in Foren kursiert, wendet Dutzende Änderungen auf einmal an. Auf dem Server dessen, der sie geschrieben hat, funktioniert sie. Auf Ihrem werden zwei oder drei dieser Schlüssel etwas kaputt machen, und Sie werden nicht herausfinden können, welche, weil Sie alles zusammen eingefügt haben.

Die Schäden sind vorhersehbar. Sehr kurzes Despawn zusammen mit verringerter Spawn-Reichweite erzeugt die klassische Beschwerde, dass keine Mobs zum Farmen erscheinen. Eine zu niedrige Aktivierungsreichweite lässt den Mob stehen bleiben und die Farm mit ihm. Den Spawner-Mobs die KI zu nehmen, tötet Mechaniken, die von Bewegung abhängen. Ein hoher Zusammenführungsradius ändert, wie sich Drops am Boden gruppieren. Und ein Wechsel der Redstone-Implementierung ändert die Aktualisierungsreihenfolge der Leitungen, genug, damit eine timing-empfindliche Contraption ihr Verhalten ändert.

Akzeptieren Sie außerdem, dass ein guter Teil des Gewinns in gar keiner yml steckt. Das schwere Plugin ist fast nie das mit dem größten JAR, sondern jenes, das bei jedem Ereignis synchron eine Datenbank abfragt, in einem wiederholten Task Entities durchgeht oder Chunk-Laden außerhalb des asynchronen Wegs erzwingt.