Beiträge von scumsaecke.de

    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

    Time Between Events Min: Diese Zeit muss mindestens zwischen 2 Drops vergehen. Es zählt der letzte Spawn, nicht die Explosion des AD.
    Time Between Events Max: Diese Zeit darf maximal zwischen 2 Drops vergehen. Es zählt der letzte Spawn, nicht die Explosion des AD.
    Cargo Drop Fall Delay: Das ist die Zeit zwischen der Anzeige (rechts oben) des Drops und dem Start des Fallens.
    Cargo Drop Fall Duration: Die Dauer des Fallens
    Cargo Drop Self Destruct Time: Die Zeit am Boden bis er platz

    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

    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

    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.

    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

    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.

    Ich meine bei 15-20 weniger. Sonst waren 60 machbar. Zwar auch mal laggy, aber machbar bei unserer spielweise... jetzt ist es bei 40-45 schon nicht mehr drin, ne türe zu öffnen oder einfach nur zu fahren -> disconnect aller 30 sek, seit dem patch...

    Vorhin haben wir unseren root neu starten lassen. danach war es kurzzeitig besser - allerdings nach 2h laufzeit gehen bei 35 spielern schon wieder die lags los...

    Mit dem heutigen Update wurde der Befehl in den GPortal Settings für die Mechs geändert. Die sind standartmäßig aktiv !!! In den Settings befindet sich nun ein Ein- Aus- Schalter anstatt einen Wert anzugeben.

    Und dass man die maximale Anzahl eingeben kann, geht nicht mehr? .... Das war so perfekt
    Leider hat der Wert bei PP nun keine Wirkung mehr und einen 1/0 Schalter gibt es nicht.

    EDIT knapp vor 20:00 Uhr. Nun ist der Schalter bei PP auch da.
    Schade, dass man die Sentrie-Anzahl nicht mehr einstellen kann. Wir haben die Funktion regelmäßig genutzt.