Beiträge von scumsaecke.de

Dem kann ich nur zustimmen. PP ist ein hervorragender Serverprovider mit extrem kurzen Reaktionszeiten.

PingPerfect hat für uns, total flexibel, einen Root bei Hetzner gemietet und da ihr GamePanel aufgespielt.
Auch alle anderen Wünsche wurden ohne zu murren umgesetzt. Die Geduld der lieben Menschen da, ist atemberaubend.

Besonders gut gefällt mir, dass man sehr persönlich behandelt wird und jede Antwort handgeschrieben ist und nicht aus Textbausteinen besteht - die nicht zur Frage passen.

Allerdings muss sich jeder im Klaren darüber sein, dass man mit PingPerfect NICHT auf deutsch kommunizieren kann.
Ihr solltet also der englischen Sprache mächtig sein, besonders wenn es technisch wird und/oder Probleme beschrieben werden müssen.

Es gibt einen Punkt, den ich als negativ bezeichnen würde:
Jeder, der sich bei PP einen Server holt, muss seine Updates manuell anstoßen.
Man muss also immer auf dem Laufenden bleiben und sollte, wenn möglich, auch von Arbeit aus die Möglichkeit haben, ein Update anzustoßen.
(Natürlich kann man das auch innerhalb der Comm managen, wenn ihr so viel Vertrauen habt)

grüße
phil

Es geht auch nicht um das Konvertieren... Es geht darum, dass man allgemein erst einmal die Möglichkeit dazu hat, einen Teil-Wipe zu machen.
Wenn die Chars bei einem Update mit gewiped werden müssen - bitte - dann ist das so.

Es geht aber darum, dass man als Server auch so mal einen Wipe machen kann ohne direkt den Stammspielern den gesamten Fortschritt zu nehmen. Unabhängig von Updates oder was auch immer.

Zitat von Jaxx Diablo

Das Thema Skill-Anpassung fände ich auch extrem wichtig. Es sind mir auch schon Spieler nach einem Wipe abgesprungen, weil sie keinen Bock hatten wieder alles hochzuskillen. Dass man seine Base neu bauen muss und gesammelte Gegenstände weg sind, können alle meist verschmerzen, ja sagen sogar, dass e Zeit für einen Umzug wurde, aber dass man manche Sachen dann eben lange nicht bauen und/oder craften kann, akzeptieren sie nicht.

Auch zu Recht, denn nur wegen einem Server-Wipe habe ich nicht Schießen oder Autofahren verlernt.

Eine Realisierung ist sicher leicht möglich - ähnlich den Ruhmpunkten. Problematischer sehe ich hier das "BackUp" der Skills. Nach einem plötzlichen Wipe durch Update können sie mir viel erzählen was sie denn für Skills hatten

Diese Möglichkeit wäre furchtbar und in der Serverrealität absolut kontraproduktiv, besonders bei relativ hohen Spielerzahlen...
Zb. kann ich jetzt als Admin bei einem Boxevent teilnehmen - ohne dass mir jemand vorwirft, ich hätte mich "geboostet"...

WENN, dann so machen, dass man bei einem Wipe die nackten Charaktere behalten kann - mit ihren Stats. Also ein reiner Map-Wipe ohne Char-Wipe. Aber Char-Edit per Befehl - sry, no way...

Grüße
Phil

Zitat von Mike-312

Man kann doch mit 4 in der Gruppe (Squad) spielen. In Zweifel eigenen Server mieten.

Und hier beginnt das überaus lukrative Geschäftsmodell der nicht freigegebenen Serverfiles.

Solche Spiele sind derzeit schon fast seuchenartig zu finden. Ich finde, hier sollte GamePires anders sein und endlich einen anderen Weg gehen.
Und auch wir als Community sollten die Spieler lieber auf die Server einladen oder ihnen welche empfehlen, anstatt ihnen zu raten einen eigenen Server zu mieten, der dann in paar Tagen nur noch vor sich hintümpelt... Teilweise haben wir ein Spieler/Server Verhältnis von 0,6! Also durchschnittlich 0,6 Spieler pro Server.

Und solange ständig kleine Server dazukommen und für ausreichend Cashflow bei Hostern und Entwicklern sorgen, werden wir NIEMALS die Serverfiles sehen...

Grüße
phil

Leider nicht. Mein Client loggt noch immer so viel und der Prodiver löscht nun regelmäßig unsere Logs auf dem Server. Zusammen mit Neustarts aller 2h haben wir für uns einen Workaround gefunden.

Grüße
phil

Hallo ihr Lieben,

wir haben folgendes festgestellt:

Haben wir unter 25 Spieler, können wir den Server quasi lagfrei 12 Stunden durchlaufen lassen - ohne Probleme.
Geht die Spielerzahl allerdings über 30 oder höher, ist es nach 2 1/2 Stunden bei uns nicht mehr möglich, auch nur eine Tür zu öffnen. (Disconnects ohne Ende, extreme Lags, Fatal Errors, usw usf. Aber En Mass!
Nun kommts - Nach dem Neustart gibt es mit gleicher Spielerzahl an der gleichen Stelle keine Probleme.

Seit dem letzten Patch beginnt das Rubberbanding um Einiges später (geile Sache) - am Lag-problem hat sich trotzdem nichts geändert.

Für uns stellt, erst einmal, der Neustart aller 2h einen Workaround dar.
Konntet ihr änhliches beobachten?

Grüß
phil

sooooo, es gibt Neuigkeiten.

Viele der Tests waren unnütz, aber einige haben auch zu Erkenntnissen geführt.

Also fassen wir zusammen:

- Wir haben viel aus der Welt entfernt - bzw die Spieler in Eigeninitiative.
- Der Hoster musste nach seinen Aussagen "immense Logs" löschen.
- Kurze Neustartintervalle verbessern die Serverperformance signifikant (heute mit 2h Abständen probiert)
- Mein Client haut tausende Zeilen Logs pro Stunde raus und speichert sie in AppData (übrigens sehr interessant, wieviele Fehler es in der Engine gibt...)

Meine Vermutung: Wurde vor Release des letzten Updates evtl. ein Log-LvL nicht deaktiviert und Server und Client laufen in einer Art Debug-Mode?

Grüße
phil

P.S.: An der Multi-Core Sache bleiben wir natürlich dran und berichten ebenfalls.

Hallo Hyperion, da verwechselst du etwas.

diese beiden Parameter haben nichts mit den Items zu tun, welche man auf den Boden wirft. Was ja die Ausgangsfrage war. Darauf hat man (derzeit) wirklich keinen Einfluss.

Darum habe ich es auch hier
RE: Diskussionsrunde zu V0.7 von SCUM
als Verbesserungsvorschlag mit angebracht.


Grüße
Phil

Leider nicht. Solange der Bereich wo der Loot liegt, nicht über mehrere Minuten vom Server entladen wird, bleibt das Zeug ewig liegen.
Ist also die ganze Zeit ein oder mehr Spieler in der Nähe, kann man Items auch 12h rumliegen lassen.

grüße
phil

Ich erhoffe mir sehr viel im Backend des Spiels.

Zb. ein paar Stellschrauben in der Config, wo ich entscheiden kann wie weit die Clienten auf unserem Server diverse Entitys vorladen, zur besseren Resourcenverwaltung.

Beispielsweise muss ich keine Spielerbasis, Gegner oder Fahrzeuge in 500m oder mehr Entfernung sehen, wenn wir doch einen PvE Server spielen.
Da reicht locker die Hälfte um Resourcen zu sparen - dafür haben wir naturgemäß mehr Basen und Items, was wieder zu einem Ausgleich führt.

Hier noch ein paar Punkte von mir/uns aus anderen Threads.

Darunter:

- Spieler-Schlösser knacken an/aus

- Option zur unsichtbaren Safezone (ohne farbigen Schleier)

- Optionen zur Änderung der Priorisierung der Entity-Ticks (speziell für dedi-server)

- LockPick Log

- Public Door Claim an/aus

- Wettereinstellungen (war schon vorhanden)

- Wipe Möglichkeiten für einzelne Fahrzeugarten (zb alle Boote löschen)

- Schubkarre craften an/aus

- Looteinstellungen (Verteilung zwischen militärisch und zivil, essen, Medizin, usw)

- separate Polizeiautos (Config-Trennung vom SUV)

- Famepunkteverfall (einstellbar) (zb minus XX Famepunkte / Tag)

- einstellbarer Loot-Despawn (getrennt in Zombieloot/Spielerloot/usw)

- Bereich für XX Minuten aktiv halten um Leichen-Despawn eines Spielers zu verhindern

- Automatisch Türen in Ortschaften schließen, wenn der Bereich vom Server entladen wird (Spieler verlässt Bereich)

- Türen-Reset (alle zu), wenn Bunker vom Server entladen wird (Spieler verlässt Bereich)

- Mehr Fahrzeuginfos für Admins - z.B.: welche ID hat man eigentlich gerade vor sich stehen?

- Maximale Famepunkte einstellbar (cap von 1k)

- Zeitgesteuerte Nachrichten an die Spieler. (Neustart, Events, Regeln, usw)

- Fahrzeug Einstellungen zu Health, Geschwindigkeit, Schaden, usw
- Fahrzeug- Crashschaden vom Spielerschaden trennen und einzeln konfigurierbar machen

- Entkopplung der Schadenseinstellungen (PvP) von den Events (mit Blick auf PvE Server)
- getrennte Despawnzeiten für die jeweiligen Fahrzeugtypen

Ganz wichtig wäre eine dosierbare Rechteverwaltung in der Administration

Jetzt gibt es nur:

"Steam-ID [godmode]" oder "Steam-ID"... quasi alles oder nichts...

Wie wäre es stattdessen mit:

[is] = Item Spawn

[vs] = vehicle spawn

[an] = announce

[dr] = Drohne benutzen

[bu] = build (jetziger "GODmode")

[te] = teleport

[ve] = vehicle edit

[god] = Alle Rechte

Hier ein Beispiel:

Steam-ID[god] <- ein Administrator mit allen Rechten

Steam-ID[is][an][te] <- Ein InGame Moderator mit paar wenigen Rechten

Steam-ID[dr][te] <- Spieler Checker

Steam-ID[vs][ve] <- ein einfacher Autohändler

Am Liebsten wäre es mir, wenn man für jeden Befehl eine eigene Variable in form von [XX] hinter die SteamID schreiben müsste. Besser und genauer dosierbar geht es nicht.

Was nun durch die umfangreichen Skillmöglichkeiten sinnvoll wäre, wäre die Möglichkeit einen Kartenwipe durchzuführen, aber die reinen Chars (nackt) mit allen Skills bestehen zu lassen.

Grüße
Phil

Du kannst es auch so machen, dass exakt 60 Sekunden nach der Einblendung oben rechts, der vorhergehende platzt.

Nehmen wir eine Platzperiode von 15 Minuten an, also exakt 4 Stk in der Stunde... Dazu nimm folgendes:

Schreibe in die beiden oberen Felder (Time between events) "14" rein.
Nun nehmen wir 30 Sekunden Verzögerung + 30 Sekunden Fallen + 840 Sekunden Standzeit = 900 Skeunden (15 Minuten) von der Ankündigung bis zum Platzen.

Grüß
phil

Möchtest du nun mehrere Drops da haben, musst du die Zeiten entsrechend anpassen.

Beispiel:
Zur Vereinfachung fassen wir die beiden ersten Werte zusammen und nennen sie "Zeit zwischen den Events".

Schreibe also bei beiden mal 5 rein, was 5 Minuten bedeutet (nur diese Werte werden übrigens in Minuten eingetragen, alle anderen in Sekunden).
Du bekommst nun aller 5 Minuten oben rechts die Einblendung, dass ein neuer Airdrop in XX Sekunden/Minuten auf die Insel fällt.

Das Ding steht nun winzig klein am Himmel und wartet. Ab jetzt kommt Wert XX, der "Cargo Drop Fall Delay", also die Verzögerung des Fallens.

Schreibst du nun zb. "150" (in Sekunden) da rein, bleibt er 2 1/2 Minuten am Himmel, bevor er fällt... (Die Zeit, wo sich Leute auf den Weg machen können)

Der Nächste Wert ist die "Fall Duration", das ist die Dauer des Fallens selbst. Also wie lange braucht er nach Ablauf des "Fall Delay" bis er den Boden erreicht. Schreibe zum Beispiel 30 ( Sekunden ) da rein.

Der Letzte Wert "Self destruction time" ist die Zeit, welche im Drop auf dem Display steht - bis er platzt.
Schreibst du hier "1200" rein, was 20 Minuten entspricht, hast du immer gleichzeitig 4 Airdrops am Boden stehen, da die "Zeit zwischen den Events" ja 5 Minuten war und alle die gleiche Warte- und Fallzeit haben.

Änderst du nun den 2. Wert auf zb "10" Minuten, hast du immer 2-4 Drops auf der Karte, denn es kommt aller 5-10 Minuten (zufällig) ein Drop, der dann immer 20 Minuten am Boden bleibt.

Sollte dir das nicht weiter helfen versuche bitte zu erklären was dein gewünschtes Ergebnis ist, die Werte bekommst du dann.

Grüße
phil


immer 4 lootbare Drops:
5
5
150
30
1200

immer 2 lootbare Drops:
10
10
150
30
1200

Immer 2-4 lootbare Drops
5
10
150
30
1200

Zitat von Laborratte

Also ich bin inzwischen bei den Grafikeinstellungen bei knapp über Minimumeinstellungen angekommen, um die aktuel lausige Performance auszugleichen. Dennoch hatte ich in der großen neuen Ferienanlage einen FPS Drop, der es mir fast unmöglich gemacht hat wieder aus der Stadt zu kommen. Dazu kam dann noch ein weiterer Bug bei dem der Kamerawinkel während des FPS Drops beim fahren einfriert, das hat sich erst wieder gefangen als ich in einer total bescheuerten Perspektive dann mit Nachtsicht und mit ettlichen Zombies im Schlepptau mit gefühlten 5 kmh langsam aus der Stadt gekrochen bin. Klar ist meine Grafikkarte GF 1050 Ti mit 4 GB VRAM als momentaner Flaschenhals nicht optimal, aber auf nahezu Minimumeinstellungen sollte es doch dennoch spielbar sein. Zudem haben Kollegen mit Grafikkarten mit bis zu 8 GB VRam das selbe Problem, und meine restlichen Komponenten, ein Rayzon 7 mit 32 GB 3200 DDR4 Arbeitsspeicher und einer M2 sollten ja wohl reichen. Bei den momentanen GraKa Preisen will ich halt noch abwarten ob es sich wenigstens im laufe des nächsten Jahres etwas beruhigt, denn ich sehe es nicht ein fast 2000 Euro für eine vernünftige Grafikkarte auszugeben, nur das ich dann bei nem FPS Drop dann bei 50 anstatt bei 19 FPS lande. Bis ich dann eine neue GraKa habe, möchte ich das Game wenigstens in schlechter Auflösug flüssig spielen können, sowas muss doch durch mögliche Optionseinstellungen machbar sein.

Das ist natürlich ärgerlich, hat aber mit den Servereinstellungen und der atm schlechten Performance der Server nichts zu tun.
Empfehlen kann ich dir die 6700XT, was das derzeitige P/L Verhältnis angeht. Klar, es sind auch 1.000€, aber mit der 1050Ti wirst du durch die 4GB nicht froh.

Scum mit mittleren Einstellungen auf 1440p braucht bei mir ca 11GB VRAM.

Auch Spieler mit 8GB haben ihre Einstellungen zu hoch angesetzt. Die Karte muss ständig fertig gerenderte Gegenden und Objekte droppen und dann neu nachladen. Kommt sie da mal nicht hinterher, fallen instant die FPS oder noch schlimmer, man fällt in eine komplett ungeladene Gegend.

Leute mit meiner Grakaleistung und Generation überschätzen ebenfalls ihre Karten und wählen die Einstellungen zu hoch. Das ist bei anderen Spielen auch kein Problem - aber hier fehlt eine Fehlerbehandlung in der Engine und sie rattert gnadenlos weiter bis an der GPU nix mehr geht.
Nochmal zum Vergleich. Ich spiele auf einer 6700XT mit Ryzen 5700X, 32GB, PCIe 4 SSD (980 pro) in 1440p. Selbst da lasse ich die Einstellungen wie sie sind und drehe nix rum. Da ich sowieso ständig die SaveFiles zum Testen lösche.

Zum Server:
Der Server hat heute wieder zuverlässig ab 40 Spieler angefangen, die Spieler reihenweise vor die Tür zu setzen. Es ist als ob man einen Schalter umlegt. Startoptionen, Fehlersuche und andere Bemühungen, haben bis jetzt leider nichts gebracht.

Wir bleiben trotzdem dran und berichten weiter

Grüße
phil

Zitat von Laborratte

Bin mal auf das Ergebnis der Problemanalyse gespannt. Spiele momentan auch auf einem dedicated Server und die Performanceprobleme steigern sich gefühlt jede Woche.

Wir konnten gleiches feststellen.

Habe gestern Abend, Nacht und heute einige Nachrichten mit PP ausgetauscht. Sie haben sich gestern live bis Nachts um 1 auf Fehlersuche begeben und wohl nach eigenen Aussagen "etwas" gefunden. Testen können wir das natürlich erst heute Abend, wenn die Spielerzahl entsprechend ist.

Heute Abend soll der nächste Test, noch einmal mit anderen Startparametern und nach einer "Fehlerbehebung" (keine was Ahnung was das bedeuten soll) laufen.

Ich bin gespannt und halte euch natürlich auf dem Laufenden.

Übrigens, ob nun Single- oder Multi-Core ist noch immer nicht (mehr) klar - da warte ich noch immer auf genauere und verlässliche Informationen. Auf meine Frage hin, warum die Auslastungen so unterschiedliche und irreführende Informationen ausgeben, habe ich leider noch keine Antwort bekommen.

Was ich schon mal sagen kann ist, ihr solltet eure Provider anschreiben und sie bitten, die Crashlogs mal zu löschen - besonders wenn eure Map schon eine ganze Weile läuft und eben viele Crashs erlebt hat. Das beschleunigte Backups und Startvorgang bei uns merkbar. Nach Aussagen meines Supporters wäre die Datenmenge in diesen Ordnern wohl immens gewesen. Genaueres hat er aber nicht gesagt. Danach hatten wir wieder -gefühlt- etwas mehr Leistung. Auch der RAM war dann 2-3% weniger ausgelastet als sonst.

Wir bleiben dran und berichten

Schönen Abend und gut laufende Server allen Mitwirkenden und Mitlesenden
Phil

Kurzes Zwischenergebnis. Zumindest bei uns ist MCS aktiviert. Ich konnte einen Blick auf die echte Auslastung im TM werfen.

Ich muss also meine Vermutung, zumindest bei uns, zurücknehmen. Wie die Hoster allerdings mit shared Hardware umgehen, weiß ich nicht.

Des Weiteren ist wohl die Anzeige der CPU Auslastung im Backend fehlerhaft, welche völlig irreführende Daten anzeigt, die nichts mit der Realität zu tun haben.

Danke für den Tipp und dass ich dadurch den Hoster angeschrieben habe, Baluba. Aktuell ist unser Hoster auf der Suche nach dem Flaschenhals.

Hoffentlich können wir/sie den Fehler finden. Wir halten euch auf jeden Fall auf dem Laufenden.

Auf die Startoptionen haben wir, trotz eigenem Root, keinen Einfluss...

Ich werde sofort meinen Hoster anschreiben und um Aktivierung dieser Option bitten.
Schauen wir mal. Sobald ich ein belastbares Ergebnis habe, geb ich gern bescheid.

Grüße
phil

Es ist auf 1 Core limitiert... Es ist eine Entscheidung der Entiwckler, ob sie den Server auf mehreren Cores rechnen lassen oder nur auf einem.... Die UE4 bietet nach meinem Informationsstand von hausaus beide Möglichkeiten.

Dass es bei den Hostern Unterschiede gibt, liegt an den Massen der Instanzen die auf den Servern laufen. - zb bei G-Portal bis zu 20 Stk auf einer IP. (I/Os an den Datenträgern sind der Flaschenhals)

Die meißten PP Server Owner haben die "High-Power" option gewählt, wo nur 4 Instanzen auf einen Server gehen. (Wahrscheinlich ältere i7 mit 4 Kernen)
Hier haben die Datenträger noch genug I/Os um das zu managen... Aber dann kommt eben die CPU Last sofort als nächster Spielverderber. Bei uns 40 Spieler.... Ende

Wir haben dann von den "High Power" Servern noch einmal ein Upgrade auf komplett eigene Hardware gewagt und sind nun auf einem eigenen Hetzner Server - das hat sich auch (ein Stück weit) ausgezahlt, da wir mehr I/Os an der nvme haben, welche wir explizit dazu gebucht haben. Aber sofort danach kommt eben wieder die CPU.... 1 Core, 100%, TPS down.... Ende Gelände...

Von den High Power Servern zur eigenen Hardware konnten wir bei unserer verschwenderischen Spielweise noch einmal 50% mehr Spieler hosten. Bis zum letzten Update konnten wir ca 60 Spieler handlen - aber mit jeder Stunde wurde es schlimmer - Die Regale immer mehr - die Last immer höher... Jetzt gehen nicht mehr als 40 Spieler und selbst das ist schon grenzwertig

Grüß
phil

Zitat von Baluba

Nur mit Ressourcen lässt sich das nicht sinnvoll erschlagen. Es ist ein strukturelles Problem, was meines Erachtens primär daran hakt, dass es nur eine interne DB gibt, die alles abwickelt. Ich weiß nicht, wie es bei Online-Spielen üblich ist, in der Anwendungsentwicklung würde man bei so komplexen Sachen die DB auslagern und relativ weit auffächern. Das muss aber von Anwendung und Infrastruktur auch unterstützt werden.

Hallo Baluba. Die interne DB ist kein Problem mehr, wenn man sie auf einer NVMe hat und nicht eine von 20 Instanzen auf einem Server gemietet hat.
Das konnten wir mit 4 verschiedenen Servern (Verträgen) und Konfigurationen nachvollziehen.

Das eigentliche Problem ist, dass die Server auf einem CPU-Kern laufen (eben DAMIT 20 Instanzen auf einer Maschine "rennen" können).
Der eine Kern ist bei wenigen Leuten schon ausgelastet und eine Warteschlange an der CPU beginnt.
Die TPS gehen runter, rubberbanding startet. Kommen nun mehr Spieler, gehen die TPS immer weiter runter und die timeouts der Aktionen beginnen... (noch keine lags)

Später hat man bei einem 30er Magazin auf einmal noch 6 Kugeln über, weil von den 90 kleinen Aktionen, die man irrsinnigerweise da rein programmiert hat, nur 84 beim client ankommen... der rest wird gedroppt oder kommt schlicht zu spät oder in der falschen reihenfolge...

Das geht so weit, dass Clienten irgendwann keine aktuellen Daten mehr erhalten und durch einen Timeout disconnecten - denn so ist es im Cient programmiert.

Das jetzige Update hat, wie bereits erwähnt, das Fass zum Überlaufen gebracht.
Jeder der weiß, wie eine CPU funktioniert, weiß was ich meine. 100% sind 100% und keine freien Ressourcen zu besitzen bedeutet SOFORT einen immensen Leistungsverlust durch die entstehenden Warteschlange...

Geht es jetzt noch weiter (denn die clienten fordern und senden gnadenlos weiter Aufgaben) und der Server ist nur noch am stolpern, schmiert er weg -> Fehlberechnung -> server_irgendwas.exe has crashed, dann können selbst simple Threads zur Aufrechterhaltung des Serverbetriebs nicht mehr durch die CPU geschafft werden.

Wir können dieses Verhalten aufgrund des dedi servers und der durchaus vielen spieler bei uns super nachvollziehen... Und weil wir viele Entitys durch reines PvE auf der Map haben, merken wir das schon früher und steuern entsprechend gegen.

Meiner Meinung nach gibt es 2 sinnvolle Problem-Lösungen.
Möglichkeit 1 und auch meine 1. Wahl: Multicore-Support für die Serversoftware... Bereits 2 Kerne können das X-fache an Threads handlen

Möglichkeit 2: Sämtliche Aufgaben für den Server überprüfen und ggf reduzieren. Die neue Nachladefunktion, diese neuen Regale, usw... Der Server braucht wieder weniger zu tun.

(Möglichkeit 3): Man sucht irgendwo Schlupflöcher mit Priorisierungen, usw... Ergebnis werden mehr Bugs und Crashs sein - aber man hat den Patch dann trotzdem irgendwie auf den Server gehieft...

Was es am Ende wird, werden wir sehen.

grüße
phil

EDIT: Natürlich hast du recht und als nächstes würden I/Os der DB den Flaschenhals darstellen. Das sieht man, wenn man einen shared Server hat. Da sind es durchaus die I/Os an den Datenträgern, welche jetzt schon massive Probleme verursachen obwohl die CPU noch Luft hat.

Mittlerweile gibt es Aussagen, dass wirklich offizielle Server einfach abgeschaltet wurden - die die nicht so gut besucht waren.

Es scheint wohl auch bei größeren Streamern nach dem patch schlimm gewesen zu sein, sowie bei den DEVs selbst - ebenfalls live...
Wir können also auf einen patch hoffen.

Geliefert wie bestellt....