TileEntities - Truhen, Öfen und mehr...

[BuildingDave]

Hallo an alle Entwickler.
Ich suche nach einer Möglichkeit Truhen erst später laden zu lassen.
Aktuell ist die "Sichtweite" bei Truhen (TileEntities) bei 64 Block. Auf All meinen Servern sind dadurch zu Spitzenzeiten fast 800.000 TileEntities geladen.
Schon lange beobachte ich, dass genau das viel Leistung vom Server zieht.
Die Frage ist jetzt, wie, bzw wo muss ich die Spigot abändern um die Sichtweite auf 16 zu bekommen.

Diese Einstellung gibt es NICHT in der bukkit.yml oder spigot.yml - das eine solche Änderung in eine neue Spigot-Version gepatcht werden muss ist klar.
Nur wie oben bereits erwähnt finden wir die Stelle nicht an der es abgeändert werden muss.

Sollte jemand WISSEN diesbezüglich haben bin ich über Info sehr dankbar.

Happy Mining
Dave

 

[Chrisliebär❤️]

Ich kann dir zwar deine Frage nicht direkt beantworten, aber warum versuchst du es denn nicht mal im Spigot Forum? Das sind normalerweise sehr kompetente Leute unterwegs und da gibts sicherlich auch jemanden, der dir dabei helfen kann. Das ist ja vermutlich wirklich nur einfach ein Wert.

Ich würde halt vermuten, dass Chests zusammen mit den Blöcken geladen werden und du entsprechend auch auf eine niedriegere Sichtweite gehen musst.

 

[BuildingDave]

1. MD5 meinte, dass eine solche Änderung nicht wichtig sei... ja... für 99% der Server ist das auch so - aber bei uns schon.
2. Es ist leider nicht "einfach nur" ein Wert... haben schon alles durchkämmt und nichts direktes gefunden.
3. Nein, das laden der Chests hat nichts mit der Sichtweite zu tun. Wenn die Sichtweite auf 8 steht (128 Blöcke) werden die Kisten trotzdem bei 64 geladen. Ist also unabhängig voneinander.

 

[Cyrox]

MD5 hat schon nicht unrecht. Das sind Microoptimierungen, die für den großteil der Server keine Rolle spielen.
Vor allem ist das Laden der Chests in meinen Augen eher weniger das Problem.
Der Kern des Problems liegt in der Programmierung von Minecraft und dem Handling der TileEntities.
Minecraft versucht dabei alles was "TileEntity" ist oder davon ableitet einmal pro Servertick zu checken.
Dazu gehören u.a. auch die Chests. Da wird dann geguckt obs nen StateChange gab (Open -> Close) und dann ggf der Sound abgespielt und die Truhe geschlossen.

Das könnte man theoretisch nur alle 4 oder 5 Ticks checken lassen. Das heißt es würden nurnoch 4-5 Mal die Sekunde alle Chests gecheckt werden statt 20mal. Wie sich sowas auswirkt und ob das ungewollte Nebeneffekte hat kann ich dir leider nicht sagen.
Der Code von Minecraft ist nunmal nicht der beste.

 

[BuildingDave]

Ja... dieser Checkvorgang bei den Truhen wird bei mir 14.000.000.000 mal durchgeführt in einer Stunden, JA... Milliarden... und das auf jedem Stadtserver - davon gibt es insgesamt 5. Und da muss sich einfach was ändern. Das sind 40 - 60 % Serverauslastung zu Topzeiten...

 

[JTK222]

Zählen TileEntitys nicht zu den Sachen die der Server nur an den Client sendet wenn sich diese ändern?

 

[Cyrox]

Um zu wissen ob sich ein TileEntity aber geändert hat, muss das überprüft werden.
Und das ist das Problem. Das senden ist denke ich das geringste Problem.

 

[JTK222]

Nope es reicht wenn der Server sich merkt ob er die Daten mit der Änderung dem Spieler bereits gesendet hat. Genau so funktioniert es mit essen und Health.
Das problem ist halt dass eine TileEntity in der Regel mit jeder Frame gerendert wird, was in MC nicht allzu gut umgesetzt wurde.

 

[Cyrox]

Reden wir grad irgendwie aneinander vorbei?
Ein TileEntity wird vom Server jeden Tick gecheckt obs nen StateChange gab.
Das ist offenbar Daves Problem. Zu dem Zeitpunkt wurde noch garnichts an den Spieler geschickt und das hat auch nichts mit dem Rendering zu tun. Rendering ist Clientseitig, der Check der TileEntities aber Serverseitig.

 

[JTK222]

Reden wir grad irgendwie aneinander vorbei?
Ein TileEntity wird vom Server jeden Tick gecheckt obs nen StateChange gab.
Das ist offenbar Daves Problem. Zu dem Zeitpunkt wurde noch garnichts an den Spieler geschickt und das hat auch nichts mit dem Rendering zu tun. Rendering ist Clientseitig, der Check der TileEntities aber Serverseitig.

Oh fail habe mich beim Hauptpost verlesen... sorry dachte er will das mit den TileEntitys machen weil es bei seinen Spielern lagt.

 

[BuildingDave]

Nein, leider wird der Server sehr stark belastet. Ab 300 Spielern merk ich es doch deutlich. Bei 400 Spielern + ist es ein Weltwunder, dass sich die Leute das noch antun. Es ist halt ein Wirtschaftsserver und kein PvP Zeugs. Da kommt einiges an Kisten, Öfen, Braustände und Schildern zusammen.
Ich habe aktuell 2 Root-Server - einen Intel Xeon E3-1270v2 4x3.50 GHz und einen Intel Xeon E5-1650. Insgesamt laufen 20 MC-Server drauf. Ram ist mehr als genug vorhanden. CPU-Auslastung ist bei 50 - 70 %... und trotzdem Lagt es halt bei 300 Spielern. Da muss eine Lösung her.

Find es aber super, dass sich bereits 2 an den Gedanken beteiligen. Danke dafür...

 

[FelixKlauke]

Nein, leider wird der Server sehr stark belastet. Ab 300 Spielern merk ich es doch deutlich. Bei 400 Spielern + ist es ein Weltwunder, dass sich die Leute das noch antun. Es ist halt ein Wirtschaftsserver und kein PvP Zeugs. Da kommt einiges an Kisten, Öfen, Braustände und Schildern zusammen.
Ich habe aktuell 2 Root-Server - einen Intel Xeon E3-1270v2 4x3.50 GHz und einen Intel Xeon E5-1650. Insgesamt laufen 20 MC-Server drauf. Ram ist mehr als genug vorhanden. CPU-Auslastung ist bei 50 - 70 %... und trotzdem Lagt es halt bei 300 Spielern. Da muss eine Lösung her.

Find es aber super, dass sich bereits 2 an den Gedanken beteiligen. Danke dafür...

Entschuldigung, aber da muss ich einfach mal sagen, dass da das Limit erreicht ist, bei 300 Leuten ist bei einem Bukkitserver schlicht und einfach Ende im Gelände, da kannst du soviel an Renderdistanzen und ähnlichem rumschrauben, wie du willst. Ich habe bereits an einem größeren Projekt mit mehreren wirklich guten Leuten an diesem Problem gearbeitet, aber irgendwann sagt Bukkit einfach, dass es keine Lust mehr hat. Irgendwann ist einfach Ende und bei Bukkit liegt diese Grenze bei einfach bei 300+ Spielern - Mehr geht einfach nicht. Ich würde den Server auf 3 Server splitten (BungeeCord benutzt du ja so oder so schon).

 

[Cyrox]

Du hast schon recht, dass bei einem 0815 Bukkitserver bei ca. 300 Spielern das Limit erreicht ist.
Das ist der Punkt an dem man (wenn man es denn will) mit Mikrooptimierungen im Code anfängt.
Damit kann man denke ich bei Minecraft noch einiges an Power rausholen. Benötigt halt tiefgreifende Javakenntnisse, Zeit und den Willen da überhaupt Zeit reinzustecken.

 

[BuildingDave]

Es laufen insgesamt 21 Minecraftserver im Verbund über Bungee - hier geht es nicht um einen einzigen Server.
Nur das Wirtschaftssystem besteht aus 5 Stadt, 5 Abbau und einem Lobbyserver. Teilweise lagen die Server bei 40 Spielern wie die Hölle. Und das muss sich ändern. Dass ein Server bei 200 am Ende ist weis ich. Deshalb habe ich das alles auch auf so viele Server unterteilt. Also machbar sollte das schon sein...