Paar Performance Fragen

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

  • Paar Performance Fragen

    Hey, es gibt so einige Sache, die ich mich immer gefragt habe in Bezug auf die Performance.
    Vielleicht kennt ja jemand die Antwort darauf.

    1. Bei jedem Schaden zum Angegriffenen wegen Bloodscreen triggern oder clientseitig dauerhaft eigenes Leben vergleichen, bei weniger Leben Bloodscreen starten?
    Die Frage in Bezug auf einen Tactics Server, wo dauerhaft nur geballert wird (z.B. pro Minute 200+ Treffer).

    2. Bei triggerClientEvent die Argumente einzeln reinpacken oder als Tabelle übergeben?

    LUA-Quellcode

    1. triggerClientEvent ( player, "asd", player, { "hi", "du", "ei" } )
    2. triggerClientEvent ( player, "asd", player, "hi", "du", "ei" )
    Macht das überhaupt einen Unterschied?

    3. Funktion erstellen oder Variable?
  • Zum Hilfreichsten Beitrag springen

  • Hilfreich

    1) Clientseitig.
    2) Ich gehen nicht davon aus, dass das irgend ein Unterschied macht. Die Tabelle ist vermutlich aufgrund ihres Datentypes etwas größer. Aber auf die paar bytes wird es wohl nicht ankommen. Ist aber nur eine Vermutung.
    3) In Bezug auf was?

    Du machst dir viele Gedanken über Performance. Grundsätzlich gut, aber du scheinst es komplett übertreiben zu wollen :D
  • :D
    Ich würde es eh nicht mehr ändern, mich hat nur gerade die 1. Frage beschäftigt und dachte mir "hmm, wieso frage ich nicht gleich auch die anderen Sachen" :D

    Beispiel für die 3. Frage:

    LUA-Quellcode

    1. function getPointsByLevel ( level )
    2. return level * 313506012
    3. end
    4. -- vs --
    5. levelpoints = {}
    6. for i=1, 100 do
    7. levelpoints[i] = i*313506012
    8. end
    Welche Methode wäre hier besser?
    Ich denk mir, dass die 2. Variante besser sein könnte.
    Ist auch nur ein Beispiel, was ich mir gerade ausgedacht habe - hab mich sowas schon immer gefragt :D
  • 1. onClientPlayerDamage ist dein Freund
    2. Ohne Table wird minimal weniger Netzwerklast verursachen. Grundsätzlich sollte das aber kaum einen Unterschied machen. PewX hat da recht was die zusätzlichen Bytes betrifft.
    3. Funktion. Wenn du das als Table verwenden willst, dann geht das auch via __index Metamethode auf einer leeren Table.
    Mich per PN bezüglich Freischaltungen zu nerven ist der beste Weg eine Freischaltung zu verhindern.

    neon-gaming.de
  • sbx320 schrieb:

    1. onClientPlayerDamage ist dein Freund
    2. Ohne Table wird minimal weniger Netzwerklast verursachen. Grundsätzlich sollte das aber kaum einen Unterschied machen. PewX hat da recht was die zusätzlichen Bytes betrifft.
    3. Funktion. Wenn du das als Table verwenden willst, dann geht das auch via __index Metamethode auf einer leeren Table.
    Die Schüsse werden total komisch synchronisiert.
    onClientPlayerDamage für source bei Beschuss zu nutzen ist ein großer Fehler, da der Bloodscreen sehr oft erscheint, wenn man überhaupt nicht angeschossen wird. Umgekehrt genauso, manchmal erscheint es, obwohl man keinen Schaden bekommen hat. onClientPlayerDamage bei Beschuss ist nur zu gebrauchen, wenn man die Info beim Angreifer nutzt.
    Ist übrigens bei onPlayerDamage ähnlich.

    Und danke für die Tipps :D
  • Bei onClientPlayerDamage musst du natürlich prüfen woher der Schaden kommt und wieviel ankommt. Bei 0.5hp Schaden macht eine große rote Einblendung nicht viel Sinn.

    Das Problem was du beobachtet hast ist dass du nur Schaden erhälst, wenn du lokal angeschossen wirst. Was auf anderen Clients passiert ist egal.
    Mich per PN bezüglich Freischaltungen zu nerven ist der beste Weg eine Freischaltung zu verhindern.

    neon-gaming.de
  • Ich hatte damals, als ich neu angefangen hatte, den Bloodscreen bei source starten und den Damage vom Angreifer triggern lassen.
    Dabei hatten wir sehr oft das Problem, dass man keinen Bloodscreen trotz Schüssen bekommen hat oder andersrum.
    Das Problem hatte ich sehr lange, bis ich es irgendwann dann so gemacht habe, dass der Angreifer den Schaden triggert und serverseitig dann zum source getriggert wird, dass er angeschossen wurde und Bloodscreen starten soll.
    Habe dabei bemerkt gehabt, dass die Schüsse eben total unsynchron sind und wenn man bei sich einen Schuss bei sich abbekommt, onClientPlayerDamage getriggert wird, obwohl der Angreifer eigentlich nicht getroffen hat.

    Ich habe es gerade getestet:
    Wenn man steht, scheint es nicht so verschieden zu sein.
    Fängt man aber an zu rennen, wird der Schaden plötzlich ganz anders erkannt.

    Source: 28 - Angreifer: 52

    Das hatten wir raus, beim Getroffenen wurde onClientPlayerDamage nur 28x getriggert, beim Angreifer ganze 52x.
    Da ist ein riesen Unterschied.

    Im Vergleich dazu, wenn man nicht rennt, also nur stehen bleibt:
    Source: 181 - Angreifer: 181
    Wenn man stehen bleibt, scheinen die Schüsse ordentlich erkannt zu werden.
    Hängt wohl von der Positionsabfrage ab o.ä.


    Naja, kurz:
    onClientPlayerDamage beim Getroffenen zu nutzen und je nachdem Bloodscreen zu starten ist keine so empfehlenswerte Methode :/


    Oder hier sieht man es auch gut (Waffe: Rifle):
    [Blockierte Grafik: http://i.imgur.com/QoGtlD4.jpg]


    Edit:
    Sind mal weiter gegangen, haben dieses Mal mit MP5 gesprayt in kürzester Entfernung:
    Source: 444 - Angreifer: 272
    Da ist ein riesen Unterschied.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Gelöschter Benutzer ()

  • Dass Schüsse in der Bewegung nicht 100%ig synchronisiert werden, wird so einfach nicht zu beheben sein, da Bewegungen ja interpoliert werden.

    Das bedeutet das zwischen 2 Ticks in denen der Server die neuen Positionsdaten aktualisiert, die Clients anhand der letzten Bewegungsdaten die neuen Positionen pro Frame nur erraten bzw. erahnen. Das sind in der Regel zwar nur kleine abweichende Nuancen, aber sie sind eben da und zwar für jedes der beteiligten Elemente.

    Der Angreifer, der Angegriffene sowie das Projektil haben für jeden Client also Momente, in denen die Position nur mit der nächst höchsten Wahrscheinlichkeit wiedergegeben werden um die Bewegung flüssig darstellen zu können.

    Der beste Weg wäre wahrscheinlich zu versuchen aus dem vom Client getriggerten Treffern, sowie dem vom Server gemeldeten Treffern irgendwie einen gemeinsamen Mittelwert zu bilden. Wäre dann zwar immer noch nicht genauer aber für alle Beteiligten gleich Scheiße und somit fair. :D