Feedback/Fehler/Anregungen

Ah alles klar.
Super, danke!

Ja Diiedeli, wenn man nicht gerade in-fight ist, dann sind die Desync Probleme auch nur marginär, aber leider ist es nunmal so das man desöfteren PVP hat und da kommts halt nunmal darauf an, das die Verzögerungen nicht allzu groß sind.

Das du überlebt hast wundert mich selbst auch sehr, denn i.d.R. hättet ihr allesamt nach dem ersten Anflug tod sein müssen

Aber danke für das schnelle Feedback, eine langfristige Lösung wäre echt super da der Server ansonsten mitsamt dem Support von euch wirklich gut ist!

Cheers!

Thema "Desyncs auf dem RD 3"
Ist momentan unser Sorgenkind. Mehr als "wir sind dran" kann ich euch leider dazu nicht mitteilen. Unbefriedigend, und dennoch nicht zu ändern. :-\

Es hat auch absolut nix mit irgendwelchen Listen oder Rankings zu tun, auf dem der Server eingetragen ist. Perfomance muss stimmen, dann kommen die Spieler von alleine. Wenns es sein muss, werden wir die Slotanzahl auch reduzieren.

Zitat von Adebar

Bitte die maximale anzahl an platzierbaren Objekten auf RD 3 erhöhen, sagt mir nun too many objects within 30 meter.

Wieviele Objekete hat dein Plotpole denn? Einfach hingehen und über Maintain die Preview anzeigen lassen. Wir haben es derzeit bei 300 Objekten pro Plotpole eingestellt.

Das Desync Problem ist ein sehr vielschichtiges und prinzipiell bin ich seit 4 Tagen und teilweise auch davor schon, nur damit beschäftigt, das in Angriff zu nehmen.

Leider kommen bei der ganzen Sache mehrere Dinge zusammen, zum einen kämpfen wir seit Freitag mit leichten Netzwerkproblemen im Rechenzentrum und wohl auch die Techniker dort sind am tunen und optimieren.
Während die Jungs allerdings dort schrauben, sind wir dabei die Settings unsererseits anzupassen.
Leider arbeiten da teilweise 2 Fraktionen gegeneinander und am Ende des Tages stimmen unsere Settings teilweise nicht mehr damit überein, was für Connection aus dem Datacenter raus geht.

Leider kann man diese Einstellungen auch nur zu jedem Server Restart angehen, diese werden dann geladen und bleiben in Nutzung bis zum nächsten Restart. Die richtige Performance mit den direkten Einstellungen lässt sich auch dann nur bei fast vollem Server gut überprüfen, nur dann ist die Bandbreitennutzung eben auf maximum und man kann beurteilen wie die Einstellungen auf die Desyncs wirken.

Jetzt gibts das generelle ArmA Problem. Zum einen will die minimale und maximale Bandbreite in Angriff genommen werden, wo wir teilweise eben gegen die Techniker arbeiten, zum anderen gibts bestimmte Werte wie oft Clients aktualisiert werden, sowohl wenn sie in der Nähe sind (<1km ingame) und darüber hinaus.
Das ergibt dann teilweise auch unterschiede ob man jemanden durchs Fernglas oder Scope beobachtet oder nicht.
ArmA setzt da verschiedene Werte zur Grundlage und diese sind natürlich wiederrum auf die Bandbreite beschränkt, die entsprechend angepasst werden muss.
Jetzt bleibt nicht viel über als jeden Tag, vor allem zu den Hauptrestartzeiten (18,21,0 Uhr) diese anzupassen, den Effekt zu beobachten und ggf. nachzubessern. Unterschiede sind da teilweise eben nur sehr spärlich möglich und man tastet sich langsam vorran.
Nachteil: es dauert gefühlte Ewigkeiten und ergibt mal mehr, mal weniger Desync.

Ich denke auch ganz realistisch und ehrlich, es wird sich noch locker die Woche hinziehen bis wir uns auf Werte festsetzen können, bei denen man sagen kann: es geht nicht besser. Dann wird sicher weitergedacht und geschaut, woran es noch liegen könnte und ob eine Reduzierung der Slots märklich was ausmachen würde.

Was ich aber definitiv sagen kann: Sämtliche stats-tracking Pages, Toplisten oder sonstwas schaue ich mir weder an, noch interessieren sie mich aufs geringste. Was zählt ist das Spielerlebnis vor Ort, ob nun mit 30 oder 80 Spielern, ob Randvoll oder mit 10-15 Slots Luft nach oben, solang genug Action ist und das spielen Spaß macht, solls mir egal sein. Also bitte keine Behauptungen da achtet jemand drauf, ich denk wir sind uns einig das andere Seiten gern tracken können was sie wollen und wer danach geht, der kann gern auf den Top #1 Server mit seinen 120 Slots und durschn. Ping von 380 gehen und da glücklich werden.

Was mir persönlich helfen könnte: - mehr oder weniger genaue Reports am Abend nach dem Zocken. Wie war der Desync/Lag etc. bei:
[list type=decimal]
[li]Autofahren für den Fahrer selbst und für Mitinsassen[/li]
[li]Laufbewegungen von Spielern im nahen Umkreis und auf Entfernung[/li]
[li]flüssiges Snipen möglich, ja, nein, vielleicht - wie bewegen sich entfernte und nahe Einheiten, ruckelts, flüssig etc.[/li]
[li]generelle Lag Probleme: kommen mehrere Kugeln gleichzeitig an, Dauert das Aufnehmen von Loot länger als normal?[/li]
[li]wie bewegen sich vor allem andere Fahrzeuge bei hohen Geschwindigkeiten, Helis, Autos etc.[/li]
[/list]

Ich denk aber das wir uns diese Woche noch auf Settings einigen können, die zumindest grundlegend Performance sichern und Kämpfe auch möglich machen.

danke erstmal an die Admins für das Feedback. (y)

Ich glaube es liegt auch größtenteils daran, das die Server 1 und 2 nicht so gute Performance haben und viele von diesen jetzt auf den 3er gewechselt haben. Habe das zumindest von einigen Gruppen so gehört. Daher ist der 3er jetzt auch 24h zum bersten voll.

Maintain funktioniert nicht ist auch noch nicht aktiviert.

Habe es versucht bei einem Plotpole. Briefcase im Inventar gehabt und maintain ausgeführt. Wurde direkt vom Server gekickt wieder eingeloggt und auf einmal verschwinden Türen, Woodfloors Metal floors... Diiedeli kümmert sich darum gerade drum die Sachen zu ersetzten. Wissen aber noch nicht ob alles verschwindet.

Zitat von Bigbass

Maintain funktioniert nicht ist auch noch nicht aktiviert.

Habe es versucht bei einem Plotpole. Briefcase im Inventar gehabt und maintain ausgeführt. Wurde direkt vom Server gekickt wieder eingeloggt und auf einmal verschwinden Türen, Woodfloors Metal floors... Diiedeli kümmert sich darum gerade drum die Sachen zu ersetzten. Wissen aber noch nicht ob alles verschwindet.

Ist seit soeben gefixt und live auf dem RD3.

Richtig "verschwinden" würde da nichts, ist nur teilweise nicht sichtbar auf Grund der Script Restriction.
Da die aber behoben wurde und wir das soeben getestet haben, sollte alles einwandfrei laufen.

Zum Zeitpunkt wann das Maintain dann nun endgültig benötigt wird, gibts heute im Laufe des Tages noch eine Ankündigung. Also nicht unbedingt sofort ausführen, ich denke die erste "Lebensverlängerung" wird es kostenlos geben und dann zum ersten mal richtig fällig in den kommenden Tagen/Wochen.

(y)

Zitat

Was mir persönlich helfen könnte: - mehr oder weniger genaue Reports am Abend nach dem Zocken. Wie war der Desync/Lag etc. bei:

nur schnell kurzes feedback:

gestern 10.12.2013
Server RD3
Zeit 18:00-00:00

- Heftige Desyncs
- in Heli und Fahrzeugen Diashow
- Spieler ruckeln sich durch die Gegend
- während PVP hing der Server so 2-4 Sekunden hinter her(wenn man jemanden getötet oder man selbst getötet wurde )
- Gear/ Lootaufnahme mit leichten Verzögerungen
- Türen und Schlösser gingen meißt erst nach 2 Sekunden auf
- FPS waren gut bis sehr gut

Gruß Buck

Zitat von Starfish

Jetzt gibts das generelle ArmA Problem. Zum einen will die minimale und maximale Bandbreite in Angriff genommen werden, wo wir teilweise eben gegen die Techniker arbeiten, zum anderen gibts bestimmte Werte wie oft Clients aktualisiert werden, sowohl wenn sie in der Nähe sind (<1km ingame) und darüber hinaus.
Das ergibt dann teilweise auch unterschiede ob man jemanden durchs Fernglas oder Scope beobachtet oder nicht.
ArmA setzt da verschiedene Werte zur Grundlage und diese sind natürlich wiederrum auf die Bandbreite beschränkt, die entsprechend angepasst werden muss.
Jetzt bleibt nicht viel über als jeden Tag, vor allem zu den Hauptrestartzeiten (18,21,0 Uhr) diese anzupassen, den Effekt zu beobachten und ggf. nachzubessern. Unterschiede sind da teilweise eben nur sehr spärlich möglich und man tastet sich langsam vorran.
Nachteil: es dauert gefühlte Ewigkeiten und ergibt mal mehr, mal weniger Desync.

Ich denke auch ganz realistisch und ehrlich, es wird sich noch locker die Woche hinziehen bis wir uns auf Werte festsetzen können, bei denen man sagen kann: es geht nicht besser. Dann wird sicher weitergedacht und geschaut, woran es noch liegen könnte und ob eine Reduzierung der Slots märklich was ausmachen würde.

Server RD3..

Nun fangen wir an. Die minimale und maximale Einstellung der Bandbreite ist wohl die einfachste Konfiguration in der ganzen ArmA-Serverarchitektur. Euer hier aufgetischtes Problem ist schlicht und ergreifend nur erstunken und erlogen. Man stellt bei einem 0815 Server mit einer 100 Mbit-Anbindung minimal auf 10 Mbit und der maximale Wert eben bei 100 Mbit. Zu niedrige Werte führen dauerhaft zu erhöhten stabilen Pings.

Nächste Lüge: ArmA 2 aktuallisiert alle Spieler auf der Map gleich, es gibt grundlegend keine großen Unterschiede zwischen zwei Spielern, die nebeneinander stehen oder Zweien, die 10km trennen. Jeder Admin mit gekauften, gecopypasteten Anti-Scripts oder anderen Admin-Scripten sollte das eigentlich ziemlich schnell merken, sofern sein Script die Spectator-Funktion besitzt.
Der Client eines Spielers in Kamenka kennt alle Positionen der Spieler und z.B. auch den kompletten Loot, der momentan auf dem NW Airfield liegt.
Ein Unterschied im Sync zwischen Fernglas, Scope oder der normalen Ansicht gibt es nicht.
Erst die DayZ Standalone limitiert die Übergabe an Werten des Servers an den Client..

Ein Nitrado-Server hat mehr als ausreichend Leistung um mindestens mit 50 Spieler zurecht zu kommen. Euer Problem ist, dass DayZMod (vorallem Epoch) sowieso keine gute Performance hat und ihr noch dazu die Missionfile mit Müll zugeballert habt. Man gehe auf euren Server und schaue sich nur die Client.RPT an und man staunt wie schnell diese an Größe gewinnt ..diese wird nonstop mit Fehlern zugemüllt. Serverseitig dürfte das nicht anders aussehen.

Nächster Punkt ist, dass ihr die Custom-Gebäude in der Missionfile stehen habt, ..wieso eigentlich? Zum einen sind die Elemente momentan eh ausgeklammert und zum anderen komplett deplaziert. Wenn man sich nun diese Scripte genauer anschaut merkt man auch sofort, dass dort bestimmte Variablen überdefiniert sind, z.B. "_vehicle_38" in "bash_trader.sqf" und "lumberjack.sqf". Dies führt zu derben Clientlags und je nach Ausmaß zu herben Desyncs.

Eine veränderte Map startet man stets mit dem Server und der Client braucht davon nichts zu wissen, da der Server diese Daten eh an den Client streamt.
In DayZMod und co. kann man dafür ganz einfach die "dayz_server.pbo" missbrauchen, hier einfach jegliche Mapveränderung in Form eines Scriptes bei "server_monitor.sqf" for "sm_done" hinzufügen. Wenn ihr es unbedingt in der Missionfile stehen haben wollt, dann macht es wie Epoch und packt es in den "isServer"-Bereich rein, wobei sich das auch nur für kleiner Änderungen eignet und man sollte immer im Hinterkopf behalten, dass keine Variablen doppelt definiert sein dürfen.
Einfache Trennung der Variablen mit der Funktion "Suchen und Ersetzen" in eurem Editor eurer Wahl:
Suchet nach "_vehicle_" und ersetzt es mit z.B. "_vehicle_123" oder was euch gerade einfällt.

Zu guter letzt ist eure Missionfile im Allgemeinen ziemlich kurios aufgebaut. Es sieht manchmal so aus, als hättet ihr wahllos Funktionen hinzugefügt und diese nicht genauer für den eigentlich Nutzen geprüft. Es gibt einige Überschneidungen und grundlegende Fehler im ArmA-Scripting.

Alle hier aufgezählten Dinge reduzieren die Server-Performance und je nach Ausmaß die Client-Performance. Ein normaler DayZ-Server sollte mit 50/50 Spielern ca. 2-5 Server-FPS haben, keine bis wenige Desyncs (jeder Servercleanup kann zu einem kleinen Desync führen) und der Ping sollte stabil sein. Mit HLSW kann man schön durchgehend den Server anpingen und bei eurem Server sieht der Verlauf ab und an ziemlich hübsch aus. Der Ping schwankt und die Timeouts nehmen ihren Lauf...

PS: Eine schlechte Server-Performance führt zu niedrigen Client-FPS + Desyncs, da der Client nicht mehr genügend Daten an den Server senden und empfangen kann.

Bin ich froh, dass dich niemand zwingt auf unsere Server zu spielen.

gestern 11.12.2013
Server RD3
Zeit 16:00-18:00

- starke Desync's in Fahrzeugen,
- starker Player Desync,
- Zombies töten dauert ewig und drei Tage (mehrere Kopfschüsse, dann erst tot),
- Gear/ Lootaufnahme mit leichten Verzögerungen,
- Türen und Schlösser gingen meißt erst nach 2 Sekunden auf,
- Gegenstände (Wooden Shack's) sind während dessen der Server läuft verschwunden (Plot Pole Probleme eigentlich auszuschließen da andere Items die neben/hinter den Shack's stehen nicht verschwunden sind),
- o.g. Problem nach Serverrestart nicht behoben oO,
- FPS waren gut (durchschn. 25 FPS),
- Tradermenüs laden extrem lange,

Cheers!

Zitat von Urs

Bin ich froh, dass dich niemand zwingt auf unsere Server zu spielen.

Seit wann ging es darum? Ich erkläre euch ArmA, wie es ist und funktioniert.
Es ist eine Kritik an euch und noch dazu hab ich durch kurzes drüber schauen schnell einige Fehler entdeckt und zum Teil Lösungsvorschlage gegeben.

Feedback/Fehler/Anregungen, bin ich hier doch falsch?

PS: Ich spiele kaum bis garnicht DayZ. Ich wurde von einer gewissen Person gebeten über euren RD3 Server drüberzuschauen und nebenbei ist mir der Beitrag eures Server-Technikers hier aufgefallen.

Du hast ohne Frage in weiten Teilen deiner Ausführung Recht, allerdings verstehe bzw. missverstehe ich einige Dinge in foldendem Abschnitt nicht : _"Nächster Punkt ist, dass ihr die Custom-Gebäude in der Missionfile stehen habt, ..wieso eigentlich? Zum einen sind die Elemente momentan eh ausgeklammert und zum anderen komplett deplaziert. Wenn man sich nun diese Scripte genauer anschaut merkt man auch sofort, dass dort bestimmte Variablen überdefiniert sind, z.B. "_vehicle_38" in "bash_trader.sqf" und "lumberjack.sqf". Dies führt zu derben Clientlags und je nach Ausmaß zu herben Desyncs.".

Sofern du mit "Missionfile" die tatsächliche Missionfile, also die sqm, meinst, muss ich dir wiedersprechen. Grade das definieren neuer Vehicle in der Missionfile statt in Scripten entlastet den Server beim initialisieren. So werden die in der Missionfile eingetragenen Objecte vom Client über das Engine generiert, womit der Server diese nicht, sofern sie nicht verändert werden, boardcasten muss. Für JIP's gilt dies offensichtlicherweise nur eingeschränkt, da der Server die neuen Positionen usw. sowieso synchen muss. Da dies bei Gebäuden allerdings durch die Natur ihrer Stetigkeit nicht zwangsweise der Fall sein muss, ist das definieren dieser in Scripten zu vermeiden.

Zusätzlich kann man Variabeln nicht überdefinieren, zumindest nicht auf die Art und Weise wie du sie anscheinend zu kritisieren denkst. Ich muss zugeben die GD und Epoch Files nicht zu kennen, da ich selber kein DayZ spiele und keinerlei Änderungen an diesen Files gemacht habe, allerdings ist heap-spraying nicht besser als das ständige redefinieren einer Variable. Inwiefern dies Desynchs verursachen soll, ist mir auch nicht bewusst, da solche Variablen grundsätzlich local in ihrem scope sind.

Mit der Missionfile meine ich nicht nur die SQM, sondern auch dessen restlicher Müll, wie "init.sqf" und co., eben die komplette momentane Missionfile von ca. 600 KB auf Server RD3.

Bis zu einem gewissen grade kann man natürlich die "mission.sqm" für Custom-Gebäude nutzen, jedoch bei größer Häufung der Gebäude empfehlen sich seperate Scripte. Der Mission-Editor schmeißt immer neben der SQM noch eine SQF raus, letzteres kann man auch noch etwas "optimieren" ist aber in den meisten Fällen nicht nötig.

Jetzt zu den Lags, die dadurch nicht vorkommen können? Ich spreche hier aus Erfahrungen und ziehe mir hier nichts grundlos aus der Nase nur um es als Mittel zum Zweck zu haben.

Mein Beispiel: Beliebige Map, diese wurde mit ca. 5000 Objekten erweitert, diese wurden in fünf Bereiche der Map eingeteilt. Es waren nun schlussendlich 5 SQM und SQF's erstellt durch den Editor.
Wir hatten anfangs die "mission.sqm"-Dateien zu einer zusammengefasst und haben festgestellt, dass das nicht so schön lief wie wir es uns wünschten. Allein schon deswegen, weil wir die Missionfile klein halten wollten ohne die zu verwendeten Mods zu editieren oder gar zusätzlich dafür eine PBO als Lager zu definieren.
Danach hatten wir dem Server seperat die 5 SQF's vorgeworfen, mit den überdefinierten Variablen. Dies führt dazu, dass man in der Nähe dieser Objekte extreme Frame-Einbrüche hatte. Schlussendlich haben wir die Variablen neudefiniert und die Sache hatte sich erledigt.

DePlex, wir bedanken uns für die Zeit und Mühe, die Du Dir machst, unserer Community zu helfen.
Wir wissen das zu schätzen. Im Sinne unseres gemeinsamen Hobbys, bitte ich Dich fair und friedfertig zu bleiben. Überdenke Deine Wortwahl.

Zitat von DePlex

Euer hier aufgetischtes Problem ist schlicht und ergreifend nur erstunken und erlogen.

Ich weiß nicht welche Laus Dir über die Leber gelaufen ist, oder ob es Dir nicht bewusst war, aber diese Aussagen greifen uns und vor allem Starfish extrem an, was er absolut nicht verdient hat. Ich würde dafür gerne eine Etschuldigung sehen!

Ich weiß mit absoluter Sicherheit, dass kein Teammitglied irgendeinen Spieler unter Vorsatz täuschen oder gar belügen wollte. Wenn technische Details nicht zu 100% richtig dargestellt wurden, bitten wir um Entschuldigung, falls dadurch Irritationen entstanden sind.

Ich gebe zu, dass diese Aussage leicht grotesk und sehr übertrieben wirkt. Das war nur als "extreme" Einleitung gedacht, jedoch war dies keineswegs als Beleidigung gedacht. Das "erstunken und erlogen", sollte nicht wörtlich sondern eher ironisch aufgefasst werden, vorallem weil ich euch im restlichen Text versuche zu helfen. Dies entschuldigt natürlich meine Wortwahl nicht aber damit wollte ich keinen persönlich angreifen.

Als ich das erste mal den Beitrag von "Starfish" gelesen hatte, dachte ich eigentlich eher an: "Die Jungs verzweifeln wohl langsam an belanglosen Kleinigkeiten..".

wir sind über jede helfende hand dankbar und deine vorschläge werden mit sicherheit auch diskutiert werden... wenn du weiterhin interesse hast uns zu helfen dann skype mich mal an (smurfi_3am)... werde aber erst nach o1oo @home sein ...