Beiträge von MorsExInferis

Nun kommt mal von dem Tripp runter mit der Vorlage. Er wollte einen Vorschlag machen oder eine Idee präsentieren und hat den frei geschrieben, was manchmal wesentlich einfacher ist als das in eine Vorlage zu pressen.

qtxm

Nun aber zu dir. Sollst da auch eine vernünftige Antwort erhalten.

Also es ist nicht so, dass die Anzahl, die dort angegeben ist, die Ressourcen des Servers begrenzt. Diese Zahl regelt nur wie viele maximal auf den Server drauf können sollen auf Basis von Erfahrungswerten.

Also ist es quasi nur ein Schutz, damit der Server ab dem Punkt nicht noch schlimmer laggt.

Es wäre schön wenn es wirklich so einfach zu regelen wäre, dass man die Zahl hoch stellt, der Server dadurch mehr Ressourcen bekommt, die er dann auf eine kleinere Zahl an Spielern verteilen könnte.

Es ist einfach so, dass die Server schon aktuell am technischen Limit was Prozessorleistung angeht, laufen. Minecraft ist durch sein historisches Wachstum leider sehr auf einen einzelnen Prozessorkern ausgelegt, was bei aktuellen Systemen nunja.... suboptimal ist, die die Leistung pro Kern nicht wirklich groß wächst. Man könnte nur mit höherer Ein-Kern-Leistung dagegen angehen.

Auch wenn es etwas ruhiger im Moment ist, kann ich dir sagen, dass wir mit einem kleinen aber guten Team daran sitzen Minecraft so anzupassen, dass es auch aus mehreren CPU-Kernen einen Nutzen zieht und so dann eine Entlastung für den Hauptteil liefert.

Allerdings machen wir das alles nebenberuflich und ehrenhalber in unserer Freizeit, dass man keinen genauen Termin sagen kann wann es wirklich effektiv besser wird.

Aber ich kann Dir versprechen, dass wir dran sind und ein paar gute Lösungsansätze haben.

Naja, man bekämpft dann aber nur die Symptome und nicht die Ursache und das Verhältnis von Kosten zu nutzen gerät aus dem Ruder.

Aber es ist halt wirklich so, dass die Interaktion der Spieler untereinander damit geringer wird, weil eben weniger auf einem Server spielen würden.

Zitat von AlexPal

es wäre viel einfacher die CBs auf max. 150 leute zu beschränken und mehr CBs servers zu erstellen .dann läuft auch alles . eigentlich ganz einfach

mfg

AlexPal

Was in höheren Kosten für die Hardware resultiert und weniger "Community" bedeutet weil die Leute mehr aufgesplittet werden und sich dadurch die Interaktion untereinander verringert.

Zitat von Hunterz187

Was ist mit dem Server los?
Erst verschwinden BEACONS vom GS, dann Haustiere, und jetzt sind ALLE meine platzierten Köpfe weg auf CB 5 !!!!!!!!!!!!!!!!!!!!!!!

Was nichts hier zu suchen hat, sondern wohl eher in den Bugreport gehört.

Zitat von 50U7R34P3R

Abge: Vielleicht mal 'ne kleine Info wie im Eingangspost...?
Wir haben ja bereits Trichterupdates, Mob-Stacking & auf einzelnen CB's Spielerlimit-Senkungen...
Wie hat sich das bisher ausgewirkt? Wo liegen die aktuellen Performance-Killer?

Letzte Infos kamen ja in der News vom 06.02.2019...
Wie geht das Projekt "Bukkit-Veränderung" bei den Dev's voran?

Deine Community ist wissenshungrig. Fütter sie mal!

Na ich bin mal so dreist und sage wie es zumindest aus der Sicht der "Paper-Veränderung" läuft.

Wir testen im Moment einige Techniken um die Jobs entsprechend zu verteilen, welche bei der Serversoftware anfallen, so dass unterschiedliche Sachen parallel abgearbeitet werden können.

Wie man sich bestimmt vorstellen kann gibt es da bestimmte Sachen zu beachten, wie zum Beispiel dass alles zeitlich synchron laufen muss, oder eine gewisse Asynchronität, vom Spieler unbemerkt, korrigiert wird.

Es müssen viele Sonderfälle beachtet werden, damit das Spielerlebnis nicht getrübt wird.

Stell Dir mal vor Du würdest ein Schaf zig mal schlagen, weil Du für dich optisch direkt davor stehst, aber der Server es als ganz wo anders ansieht. Dann würdest Du drauf einprügeln, nichts passiert und anstatt zu sterben, bekommt es stattdessen ein Babyschaf.

Sowas muss also alles beachtet werden und ist nur eines von vielen Beispielen. So viele, dass darauf alleine schon eine Person abgesetzt ist um diese ganzen Fälle aufzuschlüsseln.

Aber die Aussichten sind gut und der Gewinn an Performance ist merkbar, aber alles noch nicht reif um es auf einen Server aufzuspielen.

Und selbst wenn das alles gelöst und online ist, ist das noch lange nicht das Ende der Fahnenstange.

Und wir fangen auch erst mit den kleinen einfachen Sachen an, auch wenn die noch nicht so viel Gewinn versprechen. Aber jede große Veränderung beginnt mit kleinen Schritten.

Ich hoffe ich konnte eine zufriedenstellende Antwort geben.

Zitat von TyberGaming

Hey Abge,

du schreibst, ihr müsstet ein eigenes Bukkit programmieren, damit das Problem behoben wird. Ich hab einen anderen Vorschlag, schaut euch mal den Server "Glowstone" an, denn dieser sollte mit euren Plugins klar kommen. Laut deren Seite, kann der Server Plugins von Bukkit, Spigot und Paper verarbeiten. Außerdem ist dieser Server multi-thread fähig, was das Problem, meiner Ansicht nach, beheben sollte.

Ich hab es bis jetzt noch nicht selbst getestet, werde ich aber noch machen (ob es für eure Plugins passt müsst ihr selbst testen)

Mit freundlichen Grüßen,

TyberGaming

Es ist weniger ein eigenes Programmieren von Bukkit als eher ein größerer Umbau auf Multithreading. Das hat dabei weniger mit Bukkit, Spigot oder Paper zu tun, sondern eher mit der Vanilla-Minecraft-Serversoftware.

Die ganze Umgebung, das Verwalten der Entities, die Abarbeit von Funktionen ist alles auf Single-Thread ausgelegt. Man merkt daran einfach den Ursprung von Minecraft.

Nebenläufigkeit war da in der Basis nie ein Thema, also ist alles sehr prozedural gehalten.

Das gilt es nun aufzuspalten, zu kappseln und parallel ausführbar zu machen.

Wie ich heute früh schon jemandem erklärt habe muss man eben sehr genau drauf achten wie man etwas verwirklicht.

Es kann vieles nebenher passieren, nehmen wir mal die Mobs... die können komplett eigenständig und losgelöst agieren, also ideal um sowas in einen extra Thread auszulagern, der unabhängig vom Mainthread läuft.

Und dann kommt der Spieler, der das Pferd zum Beispiel füttert und drauf reiten will. Und schon gerät der zuvor unabhängige Thread in Abhängigkeit von anderen Threads. Sei es nun ein weiterer losgelöster oder der Mainthread. Dann muss man nämlich anfangen alles miteinader zu synchronisieren.

Das Beispiel was ich heute früh benutzt habe... Der Spieler will reiten, das Pferd steht aber dann noch am Spawn, während der Reiter schon beim zweiten Frühstück auf "p h" ist. Und das kann eben passieren wenn man die Sachen dann nicht synchron hält.

AHHHHH!!! NICHT! Dabei darf aber auch die Wartbarkeit und die Möglichkeit zum Update NICHT ausser Acht gelassen werden.

Die ganze Arbeit zur Performanceverbesserung läuft auf einer sehr professionellen Ebene.

Mit Ergebnissen ist aber nicht von heute auf morgen zu rechnen, da ihr euch vorstellen könnt, dass eine Umstrukturierung und Anpassung des Codes in dem Umfang von Minecraft nicht so schnell zu bewerkstelligen ist.

Hinzu kommt, dass viele Eventualitäten zu beachten sind, Testings durchgeführt werden müssen und selbst dann bei sehr behutsamen Vorgehen kann es noch immer zu Fehlern kommen, die erst im Livebetrieb auftreten. Um dies natürlich so klein wie möglich zu halten, wird sich immer nur auf Teilaspekte konzentriert um dort dann das Maximum herauszuholen.

Dabei darf aber auch die Wartbarkeit und die Möglichkeit zum Update ausser Acht gelassen werden.

Ich möchte euch daher bitten Geduld walten zu lassen.

Aber ich kann euch versichern, dass der gute Paskal eine Ebene geschaffen hat, die weit über dem liegt was andere Projekte zur Verbesserung von Minecraft geschafft haben.

Zitat von Ben121

Du musst aber aufpassen nicht das sich jemand damit ne API macht dass er sich damit mit der Einfachen Methode onCommand

Op holt! Aber du findest schon Leute dazu!

Sry wegen Rechtsschreibung ich schreibe am Handy!

~Ben121

Das ist nicht so einfach möglich.... Wir arbeiten in einem Team über ein Git-Repository wo niemand etwas einfach einspielen kann, da es die Teammitglieder jederzeit einsehen können und ein Codereview gemacht wird.

Und ich mag keinem in dem Team so wie es gerade ist, unterstellen, dass einer davon irgendwelches Schindluder betreiben will, da die Motivation aller diejenige ist, Abgegrieft weiter zu bringen und Lukas zu unterstützen.

Du musst Dir das auch so vorstellen, dass es unterschiedliche Core-Teams gibt. Und diejenigen die von extern zuarbeiten haben keine zusätzlichen Rechte irgendwas zu deployen oder einzustellen.

Also sind Entwicklung, Weiterentwicklung, Bugfixing und Administration in unterschiedlichen Händen.

Wenn es euch interessiert, gebe ich euch gerne ein paar Informationen bezüglich Multithreading, async/sync, Loadbalancing, Ticks (bei anderen Spielen die berüchtigten Hertz), wie es Minecraft derzeit macht und was das Ziel ist.

Natürlich ohne Versprechen was zu wann umgesetzt wird, da ich ein Performancepedant bin und die Qualität ja auch stimmen soll.

Zitat von FLOODY

Meiner Meinung nach wird es nicht mit simpler asynchronisation der Prozesse getan sein (gehe nicht davon aus, dass das Euer einziger Ansatz sein wird). Die Threads auf andere Kerne zu verlagern, ist definitiv der richtige Ansatz und wird sich deutlich bemerkbar machen. Ändert jedoch nichts daran, dass manche Plugins von der Komplexität so geschrieben sind, dass sie bei weitem mehr Rechenoperationen nutzen, als sie müssten. Daher sollte man da auch angreifen. Wie ich in meinem obigen Beispiel erwähnt und illustriert habe, bedeutet die hohe Komplexität der Plugins, eine höhere Rechenauslastung. Alleine alle Plugins von O(n!) oder O(n²) auf O(n) oder O(1) zu "vereinfachen", würde die Performance exponentiell steigern.

Das was Du erwähnst sind rein theoretische Modelle. Das ist leider nicht so umzusetzen in der Praxis.

Plugins ansich sind recht einfach auf extra Kerne zu legen. Das bieten bukkit und Spigot im Standard, wenn man sich an die Entwicklungsrichtlinie hält und von der entsprechenden Klasse erbt.

Allgemein zur Synchronität und Asynchronität kann ich sagen, dass es ein Modell gibt wie man bei Bedarf die Abarbeitung von einem asynchronen in einen synchronen Prozess übergeben kann bei Bedarf. Egal wie die Auslagerung erfolgen wird, wird selbst mit der Synchronisierung ja Last vom Mainthread genommen und so frei geschaufelt für andere Aufgaben.... Warten verbraucht nun nicht wirklich viel Leistung und blockiert auch nicht wenn es richtig gemacht ist, da nur die entsprechenden Ressourcen während des Prozesses gelockt werden.

Die Plugins selber machen wirklich nur einen sehr recht kleinen Teil aus. Tile und Mob Entities wirken sich da viel mehr aus.

Spigot und Paper verfolgen eben Ansätze, die aber nicht weitreichend genug sind.

Hauptsächlich was die Auslagerung angeht, sehe ich primär die Tiles, Mob-Entities (komplett async, solange niemand auf dem Schwein reitet), Redstone und dann die Flüssigkeiten.

Die aktuell verwendeten Plugins ziehen nicht wirklich viel Performance nachdem was ich weiß und erschließen konnte bisher.

Die Sache ist, dass die GG-Server nicht ins RAM-Limit laufen, sondern in das CPU-Limit. GG basiert auf der 1.8.8 Version der MC-Server-Software. Im Prinzip ist es richtig, dass MC mehrere Kerne unterstützt, so wie es mit allen Java-Applikationen ist.

Plugin-Entwickler sind dazu angehalten, dass die Plugins in einem eigenen Thread laufen und somit die last auf weitere Kerne vereilt wird. Jedoch macht das nicht jedes Plugin und manche greifen sehr auf die Kernprozesse von MC zu. Das bedeutet, dass diese ihre Last dann auch noch auf den Mainthread des Servers legen.

Leider ist es so, dass kapselbare Prozesse in MC leider noch immer im Mainthread laufen und nicht als einzelne Threads.

Der Umfang der Systemanalyse um das auf mehrere Threads aufzuteilen ist nicht unerheblich, da die einzelnen Prozessabläufe verfolgt werden müssen. Dann müssen die Elemente entsprechend angepasst und getestet werden.

Man muss da eben auch genau beachten, was man relativ einfach in eigene Threads packen kann, weil sie asynchron laufen, also nicht abhängig sind von anderen Sachen im Spiel, und welche synchron zum Rests gehalten werden müssen.

Jedoch ist es so, wenn diese Anpassung erstmal geschafft ist, dann bringt es ein wirklich großes Plus in der Serverperformance, was dem flüssigen Spiel sehr zugute kommt. Ich rede da nicht nur alleine davon, dass dann Redstone, Wasser und Lava ständig laufen können, sondern auch wesentlich mehr Spieler pro Server trotzdem möglich sind. Einer Verdoppelung ist da durchaus im Rahmen des möglichen bei absoluter Aktivierung aller Spielfeatures.

Aber es ist eben ein großer Entwicklungsaufwand.

Zitat von Olivaar

Ich fände es gut, wenn es ein paar Regeln für Performance schonendes bauen gäbe.

Manchmal sehe ich auf Plot Trichterstrassen, die einfach nur Items von A nach B transportieren,

obwohl man das mit einem Wasserkanal wahrscheinlich schonender bauen könnte.

Aber dazu fehlen mir die einblicke, was den Server mehr belastet

Also Flüssigkeiten gehen auch auf die Performance, aber deutlich weniger als Trichter. Man müsste den Leuten einfach nur klar machen, dass der Transport mit Wasser auf Eis auch wesentlich schneller ist, als Trichter.

Nachteil: Jeder der ins Wasser springt kann die Items abgreifen. Also muss man dort zusätzlich für Sicherheit sorgen, bzw. diese zu bauen.

Ich möchte alle mal auf die Änderung von Abge im Eröffnungspost hinweisen. Da hat er geschrieben, dass sich gerade ein Entwicklerteam formt um die Performance des Servers zu erhöhen.

In welcher Form es notwendig ist, Hardware anzuschaffen kann man so pauschal nicht sagen.

Dazu müsste man erstmal eruieren wie stark die Ressourcen überhaupt ausgenutzt werden.

Balancing über die Kerne, Reservierung von Speicher, Geschwindigkeit der GC, Threading, welche System sind betroffen (Flatfile, Datenbank, Caching,....)

Also ohne eine entsprechende Übersicht ist jede Diskussion müssig, da es nur auf Vermutungen basiert, es sei denn man setzt einen entsprechenden Server mal selber auf mit den entsprechenden Plugins, dass man das mal betrachtet. Jedoch hat man dann noch nicht die Last, welche auf GG erzeugt wird.

Und selbst dann wissen wir noch immer nicht, welche Hardware genau durch Abge eingesetzt wird. Um genaues auch da dann analysieren zu können, müsste man den genauen Prozessor wissen, die IPS des Prozessors, der genutzte RAM, ob ECC oder nicht und und und....

Es gibt also vieles zu beachten und aufzuschlüsseln und dann zu überlegen welche Schritte man geht.

Wie schon richtig erwähnt, muss es auch wirtschaftlich sein.

Klar könnte man Programmierer daran setzen die Probleme wie Luft inhalieren und den Code zur Lösung stumpf ausatmen, aber die wachsen erstmal nicht auf den Bäumen, dann kosten die auch entsprechendes Geld und auch Zeit.

Ich kann mir nicht vorstellen, dass GG so viel Geld abwirft mit allen Werbeschaltungen hier und bei Youtube, Instagramm und die Shopverkäufe, dass das einfach mal so zu stemmen ist.

1000,- Euro pro Tag, wenn man einen externen dafür anheuert kann da mal schnell ein Schnäppchen sein. Und das ist trotzdem eine Menge Geld für das eine alte Oma lange stricken muss.

Man muss also ein Balancing finden, welches einen vernünftigen Kosten-Nutzen-Faktor hat und das dann umsetzen.

Warten wir mal ab. Dass das beobachtet wird und der Plan da ist, etwas zu tun, kann man ja an Abges Posts erkennen. Wohin der Weg dann geht, wie die Lösung aussieht, das wird sich dann zeigen.

Abge von meiner Seite her können wir das gerne machen, sonst hätte ich es ja nicht angeboten zu unterstützen.

Müssen wir nur absprechen wann, dass auch alle Zeit haben.

Mir passt es eigentlich jeden Tag, so ab 20:30. Tagsüber lässt sich das auch einrichten, ausser am Wochenende, da dort die Familie vor geht.

Wie es bei H3llh4mm3r aussieht weiß ich natürlich nicht.

Sprich doch am besten mit deinem Team mal ein paar Termine ab und wir nehmen dann das, was allen am besten passt.

Wäre doch super wenn man gemeinsam eine Lösung findet.

Zitat von H3llh4mm3r

genau das gleiche habe ich quasi eine Seite vorher vorgeschlagen (nur vereinfacht dargestellt) und wurde mit "Unsinn" abgetan und technisch zu aufwändig.

Darf ich fragen was für ein MMO du "damals" mitgebaut hast (ich frage nur weil ich damals im Patchteam als Dev. von Gothic 3 war.

Ich hätte noch eine Idee Abge wie man zumindest die Redstone Problematik lösen bzw verringern könnte ohne es abzustellen.

1 Möglichkeit wäre, dass User ohne Rang (was mich dann ebenfalls betreffen würde) von natur aus Redstone deaktiviert haben auf ihren plots. Man kann sich aber ingame (oder halt im Shop) ein Kontingent an Redstone-Zeit kaufen.

Da würde ich grundsätzlich ansetzen wenn die Überlegung besteht - und damit komme ich zu Möglichkeit 2 eine Art "Stundenkonto" zur freien Verfügung anzubieten pro Tag - das man bspw. sagt: jeder Spieler (mit Rang) hat pro Tag (ich werf jetzt nur ne fiktive Zahl in den Raum) 2 Std. Redstone Nutzung die er bspw. per /redstone activate /redstone deaktivate an und ausstellen kann - wer zusätzliche Zeit benötigt (wären z.B. Mobfarmen können sich für ingame Geld oder im Shop) zusätzliche Zeit hinzubuchen.

Nunja wie auch immer, keine Lust mir noch ein Bügeleisen abzuholen deswegen klinke ich mich mal wieder aus hier - ich vertraue einfach darauf das das GG Team die Problematik angeht und hoffentlich lösen kann.

Alles anzeigen

Ich war mit an Neocron dran von ReaKKtor Media. Da war die Technik noch schwächer aber wir haben größere Mengen an Spielern pro Zone bewegen können. Und Java-Code ist in der Zwischenzeit nicht wirklich extrem langsamer als C++ wenn die erste Kompilierung durch ist.

Technisch gesprochen sind Deine Vorschläge von einer Seite her vorher kein Blödsinn. Ich bin wie gesagt den Code diesbezüglich mal durchgegangen und es ist möglich. Kostet nur Zeit und ein paar Kenntnisse bezüglich Multithreading, Synchronisierung, Mutexes, Scheduler und eben die Nutzung von Wrapper-Klassen.

Es ist Arbeit, klar.... Im Team sind laut der Übersicht 3 Devs..... Code auseinander genommen, GIT aufgesetzt, Tasks festgelegt und je nach Kenntnissen zugewiesen und dann successive umgesetzt, neuen Build für GG erzeugt und auf einem Testserver aufgespielt.

Ist ein normaler Entwicklungsprozess und so kann man es eben Schritt für Schritt umsetzen und das selbst wenn man begrenzte Zeit hat ohne den laufenden Prozess / Server zu stören.

Ist ein Feature umgesetzt und getestet, spielt man ihn eben dann nach und nach auf die Live-Server auf.

Das ist auch mit dem was im Eingangspost steht vereinbar.

Kurz mal zu mir, auch wenn ich es in einem anderem Thread schon geschrieben habe, in dem ich meine Unterstützung des DEV-Teams angeboten habe.

Ich bin ein alter Sack im Bereich IT und programmiere seit nun knapp 34 Jahren auf unterschiedlichen Systemen. Zur Zeit bin ich in einer Agentur beschäftigt und arbeite ständig mit Schnittstellen, Prozessen zu unterschiedlichen System und das hauptsächlich über PHP, ABAP und eben Java.

Selbst habe ich auch schon an Spieleprojekten mitentwickelt, unter anderem an einem MMO mit entsprechender Auslastung, die etwas über Minecraft hinaus geht / ging.

Ich habe mir in den letzten Tagen etwas Zeit genommen und unterschiedliche Ansatzwege verfolgt wie man das ganze angehen könnte um bestimmte Aufgaben in einzelne Threads auszulagern und so die Last auf einem einzelnen Prozessor zu verringern und diese auf andere zu verteilen.

Der einfachste Ansatz derweil, wie man Spigot bzw. einen Fork dessen dahingehend optimieren könnte, wäre einen Wrapper zu nutzen, der die Prozesse von Redstone und den Mobs in einen einzelnen Prozess jeweils kapselt, abarbeitet und zurück gibt.

Das was dann zusätzlich einfach noch eingearbeitet werden müsste, wäre die Funktionlaität die Prozesse synchron zu halten. Aber das sind Basics im Multithreading, bei denen Java eigentlich schon alles mitbringt was man dafür benötigt.

Zusätzlich zum, ich nenne es nun mal "Redstone-Controller" und "Mob-Controller" würde ich das gleiche noch für Lava und Wasser in Betracht ziehen.

Und als letzte Möglichkeit könnte man noch andenken, dass man die einzelnen CBs in Zonen splittet und in eigenen Threads laufen lässt. Man würde eine entsprechende Anzahl an Chunks in eine Zone packen und damit der Spieler keinen Übergang merkt noch die direkt angrenzenden Zonen mit in eine Verwaltungsinstanz packen. Wechselt er dann die Zone, wird die Spielerverwaltung an die entsprechnd andere Verwaltungsinstanz übergeben, die hauptsächlich für diese Zone zuständig ist.

Der Spieler würde davon nichts merken.... Es ist nur ein höherer Verwaltungsaufwand seitens des Servers, also diesen einzurichten.

Ein Plugin dafür würde ähnlich funktionieren wie das MV2 und müsste neu entwickelt werden.

Klar, das ist mit Zeit und Kosten verbunden, aber möglich wäre es. Es wäre eben wie das Streaming von Weltinformationen wie es in aktuellen MMOs verwendet wird.

Die Funktionalität der Plugins wäre nicht beeinträchtigt, da am Core, bzw den Schnittstellen nichts geändert würde.

Der einzige Nachteil ist dann, dass ein Update auf eine neue Version länger dauern würde, sollte man sich mal entscheiden von der 1.8.9 weg zu gehen.

Ich habe keine Ahnung wie gut die Entwickler von Dir sind Abge , ob sie sowas umsetzen können und wie weit deren Kenntnisse gehen.

Alternativ könnte man noch die komplette Verwaltung von Mobs, Redstone und der Flüssigkeiten auf einen externen Server auslagern, wenn die Verbindung untereinander nicht zu hohe Latenzen aufweißt, da die Package-Size relativ gerinig wäre, also die Bandbreite da keinen wirklichen Ausschlag geben würde.

Eine Abschaltung irgendwelcher Systeme, also Redstone oder Mob-Einschränkung würde ich nicht machen, da dies einige Mitspieler verscheuchen würde. Besonders wenn es sich um so elementäre Sachen geht.

Bei Redstone rede ich ja noch nichtmal von den automatischen Farmen sondern fängt es ja schon bei kleinen Sachen wie Türen und Druckplatten an.

Aber eventuell könnte man die Anzahl der Redstone-Elemente pro Plot beschränken. Dann könnte jeder es benutzen, es wären nur Giganto-Systeme nicht mehr möglich.

Übertragen vom realen Klimaabkommen könnten Spieler sogar dann untereinander Redstone-Kontingent handeln.

"Verkaufe 1 Stunde Redstone für 10k". /send redstone 1 {playername}

Zitat von Stefthemaster

Es kommt mir durchaus komisch vor, warum ein Clan, welcher dieses Event freiwillig (!) organisiert und großteils bezahlt hat, eine Entschädigung leisten sollte. - Es kann halt nicht immer alles glatt laufen, es waren 600 Spieler da, da knickt jeder Server mal ein.

Ich rede nicht von einer Entschädigung durch FTO. Finde es achtenswert, dass sie sowas machen.

Ich spreche hier eher Abge als Mitveranstalter an. Wenn dann diesbezüglich die Leute, welche auf dem Server verbleiben konnten (wie würde eigentlich definiert wer runter fliegt?), doppelt belohnt werden, sehe ich das doch als recht ungerecht an, da die vielen anderen, die sich ebenfalls für das Event "angestellt" haben, doppelt benachteiligt werden.

Wäre wie bei einem Konzert bei dem gesagt wird, das alle kommen können und dann wenn viele in der Halle sind, plötzlich die Hälfte rausgeworfen wird, obwohl sie eine Karte haben. Und anstatt, dass diese dann eine Freikarte für das nächste Konzert bekommen, bekommen es die, die eh schon in der Halle sind und die Musik genießen.

Zitat von Stefthemaster

Naja, der Server hat eh verdammt lange durchgehalten, dann ist er halt eingebrochen, und es gab auch für ca. 100 Spieler nochmal die Möglichkeit nochmal nachzukommen.

Und es hat ja jeder was vom Event bekommen, der teilnehmen konnte - wenn es nur das Geld von Bonze war.

Und die vielen die wollten und nicht konnten weil die Basis auf der es durchgeführt wurde einfach unterdimensioniert und schlecht geplant war?

Bei so einer Situation muss man sich als Veranstalter auch mal etwas Kritik annehmen.

Aufgrund dieser Schwierigkeiten wäre eine kleine, symbolische sollte reichen, Entschädigung angebracht.