@DEVs bzgl. duplizieren

Nachdem ich mir die API von Minecraft angeschaut habe ist mir eine Idee gekommen wie man das duplizieren der Items einschränken könnte. Dazu bedürftes es allerdings etwas freier Performance. Diese würde man allerdings dadurch gewinnen, dass das professionelle und Ressourcen ziehende Dupen abebben würde.

Ein ähnliches Verfahren haben wir früher auch bei einem anderen Spiel benutzt um das duplizieren zu verhindern.

Man müsste ein entsprechendes Plugin schreiben, welches zusätzlich zu den normalen Gegenstandsinformationen eine UUID erzeugt, wenn der Gegenstand auf normalem Weg abgebaut, produziert oder durch das Gamemode-Interface generiert wird. Diese UUID wird zusätzlich abgespeichert in Verbindung mit der UUID des Erzeugers, des augenblicklichen Trägers und des Gegenstandsnamen / -ID. Also müsste auch jedesmal wenn jemand einen Gegenstand aufnimmt, zum Beispiel beim Handel die UUID des Trägers aktualisiert werden. Besser wäre es noch, einfach einen Eintrag hinzu zu fügen. Einen für das "fallen" lassen der positionieren und einen für das aufnehmen.

Anhand dieser Liste könnte man den Weg eines Items gut nachverfolgen.

Nun zum Punkt des duplizierens.... Alle anderen Funktionen erzeugen eben keine eigene neue UUID. Ein Duplizierter Gegenstand würde also entweder die gleiche UUID verwenden oder keine besitzen... Findet man dann also im Log mehrere gleiche Events des gleichen Typs mit gleicher ID, zum Beispiel mehrere male ein Gegenstand mit gleicher Gegenstands UUID aufgenommen wird, ohne dass dein Drop-Event dazwischen ist, weiß man, dass es sich um duplizierte Items handeln muss.

Ja ich weiß, dass diese Schreib- und Lese-Vorgänge Performance kosten, aber ich denke, dass es sich lohnen würde, wenn man es dadurch eindämmt.

Eine Überprüfung des Logs könnte man ebenfalls automatisieren und muss ja nicht zwingend in Echtzeit passieren, da der Schaden, welcher zum Beispiel über den Zeitraum einer Stunde oder halben Stunde doch recht begrenzt ist.

Ich weiß nicht welche Serverkonfiguration ihr als Hardware habt, aber wenn man diese Informationen nur in eine Cue schreibt, ein extra Prozess welcher auf einem anderen Thread als der Server läuft, diese dann in einen File schreibt ist es überschaubar. Man müsste es eben Multithreading machen, was eigentlich kein Problem ist.

Wenn ich ein normales Serversetup nehme, dann sind bei der doch recht geringen Datenmenge von 34 Byte bis maximal 196 Byte schätze ich mal grob ohne Probleme 100k pro Sekunde durchaus drin. Und dabei gehe ich noch nichtmal von einer wirklich hohen APC aus.

Und der Vorteil der Cue ist halt der, dass sie nur etwas Speicher kostet und der sekundäre Thread zum schreiben das was er nicht in Echtzeit schafft dann einfach wenn es ruhiger wird abarbeitet.

Der Gewinn wenn die Duper merken, dass es nichts mehr bringt überwiegt dann und die Datenmenge welche zu bewältigen ist, nimmt ab.

Nehmen wir mal grob 300 Spieler zu Topzeiten pro CB plus/minus, kommen wir auf etwa 3500 gleichzeitige Spieler.

Also bräuchtest du knapp 300 Item/Block Änderungen pro Sekunde pro Spieler um an die Grenze zu kommen.

Da Minecraft eh recht beschränkt ist, was das Multithreading angeht, läuft mancher Prozessorkern gerne auf Sparflamme der das dann übernehmen könnte.

Die Übersicht über eine Instanz des MC Servers und die Prozessorauslastung gibt da Aufschluss.

Ganz extrem könnte man das sogar so auf die Spitze treiben, dass das Plugin die Informationen sogar nur an einen nativen Systemprozess, den man in C++ oder so entwickelt und schon ist man komplett von dem Serverprozess unabhängig. Dann hängt es wirklich nur noch an der Gesamtkonfiguration des physikalischen Servers.