Serverschonende Mechaniken: Tipps und Tricks

Geschenke auf Origo können nun wieder vom Absender abgeholt werden, wenn diese noch nicht geöffnet worden sind.
Der Server wurde erfolgreich auf die Version 1.20.4 aktualisiert und nun wieder erreichbar.
  • Im Folgenden möchte ich einige Tipps und Tricks geben, mit welchen Mitteln ihr Schaltungen serverschonender gestalten könnt oder auf was ihr beim Bauen sonst achten könnt, um den Server weniger zu belasten.


    Trichter
    Das Thema Trichter ist ein besonders großes und wurde bereits mehrmals auf dem Server angesprochen. Trichter fragen immer (10 mal pro Sekunde) ab, ob sie ein Item über ihm einsammeln können. Gleichzeitig fragen diese auch ab, ob sie ein Item in eine der 5 weiteren Richtungen abgeben können. Dabei ist es irrelevant, ob tatsächlich Items zum Transport zur Verfügung stehen oder nicht. Auch das Abdecken eines Trichters unterbindet diese Abfragen dabei nicht.


    Deshalb sollten immer möglichst wenig Trichter benutzt werden. Sie sind nicht verboten und können gerne genutzt werden. Doch jeder eingesparte Trichter hilft der Performance auf dem Server.


    Lagersysteme
    Für Lagersysteme gibt es ein serverseitiges Plugin. Besitzt man nicht genug Geld, um sein gesamtes Lager anschließen zu können, so sollte jeder überlegen, ob er nicht lieber zu Schonung des Servers zu entsprechenden Kisten läuft, bis diese ebenfalls an das Lagersystem angeschlossen sind.


    Farmen
    Trichter werden häufig zum Einsammeln der Drops von halbautomatischen Farmen genutzt. Um diese an den Stellen einzusparen, ist eine Wasserstraße zu empfehlen, die die Items zu einem Punkt spülen und dort von einem einzelnen Trichter eingesammelt werden.


    Kolben
    Kolben besitzen eine Animation, die über mehrere Ticks (4 Redstone-Ticks) geht. Da Animationen immer berechnet werden müssen, kostet dies entsprechend Ressourcen. Dies gilt für alle Elemente, auch abseits der Kolben. Darauf werd ich aber später noch einmal eingehen. Bei einzelnen Kolben ist dies nicht weiter spürbar, sondern erst, wenn sehr viele Kolben gleichzeitig berechnet werden müssen. Möchte man also mehrere Kolben anschließen, so sollten diese versetzt aktiviert werden durch zB einen Verstärker (Repeater) auf mindestens 2. Stufe. Als Richtwert können 10 Kolben genommen werden, die zeitgleich aktiv sind.


    Verzögerungen
    Wie gesagt, wird jede Animation berechnet. Dazu zählt jede Veränderung eines Redstone-Elements, wie das aktivieren oder deaktivieren einer Redstone-Spur. Bei größeren Schaltungen sollten daher immer Verzögerungen durch z. B. Verstärker eingebaut werden. Auch bei Benutzung von Wireless-Redstone kann dies in den Befehl /qc <Schaltkreistyp> [Verzögerung] hinzugefügt werden.


    Clocks
    Clocks sind zwar generell erlaubt, dürfen aber nur aktiv sein, solange die Schaltung aktiv von einem Spieler genutzt wird. Auch hier gilt das Prinzip der Verzögerung. Je schneller eine Clock läuft, desto belastender ist diese. Deshalb sollte auf die sogenannten Rapid-Clocks verzichtet werden.


    Minecarts/Boote
    Minecarts und Boote zählen als Entities. Seit der Minecraft Version 1.9 stoßen sich Entities gegenseitig ab, sobald sie sich berühren. Dies bedeutet auch jedesmal eine Neuberechnung der Bewegung. Deshalb sind Räume, in denen sich viele Minecarts/Boote dauerhaft berühren, eine größere Belastung für den Server. Deshalb sollten solche Situationen vermieden werden.


    Ähnlich belastend sind aber auch Dorfbewohner, die sich in einem Minecart befinden. Der Dorfbewohner versucht dauerhaft, sich in dem Minecart fortzubewegen. Dies geschieht selbst dann, wenn das Minecart mittels Blöcken an seiner Position gehalten wird. Die Minecarts sollten deshalb unter den Villagern entfernt werden, sobald sich diese an deren endgültigen Positionen befinden.


    Wasser/Lava
    Flüssigkeiten werden immer bei einer Veränderung berechnet. Wird ein Gebiet mit Wasser/Lava neu überflutet, so finden viele Berechnungen statt, wo sich die jeweilige Flüssigkeit hin ausbreitet. Je größer die überspülte Fläche ist, desto aufwändiger ist es für den Server. Sobald diese Ausbreitung abgeschlossen ist, so werden auch keine neuen Berechnungen durchgeführt.


    Besonders bei einige Farmen (z. B. Lohenfarmen, diverse Essensfarmen) findet diese Mechanik häufiger statt. Sobald eine Essenfarm mittels Wasser geerntet, oder eine Lohenfarm aktiviert/deaktiviert wird, verändert sich zeitweise das Wasser. Um diese Veränderung möglichst gering zu halten, sollten Essensfarmen nicht übermäßig groß gebaut und Lohenfarmen sollten nicht häufig im Wechsel aktiviert und deaktiviert werden.


    Mobs
    Wie bereits bei Minecarts und Booten, gilt auch für Mobs, dass sie sich gegenseitig abstoßen, sobald sie aufeinander treffen. Auch hier gilt, dass es möglichst vermieden werden sollte, dass sich viele Mobs auf einer kleinen Fläche befinden. Dies trifft am meisten bei Hühner- oder sonstigen Tierfarmen, als auch auf Sammelstellen von Monsterfarmen zu. Letzteres ist weniger ein Problem, sofern die Monster nach kurzer Zeit wieder getötet werden.


    Mobs auf Wasser stellen dabei ein größeres Problem dar. Da die Mobs die ganze Zeit auf dem Wasser schwimmen, werden ständig neue Berechnungen zur Bewegung durchgeführt. Verstärkt werden diese, sobald sich mehrere Mobs an derselben Stelle auf dem Wasser befinden. Sollte dies nicht gerade gebraucht werden, so sollte das Wasser unter den Mobs entfernt werden, um dem Server die Berechnungen zu ersparen.

  • Habt ihr Fragen oder Anmerkungen dazu, können diese hier gestellt werden. Bei Bedarf werde ich den Guide dann jeweils ergänzen. Solltet ihr euch unsicher sein, ob eure Farm/Schaltung zu viel ist, so könnt ihr euch gerne an mich wenden.

  • Hey Puddy,


    vielen Dank für diesen tollen Guide. Ich persönlich nutze viel Redstone, jedoch nicht viel von den serverbelastenden Knostruktionen.
    Auch ich versuche immer möglichst an Trichtern zu sparen, und komme damit auch ganz gut klar.


    Rapid-Clocks


    Ich weiß nicht was mein kleiner Bruder wieder gemacht hat, aber ja, ich habe ihm schon gesagt, dass er serverschadend ist. :P


    Wie schon gesagt, sehr guter Guide, gerade für Neulinge die viel mit Redstone bauen, aber auch für schon "ältere" Spieler hier. ^^


    Ich hoffe es werden sich einige Spieler an diesem Guide informieren und ggf. Redstoneschaltungen serverfreundlicher bauen.

  • Kolben
    Kolben besitzen eine Animation, die über mehrere Ticks (4 Redstone-Ticks) geht. Da Animationen immer berechnet werden müssen, kostet dies entsprechend Ressourcen. Dies gilt für alle Elemente, auch abseits der Kolben. Darauf werd ich aber später noch einmal eingehen. Bei einzelnen Kolben ist dies nicht weiter spürbar, sondern erst, wenn sehr viele Kolben gleichzeitig berechnet werden müssen. Möchte man also mehrere Kolben anschließen, so sollten diese versetzt aktiviert werden durch zB einen Verstärker (Repeater) auf mindestens 2. Stufe. Als Richtwert können 10 Kolben genommen werden, die zeitgleich aktiv sind.

    Animationen sind doch nicht Sache des Servers sondern Sache des Clients. Von daher ist doch auch die Anzahl von ItemFrames und ArmorStands serverseitig nicht sonderlich problematisch. sondern eher clientseitig belastend.


    Das wesentliche Problem bei Kolben ist, dass bei Auseinanderfahren und Zusammenziehen geprüft wird, ob die Blöcke durch LWC gesichert sind oder diese WorldGuard-Grenzen überschreiten. Dabei ist es besonders bei großen Pistonfarmen problematisch, weil diese alle fast gleichzeitig ausfahren und kurz darauf wieder einfahren. Dabei überlappen sich dann noch die Ausfahr- und Einfahrberechnungen durch Repeater.
    Manchmal sind die Auswirkungen dafür stärker oder weniger stark. Jedenfalls waren mir bisher diese Riesenfarmen immer ein Dorn im Auge und wegen mir könnten die auch verboten sein...

  • Die Animationen sind immer nur Clientseitig. Auch die reine Animation bei Redstone ist erstmal nur Clientseitig, auf dem Server wird dann im Hintergrund geschaut, ob das Signal an andere Blöcke weitergegeben werden muss. Je mehr Redstone gleichzeitig aktiviert wird, desto mehr Prüfungen finden in der Hinsicht statt. Bei Kolben sind es die Prüfungen ob die beiden Blöcke vor ihm gesichert sind.


    Der Guide soll erst einmal allgemein verständlich sein. Die meisten Spieler kennen sich wenig mit den Mechaniken aus, die im Hintergrund ablaufen und würden einen Text, der mit "Fachbegriffen" gefüllt ist, kaum verstehen. Vielen Spielern wird aber es mit Sicherheit auch grundlegend erstmal egal sein, was genau berechnet wird. Solange sie verstehen, welche Teile belastend sind, reicht ihnen das aus.


    Sollte doch ein Großteil an Hintergrund-Aktivitäten interessiert sein, kann dies nachgefragt/ergänzt werden.

  • Die Animationen sind immer nur Clientseitig. Auch die reine Animation bei Redstone ist erstmal nur Clientseitig, auf dem Server wird dann im Hintergrund geschaut, ob das Signal an andere Blöcke weitergegeben werden muss. Je mehr Redstone gleichzeitig aktiviert wird, desto mehr Prüfungen finden in der Hinsicht statt. Bei Kolben sind es die Prüfungen ob die beiden Blöcke vor ihm gesichert sind.

    Nimm es mir nicht übel, aber was bringt es in einem Thread auf clientseitige Belastungen hinzuweisen, wenn es im Titel um die serverseitige Performance geht. Für meinen Teil sollte man hier nicht auf clientseitige Animationen eingehen, vor allem, wenn es auch für nicht so bewanderte Leute verständlich sein soll ;)

  • Erstmal vielen Dank für den Guide, @Puddyman00 :)


    Der Guide soll erst einmal allgemein verständlich sein. Die meisten Spieler kennen sich wenig mit den Mechaniken aus, die im Hintergrund ablaufen und würden einen Text, der mit "Fachbegriffen" gefüllt ist, kaum verstehen. Vielen Spielern wird aber es mit Sicherheit auch grundlegend erstmal egal sein, was genau berechnet wird. Solange sie verstehen, welche Teile belastend sind, reicht ihnen das aus.


    Ich fände es interessant zumindest in einem Spoiler unter dem Beitrag mal die genauen im Hintergrund ablaufenden Mechaniken zu erfahren (gerne auch mit ein paar Fachbegriffen).
    Darüberhinaus muss ich mich @JOO200 anschließen: Ein Guide über "serverschonende Mechaniken" sollte keine clientschonenden Mechaniken beinhalten. Dies macht den Guide sehr unübersichtlich und für Spieler, die ein paar Kenntnisse von den Mechaniken im Hintergrund haben, wirkt der Guide somit nicht wirklich "vertrauenswürdig", sondern eher verwirrend (Was haben jetzt bitte schön die Animationen von Kolben mit der Serverperformance zu tun?).



    Wenn die Kollisionen solche Probleme bereiten, warum schaltet man sie dann nicht ab oder gibt Spielern nicht zumindest die Möglichkeit die Kollisionen in bestimmten Bereichen abzuschalten? Ich stelle mir dies in etwa wie in diesem Thread schon beschrieben vor: Body-Blocking in manchen Gebieten abstellbar machen
    Gerne erstelle ich dazu auch noch einen Vorschlag, auch wenn die eigentliche Idee in dem oben verlinkten Thread schon gut erklärt wurde.

  • Ein Guide über "serverschonende Mechaniken" sollte keine clientschonenden Mechaniken beinhalten.


    Ich verstehe eure Kritik durchaus. Eine Grundproblematik für Spielertipps ist stets, dass viele Spieler schlichtweg "Lag" als "Lag" betrachten und nicht in clientseitig und serverseitig unterteilen. Demnach halte ich es durchaus für sinnig einen Guide über alle "Lag"-Referenzen zu haben.


    Wir werden in den nächsten Tagen den Guide noch einmal anpassen und etwas optimieren, sodass sowohl Spieler als auch Experten einen besseren Gesamteindruck erhalten. :)

    Wenn die Kollisionen solche Probleme bereiten, warum schaltet man sie dann nicht ab oder gibt Spielern nicht zumindest die Möglichkeit die Kollisionen in bestimmten Bereichen abzuschalten?


    Die Spielerkollision ist eher selten ein Problem. In dem von dir beschriebenen Thread wurde die Kollision für das jeweilige Event bereits deaktiviert. Zusätzlich haben wir bereits seit längerer Zeit die maximale Anzahl an Entity-Kollisionen pro Tick reduziert. Vereinfacht gesagt haben wir dafür gesorgt, dass beispielsweise 1x1 Hühnerfarmen weniger auf die Serverperformance einwirken.


    Wir versuchen stets das Spiel so wenig wie nur möglich zu beeinflussen. Dies führt leider auch dazu, dass wir zu jeder Zeit an einer Grenze arbeiten. Viele Server verbieten einfach alle Features, die Performance ziehen können. Wir verlassen uns hierbei in erster Linie auf unsere Community. Das heißt, dass wir euch gerne einen weiteren Handlungsrahmen geben und dann auf euch zugehen, wenn es zu viel wird, statt von vornherein alles zu verbieten. So gibt es immer wieder Aktionen, bei denen wir Spielergruppen ansprechen, die einen größeren Einfluss auf die Performance haben als andere, um mit diesen dann über mögliche Optimierungen zu sprechen. Die tolle mithilfe unserer Community hat so zum Beispiel dazu geführt, dass es bis heute keine offizielle Restriktion für Trichter gibt, obwohl wir diese schon sehr oft in unsere Überlegungen mit einbezogen haben. Dieser Guide soll insbesondere für unwissende Spieler einen Einblick in diese Thematik geben.


    Für weitere Fragen/Ideen bezüglich der Performance bin ich immer gerne zu haben. :)

  • Eine Grundproblematik für Spielertipps ist stets, dass viele Spieler schlichtweg "Lag" als "Lag" betrachten und nicht in clientseitig und serverseitig unterteilen. Demnach halte ich es durchaus für sinnig einen Guide über alle "Lag"-Referenzen zu haben.


    Dann wäre es aber sinnvoll den Guide "Lagreduzierende Mechaniken" zu nennen und nicht "Serverschonende Mechaniken" ;)
    Eine Einteilung in Clientseitige Lags und serverseitige Lags halte ich trotzdem für sinnvoll. Was bringt es die Kolben-Animationen zu verringern, wenn mein PC damit keine Probleme hat und sonst niemand in die Nähe meiner Kolben kommt, dem Server an Performanceverbesserung? Wenn ich serverschonende Mechaniken bauen will, bringt es mir nichts, wenn mir clientschonende Mechaniken angeboten werden. Ich halte die Unterscheidung für sehr sinnvoll, alleine schon aus dem Grund um Spielern diese Unterscheidung einmal näher zu bringen. Wenn diese Unterscheidung nirgends getroffen wird, ist es für einen Spieler auch nicht möglich dies zu unterscheiden.



    @Puddyman00 Wenn Trichter ständig Leistung ziehen, ist es dann sinnvoll Trichter durch Spender/Werfer mit einer Redstoneschaltung zu ersetzen? Wie sich gezeigt hat zieht diese zwar, wenn sie aktiv ist, deutlich mehr Leistung, dafür ist sie aber nur zu dem Zeitpunkt aktiv an dem sie gebraucht wird und nicht durchgängig.

  • Vielen Dank für die Infos in diesem Guide. Ich habe bereits einiges davon umgesetzt. Ich finde beide Arten von Performance-Verbesserung sehr nützlich.


    Deshalb sind Räume, in denen sich viele Minecarts/Boote dauerhaft berühren, eine größere Belastung für den Server. Deshalb sollten solche Situationen vermieden werden.


    Das betrifft ja z.B. einen Lorenspeicher in einem Bahnhof. Um das zu vermeiden gab es bereits diesen Vorschlag:
    https://terraconia.de/post/149377
    Gibt es eine brauchbare "schonendere" Alternative zu den Lorenspeichern bis besagter Vorschlag umgesetzt werden kann?

    Grüße Keighar

    "Willst Du die Welt verändern, so verändere Dich selbst" Mahatma Gandhi

  • Animationen sind doch nicht Sache des Servers sondern Sache des Clients. Von daher ist doch auch die Anzahl von ItemFrames und ArmorStands serverseitig nicht sonderlich problematisch. sondern eher clientseitig belastend.


    Das wesentliche Problem bei Kolben ist, dass bei Auseinanderfahren und Zusammenziehen geprüft wird, ob die Blöcke durch LWC gesichert sind oder diese WorldGuard-Grenzen überschreiten. Dabei ist es besonders bei großen Pistonfarmen problematisch, weil diese alle fast gleichzeitig ausfahren und kurz darauf wieder einfahren. Dabei überlappen sich dann noch die Ausfahr- und Einfahrberechnungen durch Repeater.
    Manchmal sind die Auswirkungen dafür stärker oder weniger stark. Jedenfalls waren mir bisher diese Riesenfarmen immer ein Dorn im Auge und wegen mir könnten die auch verboten sein...


    @Joo200 , @Puddyman00
    Ich grabe das Thema mal aus. Also verstehe ich es richtig, dass der Einsatz von Kolben unkritisch ist, solange die Kolben nicht gleichzeitig bewegt werden? Und es ist diesbezüglich völlig egal, ob die Kolben permanent eingefahren oder permanent ausgefahren sind, da Berechnungen bei Kolben nur dann durchgeführt werden, wenn der Kolben bewegt wird?


    Was ja bedeuten würde, dass ich theoretisch 200+ Kolben in sagen wir mal 4-5 Chunks setzen könnte, solange diese nicht gleichzeitig bewegt werden..