Beiträge von DePlex

Richtig, back to topic. Schaut euch doch selbst die Log von ArmA an, wenn ihr gerade auf dem Server spielt (zu finden unter - C:\Users\USERNAME\AppData\Local\ArmA 2 OA\arma2oa.RPT). Serverseitig sollte man dies auch mal prüfen.

Niemand geht grundlos aber nun gut, ich hab mal nachgebohrt. Er wollte mir dazu nicht viel sagen, er hatte mir jedoch dazu drei Screenshots von einem Textverlauf senden können:
[..muss im Prinzip nicht jeder sehen..]

Da hätte mich auch nicht mehr viel gehalten aber das ist wieder ein anderes Thema und ich bin natürlich nicht ganz der Sachelage klar, was da direkt noch alles vorgefallen ist.
Es ist mir jedoch eines aufgefallen, wieso hat er es geschafft wohl auf ähnlicher oder gleicher Grundlage den Server stabil zu bekommen?
..und ganz nebenbei hat er aktuell wieder einen Server, der keine Probleme macht und dieser kommt anscheinend vom gleichen Anbieter.

Eine fehlende Bandbreite lässt den Server trotzdem noch richtig arbeiten. Einmal nimmt man mich wörtlich und im nächsten Satz wird wieder etwas überlesen. Ich sagte, "ArmA 2 aktuallisiert alle Spieler auf der Map gleich, es gibt grundlegend keine großen Unterschiede zwischen zwei Spielern [...]", aber nun gut, "Beleidigungen" werden immer wörtlich und direkt persönlich aufgenommen.
Achja, wie soll dir eine Shell/Batch bei ArmA helfen, vorallem bei Performance-Problemen?

http://s14.directupload.net/file/d/3469/hlm5lzl8_png.htm
Dieser Server ist überfordert mit der Mod und nicht mit der Leitung, zu viele Scripte, fehlerhafte Scripte, AI oder Sonstiges. So sieht euer Server im Normalfall aus.
http://s7.directupload.net/file/d/3469/ig4i3f3j_png.htm
Dieser Server hat eine zu unterdimensinierte Leitung.

Eure Missionfile hat sich nunmal wieder geändert aber der grundlegende Fehler, den man sofort in der RPT sieht, ist immer noch nicht behoben (dafür muss man sich nicht mal die Missionfile genauer ansehen):

Error in expression <;_l47=_l11 displayctrl 102;};waitUntil{!dayz_DisplayGenderSelect};while{_l45<120>
Error position: <dayz_DisplayGenderSelect};while{_l45<120>
Error Undefined variable in expression: dayz_displaygenderselect
File mpmissions\__CUR_MP.Chernarus\germandayz\client\compiles.sqf, line 1

Eine RPT die so stetig wächst war noch nie Gesund für einen Server, bei bestimmten ArmA-Betas führt das sogar zu einem generellen Absturz des Servers.

Meine Standard-Netsettings, mit denen ich noch nie Probleme hatte, egal ob ich die KVM ab und an stark limitieren musste, manchmal auch weit unter 20 Mbit um die Leitung kurzzeitig für andere Dinge nutzen zu können (auch wenn das immer noch nicht euer Problem ist):

Zitat von Starfish

[...]jetzt fick dich ins knie.

Vielen Dank. Werde ich demnächst probieren. Guter Konter zu, "erstunken und erlogen". Wenn sich ein Admin für ein "fick dich" beim Verfasser bedankt, dann war wohl die Einladung zur Hilfe auch nur ein Bluff.

Ihr könnt euch ja an Krazey oder Skaronator wenden, wenn ihr mir nicht glaubt. Das sind zwei deutsche DayZ-Scripter, die ich kenne (sind sogar beide bei Epoch am machen) ..und die würden euch wohl nichts anderes raten. Ich habe beide durch die Modifikation "KrayZ" kennengelernt, hier ging es anfangs um Rigging, später um GUI/UI und Scripten. Die Jungs haben trotz des schlechten Rufs von DayZ-Moddern mehr als genug Ahnung in ArmA.

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..".

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.

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.

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.

Hey,

ich bin schon seit längerem auf der Suche auf einen neuen Epoch Stammserver bin hab ich mal euren Probiert.
Da ich früher mal ein eigenen Server hatte hab ich gleich mal über eure Mission geschaut und hab dort ein Paar mal den Namen Skaronator gesehn.
Soweit ich weiß Programmiert er an DayZ Mod und an DayZ Epoch rum und hat auch ein eigenen Server wo ich mir auch mal die Mission angeschaut hatte.
Mir viel auf das ihr manche sachen 1 zu 1 wie auf seinen Server habt. Habt ihr da zufällig etwas geklaut?