ServerPlugin TileEntities - Truhen, Öfen und mehr...

Dieses Thema im Forum "Programmierung" wurde erstellt von BuildingDave, 1. Juni 2015.

  1. BuildingDave
    Offline

    BuildingDave

    Registriert seit:
    5. Juli 2012
    Beiträge:
    321
    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
     
    #1
  2. 可愛い
    Offline

    可愛い

    Registriert seit:
    19. Mai 2014
    Beiträge:
    657
    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.
     
    #2
  3. BuildingDave
    Offline

    BuildingDave

    Registriert seit:
    5. Juli 2012
    Beiträge:
    321
    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.
     
    #3
  4. Cyrox
    Online

    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.
     
    #4
  5. BuildingDave
    Offline

    BuildingDave

    Registriert seit:
    5. Juli 2012
    Beiträge:
    321
    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...
     
    #5
  6. JTK222
    Offline

    JTK222

    Registriert seit:
    5. September 2013
    Beiträge:
    665
    Ort:
    Planet Erde
    Minecraft:
    JTK222
    Zählen TileEntitys nicht zu den Sachen die der Server nur an den Client sendet wenn sich diese ändern?
     
    #6
  7. Cyrox
    Online

    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.
     
    #7
  8. JTK222
    Offline

    JTK222

    Registriert seit:
    5. September 2013
    Beiträge:
    665
    Ort:
    Planet Erde
    Minecraft:
    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.
     
    #8
  9. Cyrox
    Online

    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.
     
    #9
    meytro gefällt das.
  10. JTK222
    Offline

    JTK222

    Registriert seit:
    5. September 2013
    Beiträge:
    665
    Ort:
    Planet Erde
    Minecraft:
    JTK222
    Oh fail habe mich beim Hauptpost verlesen... sorry dachte er will das mit den TileEntitys machen weil es bei seinen Spielern lagt.
     
    #10
  11. BuildingDave
    Offline

    BuildingDave

    Registriert seit:
    5. Juli 2012
    Beiträge:
    321
    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...
     
    #11
  12. [Dev] iTzSasukeHDxLP
    Offline

    [Dev] iTzSasukeHDxLP Ehem. Teammitglied

    Registriert seit:
    5. Januar 2014
    Beiträge:
    938

    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).
     
    #12
    meytro gefällt das.
  13. Cyrox
    Online

    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.
     
    #13
    meytro und iTz_Proph3t gefällt das.
  14. BuildingDave
    Offline

    BuildingDave

    Registriert seit:
    5. Juli 2012
    Beiträge:
    321
    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...
     
    #14