Soundmod - Einfluss auf Serverstabilität?

Zitat von Clock

...Zuletzt wurde zB als Verdächtiger JSRS ausfindig gemacht...

*facepalm* Das mag ich immer. Da könnt ihr auch gleich nen Würfel werfen um die Usache zu erraten. Wenn ich das schon lese - "als Verdächtiger ausfindig gemacht". Damit wird ja sogar noch bestätigt das ihr keine Ahnung habt woran es liegt, wolltet aber ein Bauernopfer darbringen. Obligatorisch wird also erstmal irgendein Mod auf dem Scheiterhaufen verbrannt, ähh, verbannt. (ja der muss es sein, der is mehrere GB gross!^^)

Erstmal ist JSRS ein Client Side Mod. Jeder der den auf sinem Server laufen lässt hat da etwas nicht verstanden. Wie soll also ein Client Side Mod den Server zum Absturz bringen? Dazu arbeitet der Mod fast ausschließlich lokal. Das bedeutet er verursacht kaum Traffic. Nur ein Feature in diesem Mod läuft übers Netzwerk. Zugegeben, der Mod ist bei sehr großen Schlachten rechenintensiv. Aber das läuft alles auf der persönlichen CPU ab und hat auch nichts mit Coop für 6 oder 60 Spielern zu tun sondern eher etwas mit der Anzahl der gleichzeitig feuernden KI's.

Mods bei denen zuerst gesucht werden muss sind immer solche welche Einfluss auf die KI nehmen. Die sind meistens schlecht geschrieben und schicken alles übers Netzwerk. Ein tolles Negativ-Beispiel ist da die komplette TPW-Mod Serie. Wenn dem Typen nicht die Community permanent seine Mods neu schreiben würde ginge da nichts.

Sorry für OT aber das musste raus!
Grüße

EDIT:
How to find a bad mod or script - Ausschlußverfahren, Serverbefehl: #monitor, Logfiles lesen

Der OT ist hart, aber so kenne ich es von Dir und... aber Psycho meint es im Grunde seines Herzens immer gut!

Und das wichtige im Thread ist:
How to find a bad mod or script - Ausschlußverfahren, Serverbefehl: #monitor, Logfiles lesen

Ohne das Logfile und eine wirkliche Fehleranalyse ist es immer schwer...

OK... man muss wirklich anerkennen, Clock schrieb ja...

Zitat

Das aber nur aus Sicht eines Mitspielers und nicht eines Missionsbauers.

@ Psycho:
BTW: Hast das Smily gesucht!?

Zitat von Grey Wolf

@ Psycho:
BTW: Hast das Smily gesucht!?

Ja, so einen hatte ich gesucht!

Clock, danke für den Link. Lese ich mir nachher mal durch...

Aus Sicht eines Missionsbauers/Scripters muss ich Psycho absolut Recht geben (es sei denn ihr spielt nicht auf einem dedicated Server). Hier den Soundmod als Ursache für schlechte Serverperformance verantwortlich zu machen ist in 99% aller Fälle schlichtweg nicht zutreffend.
Wer ohne JSRS oder ähnlichem eine flüssigeres Spielerlebnis hat sollte sich Gedanken über seine eigene Hardware machen.

Die Serverperformance hängt hauptsächlich von folgenden Sachen ab:

• Serverhardware
• Serverbandbreite
• Scripte auf dem Server (Mods)
• Scripte in der Mission
• Anzahl (und Art) der Objekte in der Mission (dazu gehört auch AI)

Da meiner Meinung nach schon mit durchschnittlicher Serverhardware und -bandbreite locker ein Co50+ möglich ist, wird meistens das Problem in den unteren drei Punkten zu finden sein.
Abschließend kann man sagen das es letztendlich die Summe aller Punkte ist, welche ausschlaggebend für die Performance ist.

Ausschnitte aus dem von Clock verlinktem Text:

Zitat

Das Problem: Alle Soundmods sorgen für deutlich mehr Traffic und Serverbelastung, da die Soundereignisse zwischen den Clients synchronisiert werden

Zitat

Jeder Schuss muss synchronisiert werden zwischen den Clients, jeder Schuss löst auch ein Script aus.

Diese Aussagen sind schlicht weg falsch. Kein Soundereigniss wird zwischen den Clients synchronisiert.
In dem verlinkten schreiben geht es zwar um "Dragonfire" mit welchem ich persönlich nichts mehr zu tun habe und auch den Inhalt nicht kenne. Ich kann mir aber nicht vorstellen, dass die Abweichungen zu JSRS 2.1 (da habe ich noch dran geschrieben) so gravierend sein sollen bzw. ein komplett neuer Unterbau dahinter klemmt. Daher beschreibe ich mal kurz für den Laien wie ein Soundeffekt (Distance Sound) technisch mit JSRS2.1 generiert wird.
Eine Unit (egal ob Spieler oder KI) gibt einen Schuss ab. Mit Abgabe des Schusses wird eine vorkompilierte Funktion (kein Script!) ausgelöst welche die Distanz zwischen Source und Empfänger prüft. Ab einer gewissen Distanz und in diversen Abstufungen wird das abspielen des Schussgeräusches nun verzögert (t = Weg / Schallgeschwindigkeit in Luft). Außerdem kann aufgrund der ermittelten Distanz eine andere Soundsource gespielt werden um die Illusion zu verstärken. Da die eigentliche Source den Schuss ja schon längst abgegeben hat wird nach der Verzögerung ein Dummy generiert welcher den Schusssound "sagt". Dieser Dummy wird lokal generiert.

Was bedeutet das alles jetzt auf deutsch:
- ja, jeder Schuss löst eine Berechnung aus (es wird lokal die Distanz zwischen Sender und Empfänger ermittelt, auf eigener CPU)
- nein, kein Schuss wird mit irgendwem oder zwischen allen synchronisiert, jeder errechnet für sich alleine die Distanz zur Source
- nein, die Ausgabe einer Soundsource über einen Mod ist nicht aufwändiger als Vanilla (in beiden Fällen wird ein Sound abgespielt, Fakt)
- nein, nur weil es jetzt wesentlich mehr Soundfiles im Mod sind wird dadurch mehr gerechnet, dass frisst nur die Festplatte auf

Ob der Soundmod Fehler in die .rpt spamt will ich nicht abstreiten. Das wird wohl so sein. Ich tippe mal auf fehlerhafte Configs. Ob diese denn dann auch tatsächlich irgendeinen Einfluss auf die Performance oder den Traffic haben muss man im Einzelfall prüfen. (ich kenne die Meldungen nicht) Hier sollte man lediglich wissen das nicht jeder Eintrag eine Fehlermeldung ist, die meisten Einträge sind Hinweise oder Warungen.

Mal noch so nebenbei zum Thema Positionsberechnung, Client und Server.
Wenn ich das verdammte Video finden würde könnte ich euch sogar beweisen, dass da absolut nichts und überhaupt nichts synchronisiert wird zwischen Server und Client. Das hatte dslxyici (wie schreibt man den???) mal visualisert und man kann hier sogar von einem Bug bzw. schweren Missstand in der Engine sprechen. Wenn 2 Spieler eine Positionsberechnung zu ein und dem selben Objekt in der Server-Environment machen kommen bei deiden komplett unterschiedliche Ergebnisse raus. Die Abweichung beträgt je nach Distanz i.d.r. irgendwas zwischen 5 und 30 Ingame-Metern.

Grüße

Zitat von Psychobastard

*facepalm* Das mag ich immer. Da könnt ihr auch gleich nen Würfel werfen um die Usache zu erraten. Wenn ich das schon lese - "als Verdächtiger ausfindig gemacht". Damit wird ja sogar noch bestätigt das ihr keine Ahnung habt woran es liegt, wolltet aber ein Bauernopfer darbringen. Obligatorisch wird also erstmal irgendein Mod auf dem Scheiterhaufen verbrannt, ähh, verbannt. (ja der muss es sein, der is mehrere GB gross!^^)

Erstmal ist JSRS ein Client Side Mod. Jeder der den auf sinem Server laufen lässt hat da etwas nicht verstanden. Wie soll also ein Client Side Mod den Server zum Absturz bringen? Dazu arbeitet der Mod fast ausschließlich lokal. Das bedeutet er verursacht kaum Traffic. Nur ein Feature in diesem Mod läuft übers Netzwerk. Zugegeben, der Mod ist bei sehr großen Schlachten rechenintensiv. Aber das läuft alles auf der persönlichen CPU ab und hat auch nichts mit Coop für 6 oder 60 Spielern zu tun sondern eher etwas mit der Anzahl der gleichzeitig feuernden KI's.

Der Verdacht fiel nicht auf JSRS, weil der Mod so groß ist oder sonst irgendwas, sondern aufgrund der Aussagen von jaynus von United Operations - Hauptentwickler von ACRE/ACRE2 und Mitentwickler bei CBA und ACE, wenn der solche Aussagen trifft, habe ich guten Grund zu der Annahme, dass er weiß, wovon er redet. Der komplette Thread ist hier zu finden (Klick mich!), wer sich nur das wichtigste durchlesen will: Klick mich!.

Zitat von Psychobastard

Mods bei denen zuerst gesucht werden muss sind immer solche welche Einfluss auf die KI nehmen. Die sind meistens schlecht geschrieben und schicken alles übers Netzwerk. Ein tolles Negativ-Beispiel ist da die komplette TPW-Mod Serie. Wenn dem Typen nicht die Community permanent seine Mods neu schreiben würde ginge da nichts.

Wir benutzen bei uns ASR AI3, habe bis jetzt noch nichts negatives darüber gehört, lasse mich aber gerne aufklären.

Zitat von Psychobastard

hängt lediglich am Missionsbauer und natürlich auch am Serveradmin (server.cfg).

Ich gehe davon aus, dass du die basic.cfg meinst - die server.cfg hat weniger was mit Performance als mehr mit Security zu tun. Die basic.cfg ist ein Mysterium für sich, das scheinbar von niemandem komplett verstanden wird - hab da viel und lange sowohl mit Dwarden als auch mit Admins anderer Communities (EUTW, EPM) drüber diskutiert. Leider scheint in der ArmA-Community, gerade bei den größeren Communties, eine "Nein, meine config, meine config"-Mentalität vorzuherrschen, die einen offenen Austausch über dieses Thema verhindert. Lasse mich jedoch auch in dieser Hinsicht gerne beraten. Unsere aktuelle basic.cfg basiert auf einer für uns modifizierten Version der basic.cfg, die Dwarden für seine Chimera-Server verwendet:

Unser Server ist der hier: Klick mich!

Schöne Grüße
TheConen

Ja, zu klären wäre in wie weit Dragonfire neu geschrieben wurde und was von JSRS übernommen wurde.
Ich habe Dragonfire nicht auf der Platte und kann daher selber nicht nachschauen.

Hallo TheConen,

ja ich meine die basic.cfg. Ich kann gerne die des aktuellen GeCo-Servers teilen auf dem regelmäßig Events mit +50 Spielern abgehalten werden. Die Settings wurden als Basis vom A2 Server genommen an dem ich das damals über Try-and-Error erkundet habe. Die Settings wurden dann leicht an die Bedingungen unter A3 angepasst. das Problem mit dem teilen dieser configs ist ja eigentlich das jeder eine andere Hardware und/oder Serveranbindung zu der entsprechenden Config hat. Daher ist ein Vergleich auch immer so schwer bzw. nur bedingt aussagekräftig.

Problem ist meistens, dass viele Configs grobe Schnitzer enthalten und an einigen Punkten Zahlendreher oder komplett andere wertigkeiten haben. (in der Stelle verzählt z.B.)

Zu ASR AI habe ich auch noch nichts negatives gehört. Ich denke das ist auch eine positive Ausnahme.

Und danke für die Links zu den Meinungen von Jaynus. das interessiert mich und schau ich mir jetzt auch erstmal in Ruhe an.

Grüße

Zitat von Psychobastard

*facepalm* Das mag ich immer. Da könnt ihr auch gleich nen Würfel werfen um die Usache zu erraten. Wenn ich das schon lese - "als Verdächtiger ausfindig gemacht". Damit wird ja sogar noch bestätigt das ihr keine Ahnung habt woran es liegt, wolltet aber ein Bauernopfer darbringen. Obligatorisch wird also erstmal irgendein Mod auf dem Scheiterhaufen verbrannt, ähh, verbannt. (ja der muss es sein, der is mehrere GB gross!^^)

Erstmal ist JSRS ein Client Side Mod. Jeder der den auf sinem Server laufen lässt hat da etwas nicht verstanden. Wie soll also ein Client Side Mod den Server zum Absturz bringen? Dazu arbeitet der Mod fast ausschließlich lokal. Das bedeutet er verursacht kaum Traffic. Nur ein Feature in diesem Mod läuft übers Netzwerk. Zugegeben, der Mod ist bei sehr großen Schlachten rechenintensiv. Aber das läuft alles auf der persönlichen CPU ab und hat auch nichts mit Coop für 6 oder 60 Spielern zu tun sondern eher etwas mit der Anzahl der gleichzeitig feuernden KI's.

Mods bei denen zuerst gesucht werden muss sind immer solche welche Einfluss auf die KI nehmen. Die sind meistens schlecht geschrieben und schicken alles übers Netzwerk. Ein tolles Negativ-Beispiel ist da die komplette TPW-Mod Serie. Wenn dem Typen nicht die Community permanent seine Mods neu schreiben würde ginge da nichts.

Sorry für OT aber das musste raus!
Grüße

EDIT:
How to find a bad mod or script - Ausschlußverfahren, Serverbefehl: #monitor, Logfiles lesen

Alles anzeigen

Ich würde vorsichtig mit solchen aussagen sein wenn ich die Thematik selbst nicht zu verstehen scheine ...

Soundmods generell auszuschließen weil "nur Client" ist Schwachsinn
im folgendem mehr dazu (und generell bzgl. was tut der Stabilität des Servers gut und was nicht)

[HR][/HR]
[HR][/HR]
[HR][/HR]

Serverstabilität
Die Serverstabilität ist seit jeher ein wichtiges Thema in ArmA (und vermutlich hätte sich schon längst irgendwer an einem eigenen CommunityServer gemacht wenn es nicht so wäre das ArmA SQF hat ... (kein Hindernis, jedoch eine Einschränkung)) und diese wird NATÜRLICH beeinflusst bei jeder Mod die man lädt (hierbei gilt: pbo > Mission)
ob dieser Einfluss positiv oder negativ ausfällt liegt an verschiedenen Dingen (ich werde hier also mal schnell alles abhandeln was Performance/Stabilität/Skript Performance Probleme auftreten lassen könnte ...)
Kurz angemerkt:
Der Server selbst ist genauso wie jeder andere Computer ein CLIENT aus Netzwerk Sicht und wird daher hier auch so genannt

Legende (Farben)

• 
  

• # = Hat definitiv Auswirkung
  # = Hat unter bestimmten Umständen Auswirkung
  # = Hat keine/kaum merkliche Auswirkungen oder nur in sehr speziellen Szenarien
  

Legende (Buchstaben)

• 
  

• P = Game Performance (FPS)
  S = Spiel Stabilität (CTDs, Bluescreens)
  E = Script Performance ("Input lag" bei nicht nativen dingen)
  

• Config Dateien P - S - E
  Config Dateien werden in ArmA genutzt um feste werte zu definieren und sind daher ein "schnelles" werte verzeichnis
  Über diese werte kann man z.B. der Engine sagen wie ein Fahrzeug definiert ist
  
  Game Performance
  Performance technisch macht es keinen wirklichen unterschied ob man einen Configeintrag oder 2mio hat (ArmA ist schlau ^^)
  daher gibt es hier auch kaum Auswirkungen
  
  Stabilität
  Sollte einem Client eine Config fehlen (pbo in der die besagte Config liegt ist z.B. nicht vorhanden) oder in einer anderen Ausführung vorliegen (Daten mithilfe einer pbo manipuliert) so kann dies zu ERHEBLICHEN Problemen führen!
  Stabilitäts Probleme lauern daher immer dort wo Client und Server nicht das gleiche Config Verzeichnis haben
  daher immer darauf achten das Modifikationen sowohl auf Server als auch auf dem Client gleich sind!
  Die üblichen "Syntax Error" abstürze lass ich hier mal aus da diese nicht während der Laufzeit geschehen
  
  Script Performance
  Die Skript Performance ist ein Spezial Fall...
  Config Dateien direkt haben KEINE Auswirkung auf die Skript Performance jedoch ist es möglich das bestimmte Einträge in einer Config SQF/SQS Code enthalten die dann wiederum an anderer Stelle ausgeführt werden
  daher haben Config Dateien ab dem Moment wo ihre werte automatisch ausgeführt werden immer einen gewissen Skript lag (das ist z.B. der fall wenn man CBAs Extended Config Event Handlers pbo nutzt oder in einer UI die init Felder ausfüllt)
• Scripting (SQF/SQS/FQM) P - S - E
  ArmA ist modbar und daher ist Scripting im Grunde ALLES was irgendwelche Features hinzufügt (native Features ausgeschlossen)
  
  Game Performance
  Scripting KANN die Game Performance runter ziehen mit bestimmten befehlen und/oder vielen Extension calls
  Das ganze geschieht jedoch eher selten und ist nicht wirklich relevant für die Missionsmacher/Admins (Modder sollten im Regelfall Bescheid wissen)
  
  Stabilität
  Stabilität ist ebenso wie die Game Performance eine relative Sache...
  die Stabilität kann durch fehlerhafte Präprozessor befehle (#include "blafoobar!.txtbla") oder auch durch extensions ausgelöst werden
  beides sollte den Otto normal Armin/User jedoch kaum begegnen und wenn doch ist es schnell durch ein gucken in die Logs gefunden
  
  Script Performance
  JEDER Befehl in ArmA hat eine unterschiedliche Laufzeit
  so ist ein "{false} count [1,2,3]" z.B. schneller als ein "{true} count [1,2,3]" (fun fact: in manchen Fällen ist "if" langsamer als "switch" und anders herum)
  der eigentliche Skript lag kommt jedoch durch die fehlerhafte Nutzung von spawn/exec.../call befehlen
  generell gilt:
  
  
  • ArmAs asynchrone Skripts sind pseudo asynchron
  • alle asynchrone Skript handle (spawn/exec) sorgen für Skript lag
  • alle synchronen Skript Handles sorgen für merklichen Game lag (Game Performance)

  
  daher sollte man nach Möglichkeit nicht 3 verschiedene Loops erstellen sondern einen Loop in dem die 3 verschiedenen Funktionen abgehandelt werden (weniger Skript Start/Stopp lag pro Frame)
  ohh und noch was ... vermeidet exec... befehle einfach komplett ... es gibt keinen Grund sie zu nutzen außer man hat Dateien die sich zur Laufzeit ändern können
  

• Modelle P - S - E
  Neuer Tank? Neue Waffe? Die schönen Modelle die ihr dann seht sind hier gemeint
  
  Game Performance
  UserMadeContent hat gern eine "höhere" Qualität als der Content der von BI kommt
  das liegt an höher aufgelösten Modellen und anderem
  das ist auch schön und gut, jedoch sollte JEDER wissen dass mehr Polygone weniger Performance bedeutet
  User Made Content hat im Regelfall schlechte bis gar keine LevelOfDetail Modelle und hat auch gern viel zu viele Polygone als das es vertretbar wäre
  daher die schönen Waffen lieber weg packen wenn man eine stabile Frame rate haben will
  
  Stabilität
  Im Grunde nur wenn der Video Speicher vollläuft ... daher keine Auswirkungen hier
  
  Script Performance
  Modelle können keine Skripts ausführen daher keine Auswirkungen
• Sounds P - S - E
  ja ... ich glaub hierzu brauch ich nicht viel schreiben
  
  Game Performance
  keine Auswirkungen
  
  Stabilität
  bestimmte Strukturen könnten eventuell zu CTDs oder Blue Screens führen ... das sind jedoch eher exploits als normale Modifikationen ... dennoch mal aufgeführt (falsche Kodierung = schlecht)
  
  Script Performance
  keine Auswirkungen

damit sollte ich alles zusammen haben
die Themen könnte man jetzt noch vertiefen ... jedoch sollte eine Übersicht eigentlich ausreichen

gruß
X39

X39 es heißst nicht LossOfDetail sondern LevelOfDetail, und bei denen gibt es sehr große Defizite in ArmA da es halt bei mods keine "Regeln" dafür gibt oder diese viel zu locker sind

Zitat von jokoho482

X39 es heißst nicht LossOfDetail sondern LevelOfDetail, und bei denen gibt es sehr große Defizite in ArmA da es halt bei mods keine "Regeln" dafür gibt oder diese viel zu locker sind

ich bin schon froh das ich den zusammenhang nicht komplett verloren hatte in mitten des textes ... dennoch werde ich es korrigieren

Hallo TheConen,

ich habe mir den kompletten Thread aus dem von der verlinkten Forum mal durchgelesen und da sind einige interessante Sachen dabei. Ich habe mir mal ein paar Dinge raus gepickt welche ich kommentieren möchte. (Zitate jeweils von Jaynus)

Zitat

if (((lineIntersectsWith [_eyePos, _shooter modelToWorld [0, 0, (_eyePos select 2) + DFyre_building_scanner], _shooter]) select 0) isKindOf "House") exitWith {};
That line is horribly, horribly bad to run every single shot fired. 15 people shooting at the same time will freeze your game. 30 people in the server engaging at the same time? Forget it.

Das stimmt leider. Das hatte ich damals auch LordJarhead erklärt aber er wollte es unbedingt haben. Trotzdem muss man bei der Aussage aufpassen! Er spricht von Game Freeze und automatischen Latenzen auf dem Server. Dieser Code wird aber immer noch uf dem Client und seiner CPU ausgeführt und hat keine direkte Auswirkung auf den Server und seine Rechenoperationen bzw. auf die Connection. Es kann im worst-case eine Latenz geben. Das ist dann der Fall wenn die Script Engine der Clients überlastet ist und andere Operationen nicht mehr oder nur noch verzögert ausführt, auf welche der Server aber wartet.

Zitat

...incorrect configs and low quality sounds, many of which exacerbate these issues. These configs overwrite classes, load sounds incorrect, set sound metadata incorrect, and generally screw with the game in general.

Das stimmt leider auch und ist das wohl größte Problem an diesem Mod. LordJarhead hat eben leider keine Ahnung von Scripting oder von Configs. Er kann Sounds erstellen. Seine Configs waren anfangs unter A2 auch sehr mieß gewesen. Bei den Configs wurde er dann von, Schande über mein Haupt ich habe seinen namen vergessen, einem ACE-Dev unterstützt. Dieser zog die Configs glatt sodass der .rpt-Spam unter A2 nach einigen Versionen endete. Er spricht ja in diesem Thread oft von der Verbesserungsresistenz von LJ. Keine Ahnung was die beiden da vor 4 Jahren gemeinsam gemacht haben aber das würde ich eben nicht so sehen. Sonst hätte er sich ja nicht von anderen Leuten helfen lassen. Das er die selben fehler wiederholt wird wohl daran liegen das ihm keiner hilft.

Zitat

#1. Sounds always propegate across the network, so it must always be on the server otherwise will you run into performance issues (rpt spam, cache misses, etc). This is not a 'scripts propegate over the network', its an arma thing and unavoidable; if client and server sound mods don't match, you really just cant handle > 25-30 players well; you'll run into performance issues.

Das ist für mich ein sehr sehr strittiger Punkt. Hier gehe ich nicht mit. Es ist ja auch fast das selbe was X39 eben geschrieben hat. Mal Schritt für Schritt. Ja klar, Sounds haben immer etwas mit dem Netzwerk zu tun. Aber das bedeutet ja nicht das ein Soundmod jetzt das Netz mehr belastet als die an der selben Stelle sonst gespielten Vanilla Sounds. Von daher lasse ich diesen Punkt nicht gelten. Und das der Client Side Sound Mod immer auch auf dem Server liegen muss ist nicht richtig. Er will den Soundmod auf den server legen um dem .rpt Spam zu begegnen. Das funktioniert ja auch weil damit die fehlenden Infos (aufgrund der beschissenen Config) dem Server auch bekannt sind. Aber das ist ja nur die Bekämpfung von Symptomen und nicht der Ursache! Wenn die Configs sauber wären, bräuchte der Server auch nicht das Zeug laufen lassen. Daher finde ich diese Aussage so pauschal wie sie da getätigt wurde nicht in Ordnung. Der letzte Release für A2 war sauber und verursachte keine .rpt Einträge mehr. Kein Grund also den Soundmod auf dem Server laufen zu lassen. Im Gegenteil: Warum soll ich den Server mit genau den rechenoperationen belasten welche in den eben davor angesprochenen Punkten angeprangert wurden? Erst dann belaste ich wirklich den Server, also runter damit.
Zu Arma 1 Zeiten haben wir auf Public Servern mit 30 Spielern (Evo) gezockt und es waren mindestens 5 Soundmods auf die anwesenden Spieler verteilt. Der Server hatte trotzdem nicht einen Soundmod und es funktionierte alles. Klar, die Mods mit den schlechten Configs haben die .rpt gespamt. Aber dieser totalitäre theatralische Tonfall suggeriert hier immer das sofortige Ende des Servers und der ganzen Scripting-Environment. Nein, das sind immer noch nur Warnmeldungen. "Sound not found" - na und? Ja, hat den Server nicht zu interessieren. Im Rechenzentrum hört keiner zu.

Das Sounds zwischen den Clients synchronisiert werden bleibt auch weiterhin falsch, davon hat auch Jaynus nichts gesagt. Nichts desto trotz zeigt die .rpt in diesem Thread das aus warscheinlich aus dem "Dragonfire" auch schwere Lags entstehen. (gesichert ist es trotzdem nicht weil man wieder nicht die Rahmenbedingungen kennt. basic.cfg? andere Mods...) Das Gesamtbild deutet aber wohl wirklich darauf hin, dass man den Mod nicht mehr auf Events verwenden sollte. Ein Todesstoß ist definitiv der nicht gegebene Support seit 1.4 seitens des Entwicklers. Und da ja bekanntlich spätestens mit dem Marksmen DLC sich noch einige gravierende Sachen am Sound ändern werden, passen die Configs aus dem Mod dann erst recht nicht mehr. Ich glaub ich werde mir den Mod mal ziehen, langsam interessiert mich wirklich was da verbrochen wurde.

X39, einen Mod ausschließen weil "nur Client" habe ich ja nie behauptet. Natürlich kann ein schlecht geschriebener Client Only Mod negative Auswirkungen auf alles haben. (siehe Fallbeschreibung, nach dem ersten Zitat) Was ich gesagt habe ist, dass es eine der letzten Stellen ist bei der ich suchen würde. Da gibt es ganz andere mögliche Fehlerquellen die wesentlich dramatischer sind. An Config-Dateien selber habe ich leider nicht besonders viel wissen und könnte selber keine schreiben. Ich bin froh wenn ich diese lesen kann. Jedoch einer Config bei Script Performance die Farbe geld zuzuordnen halte ich für gewagt. Ja, du spirchst das Beispiel an. Eine Config führt einen Code an anderer Stelle aus und natürlich hat jedes Script automatisch auch einen kleinen Lag. Aber die Pfade in den Configs dienen zur initialisierung und werden einmalig beim Game- oder Missionsstart ausgeführt. Daher halte ich den Einfluss für mehr als marginal. Oder gibt es wirklich den Fall in der eine Config wie ein Loop Dinge feuert? Dann habe ich sowas noch nie gesehen.

Dafür bekommt Scripting bei mir in Sachen Game Performance sofort den roten Stempel. Und gerade die Missionsmacher sollten hier bescheid wissen da hier die typischen Anwederfehler gemacht werden welche entscheident zu Performanceinbußen beitragen. Und ja, wieder die Script-Latenz. Exec ist nicht gerade sonderlich sinnvoll. Aber ich glaube die aller wenigstens bewegen sich in dem Bereich beim Scripten wo es interessant wird in welchem Frame was genau ausgeführt wird. Von daher würde ich das nicht so verbissen sehen.

Grüße

p.s.: tolles Thema losgetreten

Zitat von Psychobastard

Jedoch einer Config bei Script Performance die Farbe geld zuzuordnen halte ich für gewagt. [...] Oder gibt es wirklich den Fall in der eine Config wie ein Loop Dinge feuert? Dann habe ich sowas noch nie gesehen.

Das ist der grund warum gelb und nicht rot
Es geschieht eher selten das wirklich performance durch die config alleine abfließt es ist jedoch möglich (und ich bin mir ziemlich sicher das es einige heinies gibt die dachten das es das beste ist in jeden panzer von ihnen erst mal einen spawn mit while true rein zu kloppen ...) und nicht soo unplausiebel da einfach

der hauptgrund für gelb und nicht rot liegt jedoch darin das viele CBA mit in die arma funktionalität zählen ... CBA ist nunmal skript basiert und damit letztendlich kommt dabei raus das configs skript lag erzeugen können mit CBA (und zwar nicht gerade unerheblichen)
und da CBA einfach eigentlich auf jedem arma system läuft ... hab ichs dann einfach mit rein genommen (womit es dann gelb und nicht grün wurde)
es sollte jedem ohnehin bekannt sein das configs keine skripts ausführen können und daher absolut null skript lag erzeugen (wobei das auch nicht zu 100% richtig ist ... jedoch auf den großteil der anwender und modder zutrifft)

Zitat von Psychobastard

p.s.: tolles Thema losgetreten

ist aber glaub ich bereits jetzt so stark in OT abgeglitten das es sein eigenes thema verdienen würde ...
problem ist halt immer das selbe ... wie skripte ich richtig
und da kann man in arma ne menge falsch machen (auch als skript "pr0")

Ich finde es ok, das es Thema etwas ins IT gegangen ist. Es freut mich, es auf einem angenehmen Nivoue fachlich interessant diskutiert und Wissen ausgetauscht wird und wurde.

Ein Forum ist genau für soetwas da... schön.

Bis vor Kurzem und nun vermutlich auch bald wieder habe ich an DFyre gewerkelt.
Jaynus hat absolut recht, wenn er schreibt, dass das häufige Nutzen von nearObjects in ES zu Problemen beim Client führen kann, sofern das Spiel bei ihm eh schon nicht so rund läuft.
Derzeit warten wir, was BI noch so alles machen. Allerdings hat Jarhead Bakerman an das Framework gelassen, als ich mal eine Woche keine Zeit hatte.
Ende der Geschichte: JSRS ist derzeit wohl extrem zerschossen, funzt kaum noch und Bakerman hat sich verkrümelt. Ja, ich freu mich aufs Fixen.

Zudem halte ich Jaynus' Aussage, dass sämtliche Sounds übers Netzwerk übertragen werden, für falsch. Zumindest nicht mit dem say3d Befehl, den wir in JSRS benutzen.
Es gibt auch auf dem Dedi/ auf anderen Clientrechnern keine RPT Einträge, sofern sie die Mod nicht mitladen.

Allerdings:
WAS tatsächlich geloggt wird sind Fehler, welche aus der Config hervor gehen.
Vermutlich wurde da in der Vergangenheit geschlampt, denn er spuckt zum Beispiel aus, dass Ihm die Closure und Dry Sounds fehlen würden.
Ich tippe da mal auf eine aus Versehen erstellte oder überschriebene Klasse.

So odr so, ich schau mir das an, sobald Jarhead wieder Zeit und Bock hat... allerdings muss auch ich Bock und vor Allem Zeit haben