Status Update #15 - Vorwort, ChestShop, Hopper Regeln/Optimierung

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

      Status Update #15 - Vorwort, ChestShop, Hopper Regeln/Optimierung

      Hey,

      weiter geht es mit ein paar mehr Infos zu den angedachten 1.12 Änderungen.
      Zunächst aber kurz etwas zu den Status Updates an sich:

      Vorwort

      Aus den Kommentaren des letzten SU sehe ich zumindest, dass die Status Updates zum Teil nicht als das aufgefasst werden was sie sind: Eine Beschreibung des aktuellen Fortschritts an Veränderungen der 'Plattform Kadcon'. Dabei werden Ideen und Überlegungen in ihrem aktuellen Zustand vorgestellt. Das bedeutet u.A.:
      • Im SU wird über unfertige Ideen/Ansätze geredet
      • Im SU wird der Zustand 'jetzt gerade' gezeigt, selbst eine 180° Drehung ist prinzipiell möglich
      • Im SU präsentierte Zahlen/Regeln sind gut überlegte Werte - haben aber keinerlei validierung durch User-Tests. Entsprechend können auch diese sich noch komplett ändern.

      Ich hoffe damit ist klar, warum eine Erwartungshaltung wie 'Sag bitte jetzt wie/wann genau XYZ sein wird' unrealistisch und themenfremd ist. Entweder interessiert man sich für die hier präsentierten Ideen und möchte daran mitdenken/mitgestalten und nimmt z.B. den Testserver in Anspruch oder man wartet geduldig ab. Speziell auf inhaltslose Beiträge werde ich daher auch normalerweise nicht reagieren. Inhalt im Bezug auf die Status Updates sind entsprechend Anregungen/Ideen/Vorschläge/Änderungen/Bug-Meldungen usw. - Dinge die das Thema weiterbringen.


      Auch möchte ich mich an dieser Stelle bei allen Spielern bedanken, die sich auf dem Testserver sehen lassen haben und etwas ausprobiert haben :thumbup: . Für die meisten Spieler ist die 'Baustelle Testserver' uninteressant (was absolut verständlich ist), daher helfen kleine Meldungen umso mehr. Danke an @wwtom, der einen weiteren Duping-Bug gefunden hat, welcher wohl in der 1.12 wieder funktioniert durch eine Änderung (hatte ich noch keine Zeit genauer anzusehen).

      Nun aber zum interessanteren Teil:

      ChestShop

      Die Anpassungen, damit das Mc-Repairlevel wie von Minecraft angedacht genutzt werden kann erfordert einigen Umbau, damit es verständlich ist.
      Aus diesem Grund sollen alle Reparierbaren Items einen klaren und einfachen Eintrag "Preiskorrektur: X%" erhalten. Somit ist auch für Spieler, denen "MC-Repairlevel" nichts sagt ersichtlich welche Qualität das Item noch hat.

      Weiterhin habe ich daran gearbeitet ChestShop mit dem Code für Trader zu kombinieren.
      Im Video kann man sehen, dass in Zukunft - wenn alles klappt - gezielt einzelne Items aus einem Shop gekauft werden können und somit die Spekulation über die Qualität des Items keine Rolle mehr spielt. Dabei wird die "F"-Taste genutzt, die glücklicherweise neu eingeführt wurde.

      (In MC kann man fast keine Tasten vom Server aus für neue Funktionen benutzen; wir können nicht einfach eine neue Taste o.Ä. nutzen, wir müssen immer bereits vorhandenes versuchen zu überschreiben. In diesem Fall wird das "Hand-Wechseln-Event" abgefangen in dem Fall, dass man gerade einen Shop ansieht. )





      Ich erwähne gerne mal, dass ChestShop relativ 'eklig' zu handhaben. Dies ist einer der Gründe, warum Anpassungen daran immer lange dauern und möglichst selten gemacht werden. Mittlerweile habe ich sehr viele Anpassungen an ChestShop vorgenommen und es wird auf längere Sicht wohl dazu führen, dass ChestShop komplett durch eine eigene Variante - nennen wir sie mal KShop - ersetzt wird. Dafür ist aktuell aber leider keine Zeit.




      Hopper Regeln

      Nun ein paar Informationen zu dem bereits angekündigten Thema: Hopper [ugly]

      Grundlegend ist schon seit einigen Monaten im Gespräch eine klares festes Maximum für Hopper-Anlagen zu definieren. Dieser Gedanke hängt aber immer schnell fest:
      • Redstone/Hopper/Sortieranlagen sind ein sehr wichtiger Teil von Minecraft. Wir sollten hier nur einschränken wenn es absolut sein muss.
      • Eine "feste Regel" ist nicht möglich. Sonst wäre einfach alles verboten: Siehe SU #8
      • Anlagen über 1000 Hopper sind prinzipiell 'niemals nötig', aber Punkt #1 macht klar, dass es eben Spaß macht sie zu bauen - und das wollen wir auch nicht verderben.

      Es wird daher auch nur eine unklare Faustregel geben: Zusammenhängende Anlagen mit über 500-1000 Hoppern laufen grundlegend immer Gefahr, dass sie umgebaut werden müssen sollte es Server-Performance-Probleme geben. Zusammenhängende ist hier definiert als: "Alles im Sichtfeld eines Spielers". Technischer: Alle Chunks, die durch die Anwesenheit eines Spielers ticken gelten als zusammenhängende Anlage.

      Warum ist diese Regel nötig?
      Pro Server können wir etwa 20.000 - 50.000 geladene Hopper*zur gleichen Zeit vertragen. Wir müssen die Gesamtmenge entsprechend niedriger halten als das. Auf S1 sind wir gerne mal am oberen Limit. Hauptgrund dafür sind einige wenige Anlagen mit 3000-6000 Hoppern. Ein einzelner Spieler kann hier also gerne mal 5-25% der Maximalmenge an Hoppern alleine geladen halten. Prinzipiell könnten also bereits 10 Spieler auf dem Server zur Vollast führen. Angenommen wir entfernen diese Großanlagen aus der Rechnung, dann bräuchte man direkt mindestens 40+ Spieler*.

      * Bitte beachtet, dass diese Zahlen stark vereinfacht sind und in der Realität viele weitere Faktoren hier mit einspielen wie die Nutzungsintensität, Aktivität, Last durch nebenläufige Prozesse usw.

      tl;dr: Es gibt keine neue Einschränkung für Hopper, die es bisher nicht auch schon gab. Siehe Regel 4.9


      Hopper Optimerung

      Durch die längeren Überlegungen zur oben genannten angedachten Regel habe ich auch noch mal genauer die Funktionsweise von Hoppern angesehen. Beispielhaft hier einige Werte zu einer Anlage auf S1 mit ~6000 Hoppern:

      In Vanilla MC: Trickt die Anlage demnach ~120.000 pro Sekunde (20 Ticks * 6000 Hopper). Dabei werden in dieser Anlage über 50.000 Events von Spigot/Bukkit generiert für mögliche Itembewegungen.
      In Kadcon: Ist die Funktionsweise etwas umgebaut. Daher Tickt die Anlage etwa 6000 mal pro Sekunde und generiert ~2200 Events.

      Diese Verbesserung von etwa 90-95% erreichen wir auf Kadcon darüber, dass alle TileEntities in einem besonderen für Kadcon gebauten Manager verwaltet werden. Dabei werden die Hopper seltener als 1x pro Tick aktiviert und mehr Items auf einmal bewegt. Eine Verbesserung von 95% hört sich hier wunderbar an - aber sie reicht eben nicht. Im normalen Minecraft reicht eben bereits diese einzelne Sortieranlage mit 6000 Hoppern um den Server-Prozess zum stocken zu bringen - mit nur einem Spieler online :poop:
      Bei einer 95% Verbesserung heißt dies eben: Wir brauchen dann 15-20 solcher Anlagen und es laggt wieder. :|

      Diese Änderung hat aber auch Nachteile - bei jeder Änderung an Minecraft müssen alle Stellen neu geprüft werden, ob vielleicht etwas geändert wurde. Viel Aufwand bei jedem Minecraft Update. Aus diesem Grund muss man bei jeder Änderung an Minecraft selber immer drei mal überlegen ob es sich lohnt und wie viel Arbeit es in Zukunft bereiten wird. Dieser Gedanke ist auch sehr wichtig bei der aktuell geplanten/getesteten Änderung und mit ein Grund warum sie auch komplett wegfallen könnte.

      Funktionsweise bisher


      Hopper funktionieren sehr 'einfach' in Minecraft. Jeden Tick wird erneut geprüft ob etwas getan werden kann - das wars prinzipiell schon. Dies bringt natürlich Probleme mit sich, wenn die Anzahl immer weiter steigt. Zwanzig mal 6000 Hopper die Sekunde prüfen kostet sehr viel Zeit. Daneben gibt es dann noch weitere kleinere unschöne Arbeitsweisen der Hopper. Beispielhaft werden immer erst Items aus dem Hopper genommen und danach geschaut ob sie in das Nachbar-Inventar passen. Passen sie nicht werden sie zurück in das Original gelegt.

      Funktionsweise der Optimierung
      (Für Spieler soll alles wie immer funktionieren - das ist die Grundvoraussetzung)

      Der Ansatz hier ist einfach und lehnt sich an die auf Kadcon bereits vorhandene Optimierung an. Statt jeden Tick alle Hopper zu ticken und zu prüfen muss die Menge an Prüfungen stark reduziert werden. Die bisherige Optimierung verlangsamt die Prüfungen und erleichtert so die Arbeitsmenge. Bei der aktuellen Optimierung soll die Prüfung an sich stark verbessert werden.

      Um die Prüfung zu Verbessern muss sie möglichst schnell ohne viele Vergleiche erledigt werden - wie bekommt man das hin?
      Ein Hopper hat maximal einen Eingang und einen Ausgang. Es gibt also nur begrenzt Möglichkeiten was passieren kann.
      Weiterhin muss man darüber nachdenken, dass Hopper zu 99+% der Zeit prinzipiell nichts tun. Entweder sind sie leer und es gibts nichts was sie tun könnten oder sie könnten etwas tun aber die Kiste, an die sie etwas weitergeben könnten ist voll.


      (A im Bild interagiert letztendlich passiv mit B (aus der Sicht von B), daher kann man es außer acht lassen bei der Kalkulation; nur der Zustand zwischen zwei Dingen ist relevant)


      Genau hier setzt die Optimierung an - bei den 99+% nutzlosen Prüfungen weil sich nichts verändert hat. Jeder Teilnehmer (Hopper, Kiste, ...) bekommt zwei neue Variablen: Zeitpunkt der letzten Änderung und Zeitpunkt der Letzten Änderung am Ziel. Das Ziel ist bei einem Hopper was auch immer "unten drunter ist" und bei einer Kiste könnte es z.B. der darunter hängende Hopper sein.
      (Aktuell arbeite ich nur mit Hoppern; Kisten lasse ich bisher außen vor bei den Tests)

      Mit diesen beiden neuen Variablen ist es möglich fast alle bisherigen Prüfungen zu überspringen, indem am Anfang einmal geschaut wird:
      "Habe ich mich verändert seit der letzten Prüfung? - Hat sich mein Ziel verändert seit der letzten Prüfung?"
      Wenn beides mit Nein beantwortet werden kann ist keinerlei Prüfung nötig, da nichts gemacht werden kann.


      In ersten Tests hat dies die oben genannten 50.000 Events/Sec in Spigot bzw ~2200 Events/Sec auf Kadcon auf 20-30 Events/Sec reduziert. Oder auch weniger als 0,1% der Spigot-Last. Vergessen darf man hier aber nicht, dass es sich bei dieser Anlage um einen Sonderfall handelt. Wie viel diese Optimierung am Ende im Normalbetrieb bringen wird ist völlig offen. Wenn beispielsweise Hopper eh nur 1% der Leistung verbrauchen würde man am Ende eben auch nur maximal 1% einsparen können.


      Praktische Optimierung im Bezug auf Update-fähigkeit und minimale Anpassung


      Wie oben erwähnt ist eine der Schwierigkeiten, dass jede Änderung am Originalcode nachträglich Probleme bringen kann. Das Ziel bei solchen Änderungen ist daher immer mit möglichst wenig Eingriff eine akzeptable Optimierung zu schaffen. Sollte sich am Ende herausstellen, dass diese Änderung Anpassungen an zu vielen Stellen benötigt, so wird sie am Ende wohl eher nicht aufgespielt werden.



      Update Status 1.12

      Im Teil zum ChestShop kann man erkennen, dass ich mir einiges mehr an Zeit genommen habe um dies besser verständlich und nutzbar zu machen. Ohne diese Anpassungen wäre das Update wohl heute/morgen aufgespielt worden. Ich habe mich aber dazu entschieden, dass dies eine Änderung ist die ich zu Beginn der 1.12 haben möchte und nicht erst in den Tagen/Wochen darauf. Das Update verschiebt sich daher mindestens um die Zeit, die es dauert dies genügend getestet zu haben. Daneben wurden einige Bugs gemeldet, die ich bisher in ihrem Umfang noch nicht einschätzen kann. Aktuell würde ich wieder Sonntag auf Montag anstreben - mal schauen welche Stöcker ChestShop mir noch in den Weg wirft.


      Kade
      Bilder
      • shoplog.jpg

        105,7 kB, 880×151, 1.498 mal angesehen
      • theorie.png

        53,42 kB, 349×200, 1.478 mal angesehen
      Dateien
      • shopping.webm

        (984,62 kB, 1.394 mal heruntergeladen, zuletzt: )
      blog.kadcon.de
      Bitte möglichst alle Fragen im Forum stellen und nicht mir per Privatnachricht.
      @TimoSpeyer

      Guter Punkt und das muss ich definitiv noch genauer ansehen. Technisch gesehen ist dies aber glaube ich nicht relevant für die Lösung, da der jeweils aktive Teilnehmer die Prüfung macht und deswegen immer eine 1:1 Betrachtung funktioniert. Aber ausschließen, dass dieser Punkt noch große Probleme machen kann werde ich mit Sicherheit nicht - das lernt man relativ schnell beim Programmieren :rolleyes:

      Die Formulierung ist nicht gut gewählt. Besser wäre wohl etwas wie "Ein Hopper interagiert von sich aus immer maximal mit zwei anderen Entitäten".

      Kade
      blog.kadcon.de
      Bitte möglichst alle Fragen im Forum stellen und nicht mir per Privatnachricht.
      @SuracCarpeDiem

      Man kann es normal und über das Fenster kaufen, ist auch bei allen Items so möglich.

      Das mit den Mengenangaben ist ein wichtiger Punkt, aktuell kauft man die Menge von dem Item was in dem Slot liegt.
      Ich denke am Ende wird es so sein das man die Anzahl vom Shopschild kauft und wenn man öfters klickt erhöht sich die Anzahl wie
      beim normalen Shopschild.

      Was ich jedem Empfehlen kann ist mal auf den Testserver zu kommen und es zu testen.

      jambo



      Um das "Inventar Shopping" in speziellen Shops zu deaktivieren könnte man einen Extrabuchstaben irgendwo auf das Schild schreiben.
      z.B.:
      Name
      1 x
      B 1: S 1
      1

      Das "x" in der zweiten Zeile des Schildes zeigt dem Shopschild, dass das "Inventar Shopping" hier deaktiviert ist.
      Ich kenne mich mit der technischen Umsetzbarkeit nicht aus, stelle mir das jedoch so vor: In der Shopschild Erkennung wird eingebaut das es ein extra X in der zweiten Zeile ignorieren kann. Es wird vor dem ausführen von "Inventar öffnen" gecheckt ob sich in der zweiten Zeile ein X befindet, wenn ja: Abbrechen und Text ausgeben: Hier ist ... deaktiviert.


      Generell zu dem System kann ich nur sagen super geil :D
      :KadConLogo:

      Stolzer S1ler, zu etwas über 7% Ninjapanda

      :!: Hier kommt etwas hin. Irgendwann. Eventuell. Wahrscheinlich. :!:


      Dir gefällt nicht was ich schreibe?


      Dann wende dich bitte an deine Katze oder einen inaktiven Spieler deiner Wahl

      YeY, noch eine Woche Zeit bekommen, um meine Farm zu vollenden...

      Hoffe nur, dass es keine Pistonlimit überschritten Blöcke werden .---.

      Ansonsten zu dem Chestshop Dingen...

      *thumpsup*

      //Master

      Edit: Kade kannst dir ja meine PN nochmal angucken, aber die hat sich jetzt so ziemlich geklärt. ^^

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Masterrar42“ ()

      Mir kommt da grad so ne waaahnsinnige Idee (wahnsinnig in der hinsicht das dies wahrscheinlich noch mehr umprogrammieren bedeutet):
      Wie wäre es denn wenn man die mengenangabe vom schild wegnimmt und dieses system zum kompletten verkaufen und kaufen nimmt.
      Also mach ich z.b. rechtsklick auf das verkaufsschild bzw linksklick geht dieses "pseudoinventar" auf und man kann items die man verkaufen möchte (die natürlich auch an der kiste angekauft werden) einzeln oder über die serverbefehle verkaufen. (also shift linksklick für einzelne stacks und shift+rechtsklick für ganzes inv bis die kiste voll ist)

      Noch weiter gedacht könnte man die zu clientlaggs führenden schilder komplett rausnehmen und über den befehl /shop create Noitari(oder leer),64,b1:s1,? die kiste die man anvisiert als shopkiste definieren und mit /shop close die kiste die man anvisiert die kiste wieder als normale kiste definieren.

      Glaub das würde noch einige laggs dezimieren und vllt könnte man das in betrachtung ziehen wenn man eh ein eigenes shopplugin programmiert ;)
      PS: Mengenangabe wegnehmen fällt mir grad so auf is ja völliger blödsinn, man muss ja auch wissen wieviele items was kosten XD
      Dementsprechend auch den befehl angepasst.
      I ben en schwob, i ko ellet außer hochdeutsch, deschdeweg kannsch die bechstabenverwuchsler, die de findsch gern behalte und an'd wand nagel'n ;)

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Noitari“ ()

      @Masterrar42

      Genau das Shop-Menü ist noch mitten in der Bearbeitung - es gibt fast keinen Code der Fehlerfälle abfängt. Beispielsweise Hotkeys usw. provozieren auch alle Fehler und während ich selber am Umbauen bin (ich teste live auf S2) gibts auch zwischenzeitlich gerne mal Duping-Bugs usw. dauert noch etwas bis es "nutzbar" ist ^^

      Kade
      blog.kadcon.de
      Bitte möglichst alle Fragen im Forum stellen und nicht mir per Privatnachricht.
      hi erst mal danke für die infos aber 1 frage hätte ich noch auch wen sie warscheinlich nicht so relevant ist warum werden bitte mosaik blöcke 20x teuer(mehr kohle benötigen ) als in vanilla was ist der grund/die idee dahinter es teuer zu machen wäre einfach schön zu wissen welche beweggründe du hattest dies zu tun ansonstem noch mal vielen dank

      zooaffe110 schrieb:

      20x teuer


      Ich Besserwisser muss das sagen: Nicht 20x teurer, ~160 mal mehr Brennkosten ^^ :P

      (normal kann eine Kohle acht Items brennen. Wenn ca. 20 Kohle benötigt werden, ist dies 20x8)
      :KadConLogo:

      Stolzer S1ler, zu etwas über 7% Ninjapanda

      :!: Hier kommt etwas hin. Irgendwann. Eventuell. Wahrscheinlich. :!:


      Dir gefällt nicht was ich schreibe?


      Dann wende dich bitte an deine Katze oder einen inaktiven Spieler deiner Wahl

      Hopper-Brainstorming (ein paar Ideen):

      (vorab: Bei den neuen Einstellungen zu "wann war ich zuletzt aktiv" etc. bitte auch bedenken, dass Hopper auch Items aufnehmen können (und sollen), die man auf sie drauf wirft oder die per Wasserleitung zum Filter hintransportiert werden. Über dem Filter befindet sich nicht immer ein "gerade aktualisierter Container"!)


      Eine Sortieranlage benötigt heute drei Hopper pro Item und zusätzlich noch Redstone-Technik. So wie Dispenser auf Kadcon ein neues Feature erhalten haben für Animal-XP, könnte man auf andere Art vielleicht ein neues Feature einbauen für Hopper, so dass sie Items Filtern ähnlich wie ein Diamantrohr in Buildcraft minecraft-de.gamepedia.com/Mod…BuildCraft#Transportrohre
      • In einem als "Filter" eingestellten Hopper lassen sich bis zu fünf verschiedene Items platzieren. Alle dort platzierten Items werden vom Trichtereingang herausgefiltert und direkt an den Ausgang des Filters weitergeleitet.
      • -> direkte Reduzierung der Hopper von drei pro Item auf zwei pro Item (ein Hopper für den Filter und ein Hopper für die Leitung darüber)
      • -> weitere Reduzierung der Hopper dadurch, dass Spieler vielleicht nicht mehr jedes Item komplett separieren, sondern z. B. für alle Netherquarz-Blockarten eine einzige Kiste und somit nur einen einzigen Filter verwenden.
      • -> neues Kadcon-Feature könnte dabei auch sein, dass man zukünftig auch nicht-stackbare Items damit sortieren kann (Werkzeuge etc.). Dies könnte auf der anderen Seite die Anzahl Hopper wieder erhöhen.


      Zur Funktionsweise für den Spieler könnte ich mir das z. B. so vorstellen:
      • Wird ein Hopper platziert, so ist es ein ganz normaler Hopper.
      • Legt der Spieler ein oder mehrere Items per Rechtsklick-Menü im Hopper ab, so ändert sich seine Funktion sofort auf "Filter".
      • Im "Filter-Modus" ändert der Hopper sein eigenes Inventar nicht (niemals). Ist über dem Eingang ein Item, dass einem Filter-Item entspricht, wird es (ohne den Filter zu "betreten") direkt an den Ausgang des Filters weitergeleitet. Somit bleiben die vom Spieler vorgenommenen Filter-Einstellungen unverändert.
      • Nimmt der Spieler alle Items per Rechtsklick-Menü wieder aus dem Hopper heraus, so ändert sich seine Funktion sofort wieder auf "normal". Gleiches gilt, wenn der Hopper abgebaut/gesprengt etc. wird.


      Wo könnte es Probleme geben?
      • Wenn ein Spieler aus irgendeinem Grund Items in einem Hopper platzieren will, ohne den Hopper zum Filter zu machen, so müsste er eine Kiste darübersetzen und die Items in den Hopper saugen lassen und die Kiste danach wieder abbauen. -> kein großes Problem
      • Wenn ein Spieler aus irgendeinem Grund Items in exakten Mengen und an exakten Positionen im Hopper platzieren möchte (so wie das bei den heutigen Sortier-Filtern der Fall ist), so wäre das bei Umsetzung des oben stehenden Vorschlages nicht mehr möglich. Mir fällt andererseits aber auch kein Grund ein, warum ein Spieler dies noch machen wollen würde, da es ja die bessere Funktion zum Filtern schon gäbe. -> Daher sehe ich hier ebenfalls kein großes Problem.
      • Es ist für mich nicht überschaubar, wie viel Performance die Prüfung des "Filters" nach bis zu fünf zu filternden Items benötigt.
      Schock deine Eltern: Lies ein Buch!
      (Fratzenbuch? Nein danke ...) (... und auch kein whatsdreck!!!)
      Diese Antwort in dem anderen SU wäre die gewesen die wir wollten. Bezüglich der Shops. Zwar sind noch weitere Fragen ungeklärt aber naja.

      Wichtiger Punkt.

      Du sagst vllt nächsten Sonntag. Wäre es nicht besser dann noch eine Woche zu warten und das Ding am Freitag den 11.8 so gegen 17 Uhr rauszuhauen. Gedanke dabei ist einfach. Auch wenn viele Ferien haben und jung sind, trifft das nicht auf alle zu.
      Gerade da kadcon ein Wirtschaftsserver ist wäre es füe die arbeitende Bevölkrrung sehr unfair. In meinem Fall wären das fast 24 Stunden in denen ich die neuen Items nicht produzieren und verkaufen kann.

      So wäre es mit einem Start am Anfang des Wochenende für denk ich mal den größten Teil der Spieler Möglich "dabei" Zu sein.
      Wie schon bei den letzen Updates festgestellt wurde wirst du nie einen genau passenden fairen Zeitpunkt für alle finden.
      Der von dir vorgeschlagene Freitag wäre sehr unfair für alle die Samstags arbeiten, oder Samstags in den Urlaub fahren, oder oder.
      Für mich zum Beispiel wäre Montag toll, denn ich muss bis Sonntag immer in den Spätdienst.

      Kade soll mMn das Update dann raus hausen, wenn er meint, dass es stabil genug für die Server ist.
      Diejenigen die "Nachteile" haben haben einfach Pech . Wie gesagt inklusive mir, damit muss ich, müssen die anderen einfach leben.

      mfg
      Markus

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Harlekinz“ ()