Wie testet ihr eure Missionen bezüglich Performanc

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Wie testet ihr eure Missionen bezüglich Performanc

    Ich habe mal ne frage an die Missionsbauer.

    Ich selber baue schon fast 1 Jahr Missionen in Arma aber dennoch lässt mich immer ein Problem verzweifeln.
    Ich baue eine Mssion teste im editor und auf dem Server und habe sehr selten probleme mit der performenc und wenn doch wird daran geschraubt.
    Aber dann wenn ich die mission in der gemeinschaft spielen beklagen sich trozdem ein paar leute das sie FPS einbrüche hatten.
    Nun ja wie auch immer ich schaue mir jedes mal natürich die server logs an und kann da nicht feststellen das da scripte sich aufgehängt oder fehler produzieren.
    Auch von der Einheitenzahl gleichzeitig auf der karte sollte es kein problem sein (max 30 Feinde)

    Nun die frage an euch wie testet ihr eine Mission oder habt ihr andere tipps sachen Performance

    Vielen Dank

    florian
  • Grüezi !
    Vorweg, es gibt keine ultimative Lösung.
    Es kann sicherlich am Skript liegen, aber auch am Server oder am PC vom Spieler.
    Sagen wir mal 10 Spieler und deine 30 KI sind definitiv kein Problem. Dann muss man wissen wie die FPS Einbrüche sind.
    Liegen wir hier bei 20 FPS oder weniger ?
    Spielen hier Mods eine Rolle ?
    Du siehst es kann viele Ursachen haben.
    Warum reiben sich Frauen morgens nach dem Aufstehen die Augen?
    Weil sie keine Eier zum Kratzen haben!


    tactical faction action & insurrection
    steamcommunity.com/sharedfiles/filedetails/?id=697756742
  • ja wie du erwähnst hast es kann viele möglichkeiten sein. Städte, Mods , Scripts ,Server ,PC ,Einheitenzahl, Trigger
    naja die frame einbrüche sind meistesn so bei 15 fps.
    bei denn mods habe ich festgestellt das man ihmer mit den rhs fahrzeuge aufpassen muss da die sehr rechen intensiv sind und zum teil lags verursachen.
    ansonsten denke ich einfach das es an der anderen pc liegt da ich ehrlich gesagt nie wircklich problem habe selbst der server nicht.
    Vielen dank für die antwort dachte da es ein test konzept bei den verschieden gruppen gibt.

    mfg Florian
  • Auf jeden Fall lohnt es sich ein gutes Missions Framework zu verwenden, das Unit Caching betreibt und auch schaut das öffentliche Variablen korrekt gesetzt werden. Die meisten bringen noch zuästzliche Boni mit, da muss jeder für sich schauen was passt und was nicht.

    Hier mal die "üblichen Verdächtigen":
    ALiVE
    F3
    Zenophon
  • Hey Florian,

    Hmm das ist nen punkt wo sich viele leute echt streiten wie man das am besten macht. ich glaube die frage ist immer was in der mission ist bzw worum es geht.
    Bei missionen die Stark gescriptet sind ist Testen mit min 15-20 leuten(wenn die Mission so groß ist) Wichtig und Pflicht und auch wenn es Quälent ist!

    Die Punkte die nun kommen sind meine erfahrung und Meinung die ich mir in den letzten Jahren so angesammelt habe.

    Jedoch würde ich ehr von ALiVE abraten weil die erfahrungen die ich bis jetzt damit gemacht habe ist es sehr unperformant.
    Ich Persönlich greife am liebsten zu GAIA und nen kleinen spawn script was ich selbst mal geschrieben haben das AI Spawn und sie dann z.b. an GAIA oder CBA/BIS Tasks übergibt(also die XXX_fnc_taskPatrol/Attack/Defend).

    Caching System Jein!
    Bei kleineren Missionen ziehen diese Systeme die Performace Ehr runter anstadt sie zu verbessern. Dennoch kann man sie benutzten.

    Desweitern sollte man schauen das man am besten auf schleifen verzichtet da diese sehr gerne mal "abstürzen/aufhängen" was dann totale "abstürze/Abrüche" zur folge haben kann.

    Ich selbst fange aktuell an alles ehr über EH(EventHandlers) zu Lösen und damit ist man dann meiner erfahrung nach auf ner sicheren seite.

    Ganz wichtig meiner meinung nach, um Fehler zu vermeiden ist das man sich an eine Nomenklatur hät die man sich selbst irgendwo abschaut.
    als Beispiel:

    Quellcode

    1. JK_var_missionParameter000 = false;
    2. ['JK_spawn_Marker_000', JK_target_Obj_000] call JK_AI_fnc_spawnGroup;
    3. [JK_spawn_Obj_001, 'JK_target_Marker_001] call JK_AI_fnc_spawnGroup;


    1. das JK hier bei steht für Joko
    2. VAR/AI ist hierbei das Module als z.B. Var sind generell Variablen und AI sind meine AI Scripts
    3. fnc kenzeichnet eine funktion
    4. ist meistens die Funktion was es tut oder was es ist

    Dieses verhindert dann
    1. die versehentliche Doppelt Belegung
    2. das die Variablen falsch geschrieben werden
    3. das auch jemand anders was damit anfangen kann und
    4. das man sogar Theoretisch Macros benutzten könnte

    beispiel mit Macros(also so sehen meine aus)

    Quellcode

    1. MGVAR(Parameter000) = false;
    2. [SM(000), TO(000)] call EFNC(AI,spawnGroup);
    3. [SO(000), TM(000)] call EFNC(AI,spawnGroup);

    CBA Macro einbindung: dev.withsix.com/docs/cba/files…t_macros_mission-hpp.html
    CBA Macro erklärung: dev.withsix.com/docs/cba/files…pt_macros_common-hpp.html
    Dazu sollte man meiner meinung nach nicht zuviel Code in ein Trigger schreiben sonder ehr nur Variablen abprüfen und Setzten

    Noch ein Tipp ist das man alles was man in der Mission wirklich nicht braucht auch nicht mit laufen muss inbezug auf Scripts. Das heißst wenn du z.b. nur CBA Patrol benutzt dann muss kein Upson oder GAIA mitlaufen und Perfomace Fressen.

    Und noch ein Tipp:
    Schaue das Leute immer die selben Mods mit am laufen haben das heißst wirklich aufpassen das das alles stimmt und auch Mods die vermeitlich nur "Local" laufen, tun es meistens nicht. Mal als kleines Beispielt hier ist L_ES(das auch in JSRS DragonFyre Full mit drinne ist) meint zwar das es local ist, ist es aber nicht ganz.


    Allesdings liegen die Letztendlichen FPS des Clients auch immer noch an der Hardware des Clients denn ne alte gt9600 und nen Pentium kann arma halt nicht so gut wieder geben wie ne gtx970 und nen I7 ;D.


    Ich hoffe sehr das es etwas weiter helfen konnte und du kannst nun ein paar Performace Probleme/Scripting Probleme weiter verhindern.

    MFG
    Joko
  • Ich halte Unit Caching für überbewertet.

    Gruppen, die weit von den Spielern entfernt sind, haben in einer performanten Mission nichts zu suchen.
    Da liegt die Verantwortung beim Missionsbauer oder bei Zeus, solche Einheiten erst zu Spawnen wenn es nötig ist und ggf auch wieder zu entfernen.

    Außerdem ist die Performancesteigerung geringer als man denkt. Einheit, welche für keinen Spieler sichtbar sind, unsichtbar zu machen, hat keinen Effekt. Der Server hat mit der Sichtbarkeit sowieso nichts am Hut.
    Entfernt man Einheiten aus einer Gruppe reduzieren sich die benötigten Berechnungen (pro Frame) nicht proportional zur Gruppengröße, da der Großteil der Berechnungen nur einmalig pro Gruppe durchgeführt wird und unabhängig von der Anzahl der Einheiten ist.

    Dadurch ist es (wie in Post oben schon geschrieben) nicht selten der Fall, dass ein Script das diese Aufgabe übernimmt ein unbefriedigenderes Spielerlebnis bringt als erwartet.
    Man muss auch bedenken, dass das Hinzufügen des Script erstmal die Performance senkt und nur für den Fall, dass sich Einheiten weit entfernt befinden, diese wieder steigert. Um die ursprüngliche Performance wieder herzustellen muss sich also zwangsläufig mindestens eine ungünstig platzierte Einheit in der Mission befinden.

    In Ausnahmefällen (24h Missionen, o.Ä.) macht es Sinn ein solches Script zu verwenden.
    Aber wer eine Mission in einem solchen Umfang baut, sollte auch selbst in der Lage sein seine gespawnten Einheiten zu kontrollieren und benötigt kein externes Script.

    101st Airborne Division
    airborne-division.de

    TaktiCool (ArmaAtWar, CLib, Streamator)
    github.com/TaktiCool
  • Unheilligkeit schrieb:

    [...] Aber dann wenn ich die mission in der gemeinschaft spielen beklagen sich trozdem ein paar leute das sie FPS einbrüche hatten. [...]

    Es beklagen sich immer leute über die performance
    und bei der eigentlichen performance kann man über die script seite nicht sonderlich viel machen
    scripting wirkt sich hautpsächlich als script-lag aus und nicht auf der FPS
    einzige ausnahme:
    synchrone scripte (alles wo ein "sleep 1" befehl z.B. versagen würde)
    auf diesen script raum wird nämlich "gewartet" sodass er tatsächlich die FPS stören kann und wird (wenn falsch verwendet)
    für den otto normal scripter jedoch uninteressant da hier die meisten scripte mit einem spawn im asynchronem bereich laufen (ausnahme hier wieder: server, hier gilt übrigens die selbe regel wie beim client! synchrone bereiche so schnell wie möglich verlassen) und kaum event handler verwendet werden die "schwehre" operationen durchführen


    jokoho482 schrieb:

    [...] Ganz wichtig meiner meinung nach, um Fehler zu vermeiden ist das man sich an eine Nomenklatur hät die man sich selbst irgendwo abschaut.
    als Beispiel:

    Quellcode

    1. JK_var_missionParameter000 = false;
    2. ['JK_spawn_Marker_000', JK_target_Obj_000] call JK_AI_fnc_spawnGroup;
    3. [JK_spawn_Obj_001, 'JK_target_Marker_001] call JK_AI_fnc_spawnGroup;


    1. das JK hier bei steht für Joko
    2. VAR/AI ist hierbei das Module als z.B. Var sind generell Variablen und AI sind meine AI Scripts
    3. fnc kenzeichnet eine funktion
    4. ist meistens die Funktion was es tut oder was es ist

    Dieses verhindert dann
    1. die versehentliche Doppelt Belegung
    2. das die Variablen falsch geschrieben werden
    3. das auch jemand anders was damit anfangen kann und
    4. das man sogar Theoretisch Macros benutzten könnte [...]

    Man sollte hierbei erwähnen das der standard form (genutzt von BI) wie folgt ist:
    <TAG>_fnc_<NAME>


    NetFusion schrieb:

    Ich halte Unit Caching für überbewertet. [...]
    Außerdem ist die Performancesteigerung geringer als man denkt. Einheit, welche für keinen Spieler sichtbar sind, unsichtbar zu machen, hat keinen Effekt. Der Server hat mit der Sichtbarkeit sowieso nichts am Hut. [...]


    es stimmt zwar das der server die einheiten nicht rendert und damit einheiten unsichbar machen nichts ändert, jedoch ist auch die annahme das unit-chaching scripte einheiten "unsichtbar" machen falsch

    caching scripte zerstören einheiten und spawnen sie wieder wenn sie wieder benötigt werden (also einheiten in die nähe kommen)
    und der performance unterschied ist hierbei signifikant

    [...] Entfernt man Einheiten aus einer Gruppe reduzieren sich die benötigten Berechnungen (pro Frame) nicht proportional zur Gruppengröße, da der Großteil der Berechnungen nur einmalig pro Gruppe durchgeführt wird und unabhängig von der Anzahl der Einheiten ist. [...]

    nur teilweise richtig

    richtig ist: es gibt berechnungen die schwehr sind und pro gruppe durchgeführt werden
    jedoch wird für jede einheit ebenfalls eine separate berechnung durchgeführt (sonst würde die AI sich nicht verhalten wie sie sich verhält)

    [...] Dadurch ist es (wie in Post oben schon geschrieben) nicht selten der Fall, dass ein Script das diese Aufgabe übernimmt ein unbefriedigenderes Spielerlebnis bringt als erwartet.
    Man muss auch bedenken, dass das Hinzufügen des Script erstmal die Performance senkt und nur für den Fall, dass sich Einheiten weit entfernt befinden, diese wieder steigert. Um die ursprüngliche Performance wieder herzustellen muss sich also zwangsläufig mindestens eine ungünstig platzierte Einheit in der Mission befinden. [...]

    Es stimmt zwar das die scripte gern mehr stören wenn falsch verwendet als dass sie nützen, die performance sollten sie jedoch dennoch bei entsprechender server HW nicht beeinflussen ("spawn"-scripte haben festgelegte run zeiten weswegen es bei einem einzelnen spawn gern passiert das die performance des scripts runter geht ohne das irgend was sich augenscheinlich geändert hat was so viel bedeutet wie: abhängig von der anzahl der spawns (die ohnehin niedrig gehalten werden sollte ...) geschieht keine performance änderung)

    [...] In Ausnahmefällen (24h Missionen, o.Ä.) macht es Sinn ein solches Script zu verwenden.
    Aber wer eine Mission in einem solchen Umfang baut, sollte auch selbst in der Lage sein seine gespawnten Einheiten zu kontrollieren und benötigt kein externes Script.

    würde eher sagen dass in Public-Server missionen ein solches script notwendig ist (wobei die missionen in public servern ja ohnehin nicht für performance bekannt sind ...)
    eine mögliche implementation eines eigenen unit-caching systems lässt sich übrigens hier (XLib Insurgency Modul - Ein stark vereinfachtes "chaching" script) finden
  • X39 schrieb:

    jedoch ist auch die annahme das unit-chaching scripte einheiten "unsichtbar" machen falsch


    Werf mal einen Blick in das F3 AI Caching Script.

    X39 schrieb:

    bei der eigentlichen performance kann man über die script seite nicht sonderlich viel machen
    scripting wirkt sich hautpsächlich als script-lag aus und nicht auf der FPS


    Da muss ich widersprechen. Scripte sind ein Faktor, der in Bezug auf Performance eine große Rolle spielt und die Erfahrung hat gezeigt, dass hier die häufigste Ursache für unperformante Missionen liegt.
    Performance ist für mich die Dauer der durchgeführten Berechnungen pro Frame. Daraus kann man also direkt die FPS ableiten.
    Lags haben immer etwas mit Netzwerken und Datenübertragung zu tun. Sie kommen zwar in Arma auch vor (Desync), haben aber primär nichts mit Scriptperformance zu tun.

    Um nochmal zurück zum Topic zu kommen:

    Stellt euch vor ihr habt ein Script und wollte dessen Performance messen. Das Script steht direkt in der init.sqf und beinhaltet keinen spawn oder execVM Befehl (es läuft in einem "Unscheduled Environment").
    Um die Laufzeit zu messen kann man nun einfach vor und nach dem Script diag_tickTime auslesen. Die Differenz ist der gesucht Wert. Hierbei sollte natürlich beim Optimieren ein möglichst kleiner Wert erreicht werden.

    Läuft das Script in einem "Scheduled-Environment", ist das Messen der Laufzeit komplizierter. Der Scheduler der Engine bestimmt nämlich wie viel Laufzeit dem Script zur Verfügung gestellt wird. Das hängt in erster Linie davon ab, wie viele andere Scripte zur gleichen Zeit noch laufen sollen. Es kann also vorkommen das ein Script, welches eigentlich Recht simpel ist, auf einmal sehr langsam ist, da andere Scripte dieses blockieren.
    Die Ergebnisse einer Performancemessung sind hier also nicht verlässlich und in manchen Fällen sogar Irreführend.

    Man sollte also alle Scripte im "Unscheduled-Environment" laufen lassen (ja das geht). So können aussagekräftige Messungen bezüglich Performance durchgeführt werden. Weitere Details beschreibt auch das ACE3-Team hier.

    X39 schrieb:

    die meisten scripte mit einem spawn im asynchronem bereich laufen


    Und damit können die meisten nicht vernünftig ihre Performance messen. Was eine Erklärung dafür ist, dass es so viele schlechte Scripte gibt.

    101st Airborne Division
    airborne-division.de

    TaktiCool (ArmaAtWar, CLib, Streamator)
    github.com/TaktiCool
  • NetFusion schrieb:

    Werf mal einen Blick in das F3 AI Caching Script. [...]

    für schlechte scripte kann ich nun wirklich nichts ... aber gut zu wissen :P

    NetFusion schrieb:

    [...] Da muss ich widersprechen. Scripte sind ein Faktor, der in Bezug auf Performance eine große Rolle spielt und die Erfahrung hat gezeigt, dass hier die häufigste Ursache für unperformante Missionen liegt. [...]

    Ich kann dir versprechen dass schlecht gemachte addons die schlechte LODs und ähnliches haben einen erheblich größeren impact haben (gibt auch ein schniekes video von dslyecxi darüber) als alles andere
    die AI (gespawnte) hat ebenfalls einen erheblich größeren impact als jedes script jemals haben kann da jedes objekt auch irgendwie dargestellt wird und berechnet sowie synchronisiert wird (wenn auch mit zunehmender distanz immer unpriorisierter)

    NetFusion schrieb:

    [...] Performance ist für mich die Dauer der durchgeführten Berechnungen pro Frame. Daraus kann man also direkt die FPS ableiten.[...]

    das ist korrekt

    NetFusion schrieb:

    [...]Lags haben immer etwas mit Netzwerken und Datenübertragung zu tun. Sie kommen zwar in Arma auch vor (Desync), haben aber primär nichts mit Scriptperformance zu tun. [...]

    genau falsch
    scripte die sich permanent synchronisieren (bzw. permanent netzwerk "spam" verursachen) sind der ursprung dieser wunderherrlichen gelben ketten
    ArmA selbst verursacht im vanilla zustand ohne mods o.ä. solche gelben ketten nämlich nur in den seltensten fällen und auch nur bei einem spieler
    Hier haben scripts wirklichen impact! Netzwerk performance wird hauptsächlich durch scripte gesenkt (glücklicherweise laufen jedoch die scripte mit niedriger prio sodass es meist nicht schlimmer als gelbe kette wird)

    NetFusion schrieb:

    [...] Um nochmal zurück zum Topic zu kommen:

    Stellt euch vor ihr habt ein Script und wollte dessen Performance messen. Das Script steht direkt in der init.sqf und beinhaltet keinen spawn oder execVM Befehl (es läuft in einem "Unscheduled Environment").
    Um die Laufzeit zu messen kann man nun einfach vor und nach dem Script diag_tickTime auslesen. Die Differenz ist der gesucht Wert. Hierbei sollte natürlich beim Optimieren ein möglichst kleiner Wert erreicht werden.

    Läuft das Script in einem "Scheduled-Environment", ist das Messen der Laufzeit komplizierter. Der Scheduler der Engine bestimmt nämlich wie viel Laufzeit dem Script zur Verfügung gestellt wird. Das hängt in erster Linie davon ab, wie viele andere Scripte zur gleichen Zeit noch laufen sollen. Es kann also vorkommen das ein Script, welches eigentlich Recht simpel ist, auf einmal sehr langsam ist, da andere Scripte dieses blockieren.
    Die Ergebnisse einer Performancemessung sind hier also nicht verlässlich und in manchen Fällen sogar Irreführend. [...]

    Das ist korrekt, mehr dazu jedoch in der folgenden quote ...

    NetFusion schrieb:

    [...] Man sollte also alle Scripte im "Unscheduled-Environment" laufen lassen (ja das geht). So können aussagekräftige Messungen bezüglich Performance durchgeführt werden. [...]

    Gute idee! Dann gibt es wenigstens nicht mehr einen script lag sondern dann geht wenigstens alles wirklich auf die FPS <3
    der scheduler vergibt die performance nicht fair sondern strikt (irgendwas mit 3 war es ... glaube max. 0.03s laufzeit kann ein script beanspruchen ... bin mir jedoch nicht sicher und finde die referenz im wiki momentan nicht da es sich hier um eine unterseite von irgend einer beschreibenden seite handelte und kein befehl) daher geschieht es auch das ein script mal gar nicht in einem frame dran kommen kann wenn die schedul liste zu hoch ist

    wunderbar erkennen lässt es sich übrigens wenn man den direkt vergleich call und spawn macht
    der spawn wird immer langsamer über der zeit sein als der call
    warum ist auch recht einfach: der scheduler gibt dem spawn nicht die 100% möglichkeit sondern die strikte einstellung

    kurze erläuterung zu spawn und call ...
    synchron (call aus nicht-spawn) blockiert den frame
    asynchron (call aus spawn oder eben spawn) nicht

    daher kann man noch so viele spawns haben und sie werden sich kaum auf die performance draufsetzen
    es erhöht sich der script lag und irgend wann ist der scheduler dann überfordert (das ist wenn es dann auf die performance geht ... vorher hat einen jedoch der 5 sekunden script lag gekillt)

    anders herrum bedeutet es das man schwehre operationen NIEMALS in einem synchronem raum ausführen sollte (außnahme: es ist eine einmalige operation die am anfang durchgeführt wird, hierbei sollte jedoch noch angemerkt werden dass eine solche operation entsprechend den spieler so lange blockieren sollte da dieser nichts davon mit bekommen dürfte im regelfall)

    performance löcher verursacht durch scripts sind daher so realistisch wie die 77 jungfrauen wenn sich der tali in die luft sprengt


    mit freundlichen grüßen
    X39
  • Psychobastard schrieb:

    (finde die Aussagen von dir NetFusion nämlich sehr gefährlich da es nur Halbwahrheiten sind)


    Wieso so klein und in Klammern?

    Ich finde es schade so etwas ohne ein Beispiel oder sonstige Information für die Halbwahrheit meiner Aussagen, hier zu lesen. Das schadet einzig der Glaubwürdigkeit meiner Aussagen. Oder hattest du einen anderen Gedanken dabei?
    Ich gebe Tipps um das Spielerlebnis der Community in Arma zu verbessern und bisher hat sich noch niemand, der meine Ratschläge befolgt hat, beschwert oder Ähnliches.

    Trotzdem interessiert mich was an meinen Aussagen gefährlich sein soll...

    Wo wir schon bei Kritik sind:
    Ich habe, nicht nur hier im Topic, viele Unwahrheiten gelesen (in Zusammenhang mit SQF), wo ich nicht (wie manch anderer) einzeln widerspreche. Denn zu behaupten etwas sei richtig bzw. falsch, erfordert meiner Meinung nach immer einen Beleg und ich habe einfach nicht die Zeit dafür.

    Ich selbst kenne meine Erfahrung im Bereich Informatik und kann auf diese Vertrauen. Daher erachte ich es auch nicht als notwendig jede meiner Aussagen von Anfang an zu belegen. Ich kann auch nachvollziehen, dass ihr diese nicht kennt und daher meinen Aussagen gegenüber kritisch eingestellt seid.

    101st Airborne Division
    airborne-division.de

    TaktiCool (ArmaAtWar, CLib, Streamator)
    github.com/TaktiCool
  • Wieso so klein und in Klammern?

    Weil es nicht die Kernaussage meines Posts werden sollte.

    Trotzdem interessiert mich was an meinen Aussagen gefährlich sein soll...

    Weil unerfahrene Leser hier nach Lösungen für Ihre Probleme suchen bzw. lernen wollen. Diese Aussagen können also nicht von allen hinterfragt werden. Das führt dazu das die Dinge als gegeben hingenommen werden die eben nicht korrekt sind.

    Ich habe, nicht nur hier im Topic, viele Unwahrheiten gelesen

    Ja stimmt. Der Unterschied ist aber das bei anderen zu sehen ist was eine Hilfe oder eine Lösungsidee ist. Du schreibst deine Texte wie Gesetze und trittst als Informatiker auf. Das ist ein völlig anderes Erscheinungsbild. (Professionalität vermittelt Sicherheit)

    Ich selbst kenne meine Erfahrung im Bereich Informatik und kann auf diese Vertrauen.

    Ja das ist auch gut so - ich bin z.B. kein Informatiker. Aber selbst wenn Bill Gates hier etwas postet, würde ich ihn hinterfragen. Das liegt ganz einfach an den spezifischen Eigenschaften von Arma bzw. der Engine. Wie da was warum ist lernt/versteht man eben nur über die Jahre. (oder du ließt dir das komplette Wiki am Stück durch XD)



    So, das ist trotzdem alles OT - damit noch was zum Topic kommt:
    Wenn ich die Performance echt messen möchte, dann handhabe ich das eigentlich nur über Simulation und auch nur an Komplexen die ich für kritisch erachte. Mit Simulation meine ich dann ich schätze ab was die normale Belastung sein wird (gemessen an Spielerzahl z.B., oder KI Menge, Anzahl Partikel, etc... - Fallabhängig) und übertreibe den Fall um das x-Fache. Wenn ich z.B. mein AI-Handling prüfen möchte (spawn, despawn, movment, etc...) und das Ziel ist es 10 Gruppen a 12 Mann + 3 Fahrzeuge zu organisieren und in Zeit x zu spawnen, dann lasse ich eben doppelt so viele in der halben Zeit spawnen und beobachte dabei die Frames bzw. zeichne via diagTickTime o.ä. an kritischen Stellen mit.


    Grüße

    ___<<<my A2 Missions>>>___<<<A3 Wounding System>>>___