Beta-Funktionstest

[Sumpfhytte]

Ich stelle mir das auch tatsächlich für die Spieler sowohl als auch das Serverteam mühsam und umständlich vor..

Wir schauen mal, wie es sein wird, wenn es soweit ist. Bisher war die Notwendigkeit zum Füllen von großen Seen ziemlich überschaubar, da wird es jetzt nicht plötzlich einen Ansturm geben. Sollte dennoch etwas nötig sein, könnten wir zum Beispiel technische Lösungen prüfen, um auf Nachfrage von dem WE-Filter ausgenommen zu werden. Allerdings bleibt dann immer noch das Problem, dass man versehntlich grass_block mit grass verwechselt und damit den Server stört. Auch das könnte man wieder technisch lösen, aber bevor die ganze Sache immer komplizierter wird, warten wir wie gesagt erstmal ab, wie groß die Notwendigkeit wirklich sein wird.

 

[fscript]

Allerdings bleibt dann immer noch das Problem, dass man versehntlich grass_block mit grass verwechselt und damit den Server stört.

Kann man das nicht über einen Chatfilter lösen? So in etwa: "Um Grasblöcke zu setzen nutze die Block-ID grass_block, wenn du wirklich Grashalme (Block-ID grass) setzen willst, gib den Befehl erneut ein."

 

[Sumpfhytte]

Auch das könnte man wieder technisch lösen, aber bevor die ganze Sache immer komplizierter wird, warten wir wie gesagt erstmal ab, wie groß die Notwendigkeit wirklich sein wird.

 

[Wulfens]

Bisher war die Notwendigkeit zum Füllen von großen Seen ziemlich überschaubar,

Es gibt nicht nur große Seen mit Wasser zu füllen.

Allerdings bleibt dann immer noch das Problem, dass man versehntlich grass_block mit grass verwechselt

Es ging ja erst einmal um Wasser und den //fill-Befehl. Aber Vieles könnte man auch mit einer wie von @fscript vorgeschlagenen Lösung probieren.

warten wir wie gesagt erstmal ab, wie groß die Notwendigkeit wirklich sein wird.

Ja, aber die Leute gewöhnen sich auch an das Umständliche. Wie willst du feststellen, wie groß die Notwendigkeit wirklich ist, wenn sich die Leute jetzt ins Unbequeme schicken und mit Wassereimern und anderen Behelfen arbeiten?

Wie oft gab es denn eigentlich in der Vergangenheit durch Versehen von Spielern mit WorldEdit spürbare Störungen des Servers?

 

[Sumpfhytte]

Es ging ja erst einmal um Wasser und den //fill-Befehl.

Es geht um den WorldEdit-Filter. Der unterscheidet nicht zwischen Befehlen oder Blöcken, sondern funktioniert ohne Ausnahme so, wie hier beschrieben.

Wie oft gab es denn eigentlich in der Vergangenheit durch Versehen von Spielern mit WorldEdit spürbare Störungen des Servers?

Der Filter kann nicht zwischen Versehen und Absicht unterscheiden. Jeden Tag kommen neue Spieler auf den Server. Die Störungen, die der WorldEdit-Filter verhindert, passieren so oft, dass wir einen WorldEdit-Filter brauchen. Der einzelne Spieler bekommt diese Anzahl nicht mit, weil er nicht 24/7 in der Creative-Welt oder in einem Bauevent ist, aber jede Störung dieser Art ist schon zu viel, denn dann kann nicht weitergespielt werden. Daher bekommen die Devs in diesen Fällen eine Meldung auf ihren Handys, damit sie den entsprechenden Server umgehend wieder aktivieren können.

Es wäre möglich, den WorldEdit-Filter komplizierter zu machen, aber wir warten erstmal ab, ob dieser Aufwand nötig ist.

 

[Sumpfhytte]

Am Sonntag fand ein spontaner 1.16.4-Belastungstest statt mit folgendem Ergebnis:

• Die programmierte Deaktivierung der Villager, wenn sie einige Zeit nicht genutzt werden, funktioniert. Die Villager machen keine Performanceprobleme mehr.
• Leider gibt es immer noch eine massive Überlastung des Servers, sobald mehr als 20 Spieler in einer Welt sind. Dadurch treten starke Probleme beim Laden der Welt auf: Man bewegt sich vorwärts, aber die Welt erscheint nicht, so dass man ins Leere läuft und nichts sieht (Chunkladeprobleme). In manchen Fällen friert man an dieser Stelle ein und kann sich nur durch Verlassen des Servers befreien. Die Devs sind aktuell auf der Suche nach Ursachen und Lösungen. Einige mögliche Ursachen wurden schon ausgeschlossen, aber noch wird weiter geforscht. Wir halten euch auf dem laufenden.

 

[Wasserhahn24]

• Leider gibt es immer noch eine massive Überlastung des Servers, sobald mehr als 20 Spieler in einer Welt sind.

Ich sagte schon gestern, wir müssen es wie Thanos machen. 50 % aller Spieler entfernen.

 

[Building_Engine]

50 % aller Spieler entfernen.

Meldest du dich freiwillig?

 

[Wulfens]

Wir halten euch auf dem laufenden.

Danke für die Info und für die Arbeit an dem Update. Fühlt euch bitte nicht gedrängt, unbedingt zum geplanten Termin Mitte November fertig zu werden. Auch, wenn ich mich auf die Neuerungen freue, ist mir erst einmal ein gutes Spielerlebnis wichtig.

 

[Sumpfhytte]

Aktueller Stand: Die Devs haben gestern ausführlich die Chunkladeprobleme getestet. Der Server hat allgemein keine Probleme damit, es sind die Clients, die sich verschlucken und die nötigen Daten nicht immer anzeigen. Da wir die Programmierfehler in euren Clients nicht ändern können, testen wir, ob mehrfaches Senden der Chunkdaten hilft.
Auslöser der Probleme ist immer wieder die zu hohe Belastung des Servers mit zu vielen Berechnungen. Die Devs haben schon viele dieser Belastungsquellen gefunden (z.B. unbenutzte Villager oder übertriebene Farmen) und sind nun zu den Stellen vorgedrungen, die sie bisher nicht entdecken konnten, weil sie von den anderen überlagert wurden. Diese neu entdeckten Belastungsquellen werden jetzt angegangen. Danach wird wieder mit möglichst vielen Spielern getestet, wie gut die neuen Optimierungen funktionieren.

 

[Wasserhahn24]

Also verstehe ich das richtig, dass der Server eigtl. läuft, aber die. 1.16 zu doof programmiert wurde um als Empfänger die Daten richtig auszugeben?

 

[Sumpfhytte]

Naja, "doof" ist ein hartes Wort, denn auf einem Realms-Server von Mojang können nur maximal 10 Spieler sein und bis 20 Spieler funktioniert es ja. Aus Mojang-Sicht also 100% besser als nötig

Unsere Tests haben gezeigt, dass die Daten (glücklicherweise) auf Serverseite immer vorhanden und aktuell sind, also kann es nur an der Client-Server-Kommunikation liegen. Das Problem hängt diesmal nicht von der Leistungsfähigkeit des Client-Computers ab, weil es auch bei starken Client-Rechnern auftritt. Es passiert folgendes: Wenn der Spieler sich weiterbewegt, wartet der Client auf neue Chunkdaten, um diese anzuzeigen. Dabei wartet er so lange, bis er der Meinung ist, dass diese Daten angekommen sind. Er wartet auch, wenn der Spieler schon längst 16 Blöcke weiter gelaufen/gefahren/geflogen und im nächsten Chunk ist. Eigentlich könnte der Client jetzt mit dem Warten aufhören und die nunmehr überflüssig gewordenen Daten überspringen, denn er muss nichts hinter dem Rücken des Spielers anzeigen. Aber er wartet weiter und wartet und wartet. Das Spiel friert ein und nur ein Relog hilft. Da wir das auf Clientseite nicht ändern können, versuchen wir die Daten mehrfach zu senden, damit so etwas nicht passiert.

 

[Woofington]

Doch, "doof" ist schon angemessen. Ich bin immer wieder erstaunt, dass Entwickler knapp 25 Jahre nach dem ersten VR-Boom in den 1990ern immer noch nicht gelernt haben, was Area of Interest Management ist und wie man das richtig implementiert.

 

[Wasserhahn24]

Naja, "doof" ist ein hartes Wort, denn auf einem Realms-Server von Mojang können nur maximal 10 Spieler sein und bis 20 Spieler funktioniert es ja. Aus Mojang-Sicht also 100% besser als nötig

Unsere Tests haben gezeigt, dass die Daten (glücklicherweise) auf Serverseite immer vorhanden und aktuell sind, also kann es nur an der Client-Server-Kommunikation liegen. Das Problem hängt diesmal nicht von der Leistungsfähigkeit des Client-Computers ab, weil es auch bei starken Client-Rechnern auftritt. Es passiert folgendes: Wenn der Spieler sich weiterbewegt, wartet der Client auf neue Chunkdaten, um diese anzuzeigen. Dabei wartet er so lange, bis er der Meinung ist, dass diese Daten angekommen sind. Er wartet auch, wenn der Spieler schon längst 16 Blöcke weiter gelaufen/gefahren/geflogen und im nächsten Chunk ist. Eigentlich könnte der Client jetzt mit dem Warten aufhören und die nunmehr überflüssig gewordenen Daten überspringen, denn er muss nichts hinter dem Rücken des Spielers anzeigen. Aber er wartet weiter und wartet und wartet. Das Spiel friert ein und nur ein Relog hilft. Da wir das auf Clientseite nicht ändern können, versuchen wir die Daten mehrfach zu senden, damit so etwas nicht passiert.

Aber was hat das mit der Spielermenge zu tun, wenn es doch auf UNSERER Seite mit der Datenverarbeitung nicht klappt? Warum interessiert das den Clienten überhaupt beim Chunkladen?

 

[ArtemisKnight]

Ich nehme mal an das sind zwei verschiedene, nebeneinander auftretende Probleme @Wasserhahn24 .
Trotzdem bleibt die Performance ein Flaschenhals, der duch viele, nicht zwangsläufig voneinander abhängige, Dinge beeinflusst wird.
Deswegen müssen wir trotzdem für möglichst viele Probleme eine Lösung finden.

 

[Sumpfhytte]

Grundsätzlich hat der Client keine Chunkdaten, er zeigt sie nur an. Er bekommt sie per Internet vom Server. Der lädt die Welt abschnittsweise (Chunkdaten) von seinem Massenspeicher in seinen Arbeitsspeicher und sendet sie an alle Clients, die diese Chunkdaten gerade brauchen.

Dass ein Spieler mitten im Spiel einfriert, ist ein Problem des Clients, weil der Client fehlende Daten nicht überspringen kann. Aber natürlich kann man so nicht spielen, daher müssen wir etwas dagegen tun. Das Überspringen fehlender Daten wäre die einfachste Lösung, aber weil wir die Clients nicht ändern können, versuchen wir die Chunkdaten mehrfach vom Server an die Clients zu senden.

Außerdem haben wir erkannt, dass dieses Verschlucken von Daten offenbar mit der Belastung des Servers zusammenhängt. Er hat zwar alle Daten, aber wenn er zu viel zu tun hat, sendet er sie möglicherweise nicht alle oder nur teilweise. Da können wir nichts machen, wir können das Spiel nicht neu programmieren. Aber auch da hilft das mehrfache Senden. Zusätzlich wird die Verringerung der Serverbelastung dazu führen, dass dieses Verschlucken seltener auftritt.

 

[Kathinka72]

Was für die Clients wohl noch aktuell erschwerend hinzukommt ist die gesamte Internetsituation.

Ich verfolge das schon eine Weile und musste feststellen, dass durch den erneuten Lockdown vermehrt Leistungseinbrüche zu verzeichnen sind. Das hatten wir beim ersten Lockdown auch, wenn auch noch massiver als jetzt. Jetzt fällt es weniger auf, da Schüler (noch) zur Schule gehen und viele Arbeitnehmer auch (noch) zur Arbeit dürfen.

Wir sollten das als User nicht ganz außer Acht lassen.

 

[HalfKnightDrums]

Gestatten, Wasserhahn24, erster Jurist von UWMC. Spezialisiert auf Regeln, RfdF und weitere Ergänzungen.
Oh man das wird 'n ganz schöner Batzen an neuem Inhalt und Regeln. Freu mich drauf. Schade nur, dass das Quarz aus den Angeboten der Drofbewohner verschwunden ist. Hatte mich schon auf die Wirtschaftskrise gefreut.

Quartz Preis wird sinken, da Piglins Quartz traden, kostet damit zwar Gold aber ganz billig wirds nicht

 

[Michael1203]

Quartz Preis wird sinken, da Piglins Quartz traden, kostet damit zwar Gold aber ganz billig wirds nicht

Ist das schon bestätigt?

 

[Rodikachu]

Quartz Preis wird sinken, da Piglins Quartz traden, kostet damit zwar Gold aber ganz billig wirds nicht

Also wenn ich die Dropzahlen anschaue, brauchst du 2400 Goldbarren (bei 9:1 etwa 266 Dias) für etwa 880 Netherquarz (220 Quarzblöcke, bei 9 Dias der Stack also knapp 31 Dias wert), also nein. Das wird sich nicht lohnen ;P Quelle