Custom Latency Tolerance

Bullzyi

Rare-Mob
Mitglied seit
01.07.2009
Beiträge
456
Reaktionspunkte
3
Kommentare
124
hallo, habe soeben das auf mmo champ aufgeschnappt und verstehe leider nicht so ganz was das zu bedeuten hat. Was mich auch wundert ist das dieser TCPAckFrequency die eigentlich immer als Mythos bezeichnet wurde anscheinend doch irgendwie von Bedeutung ist. Sie wird sogar als " Hack " bezeichnet.... wie gesagt würde gern aufgeklärt werden was das alles bedeuten soll.

As an update to this, the next beta build will include a slider bar (labeled "Custom Latency Tolerance") that lets you tune how sensitive the ability queue is (including sliding it all the way to zero if you choose). This value allows you to control (in milliseconds) how long before the GCD finishes the client will let you queue your next ability.

The optimal setting will probably be right around what your ping time is. So, if your ping is 100 for example, you'd probably want to set it at 100 or slightly higher.

Does that mean that the plans to add in the ability to replace a previous command is out? or is that still a possibility?
That's still in too. It's just that while overriding is helpful it can still fail if your override gets to the server a little too late and your previously queued ability goes off anyways.

why cant you just make the client dynamically change this setting based on the ping rather than make the player choose it and probably get it wrong?
We plan to do this as the default value (when you aren't overriding it) in a future patch. There are some complexities that prevent us from being able to do it right now.

How are you going to address people using the TCPAckFrequency registry hack to "lower" their ping? Are you going to disable it in-game, similar to how you handled the nagle algorithm?
The server now enforces the actual global cooldown value, whereas in the past it allowed a .4 sec slush. So, instead of having a slush factor that let somebody cast a bit early, it now catches the request, waits until the cooldown has actually completed, then casts the spell for you (the queue'd ability) at the soonest possible time.
 
Weder Hack noch Mythos, die Datenpakete kommen dank einzelner, schnellerer Versendungen schneller an. Nur spürbar bei Spielen die viele Datenpakete verschicken. TcPackfreq ist aber shit für die Server.
 
....thema verfehlt, 6 setzen

Edit: dass das Ding dir erlauben soll, ein Taste zu drücken (und damit den folgenden Zauber auszulösen) bevor der serverseitige GCD durch ist, abhängig von deinem Ping, hast du nicht gefragt oder?
 
Zuletzt bearbeitet von einem Moderator:
Suchfunktion nutzen. Das ist der gefühlte 768 Beitrag zu diesem Thema. Nein es bringt nicht wirklich was, ausser das die Anzeige niedriger aussieht. Die Lags bleiben die selben.
Hast du schon mal von spieziellen Netzwerkkarten gehört wie der "KillerNic" oder jetzt die neueste Verarsche die "Killer 2100"
Nicht mal die Karten bringen den gewünschten Effekt und kosten dabei noch 120 - 150€. Also wenn die das nicht können, was denn dann?
 
Zuletzt bearbeitet von einem Moderator:
Ansonsten ganz nett, da man so praktisch keinen Ping mehr hat beim GCD.


Suchfunktion nutzen. Das ist der gefühlte 768 Beitrag zu diesem Thema. Nein es bringt nicht wirklich was, ausser das die Anzeige niedriger aussieht. Die Lags bleiben die selben.

Nein.
 
Zuletzt bearbeitet von einem Moderator:
Test es doch mal mit einem Addon das den wahren Ping anzeigt. Er ist besser. Wenn du dir einreden willst das er es nicht ist dann tu das.

Normal Ingame: 180 MS in Inis, Addon zeigt bei Casts 260+ an.
Mit der geänderten Variable: 50-70 MS, Addon zeigt bei Casts 100+ an.
 
Zuletzt bearbeitet von einem Moderator:
OK Gegenfrage. Was macht der sogenannte Hack? Nein lass mal ich antworte selber.
Er schickt kurz gesagt dein Datenpakete etwas komprimierter/schneller. Soweit so gut. Aber was meinst wieviel das den Server interessiert der diese empfängt? Richtig nämlich gar nicht. Er schickt seine Pakete weiter so wie immer. Gibt es Lags, also wenn die Server rumzicken, dann bringt das genau 0,0 bei dir.
 
Doch, da normalerweise Datenpakete gesammelt werden und dann erst geschickt, deswegen die große Verzögerung in WoW. Mit der Variable schickt er diese einzeln ohne zu Sammeln.
In einfachen Worten.

Edit: Dabei juckt es den Server sehr wohl, da er viel mehr arbeiten muß.
 
Zuletzt bearbeitet von einem Moderator:
okay TE hier... die Frage ist komplett anderes gemeint. Was wurde beim GCD geändert ? Habe die TCPAckFrequency nur aufgeriffen weil wirklich viel darüber gestritten wurde ob es was bringt und mich hat es verwundert das auf einmal diesen Wort im Zusammenhag mit dem GCD erwähnung findet. Bitte nicht um den Sinn Unsinn von TCPAckFrequency diskutieren. Darüber wurde wirklich schon genug geschrieben in den weites des www. Hier geht es nur um den neuen GCD.
 
Am GCD hat sich doch nichts geändert.

Nur die Verarbeitung des Befehls wurde verändert. Bisher ist es so, dass du den Spell nicht auslösen konntest, bevor der GCD auch auf dem Client "abgelaufen" war. Jetzt kannst du den Befehl halt schon 102 ms vorher abesenden und er wird in eine "Warteschlange" gestellt und dann, wenn der GCD beim Server abgelaufen ist wird der Befehl verarbeitet.

So interpretiere ich das.
 
danke @ Mod ... also endet damit das effektive " spammen " um mehr Schaden zu machen da man ein Zeitfenster von ( hier im Beispiel 102 ) ms hat ? Solange man unter 102 ms bliebt beim drücken sollte man gleich viel Schaden machen wie der Spieler der wirklich im 10 ms Intervall die Tasten gespammt hat ? Wäre eine gute Änderung für die Tasterturen aber leider nimmts wieder die Möglichkeit sicher gegenüber anderer faulen Klickern deutlich abzusetzen
 
das ganze soll einfach nur dazu dienen, dass man die lags weniger merkt. normalerweise wird der befehl sofort an den server verschickt und irgendwann kommt die antwort (je länger man warten muss desto größer der lag).

wenn man jetzt nen ping von 200 hat, dann dauert es 0.2 sekunden bis man antwort vom server bekommt. wenn der ping jetzt höher ist kommt man irgendwann an den punkt, dass der client und der server stark asyncron laufen und spells die gecasted wurden einfach abgebrochen werden. die neuerung bewirkt dann das beim casten diese verzögerung mit einberechnet wird.

wenn man jetzt nen ping von 200 hat, dann stellt man am besten 200 ein und jeder cast und auch der gcd dauern dann eben diese 0,2 sekunden länger auf dem bildschirm und bei 600 stellt man 600 ein und dann dauert alles 0,6 sekunden länger. so bleiben client und server syncron wodurch man auch wirklich nur dann nen neuen cast machen kann, wenn der server auch bereit dafür ist. das verbessert dann den spielfluss, da man dann z.b. nichtmehr einen spell casted und nen anderen schon geparkt hat und eine gefühlte ewigkeit warten muss nur um dann zu sehen, dass die geparkte fähigkeit durch den gcd gelöscht wird.

anfangs soll man das noch selbst einstellen müssen und später soll das ganze dann automatisch geschehen.
 
Letzen Endes lässt sich aus dem text gar nichts herausinterpretieren.

Es wird lediglich gesagt dass sowohl client- als auch serverseitig der queue für die Pakete angepasst wird.

Auf Clientseite meiner Meinung nach, völlige Augenwischerei - denn man hat zwar die visuelle Anzeige bzw Bestätigung,
dass es schneller geht - aber real ändert sich nichts.

Letzten Endes nur ein Eingeständniss dass sich der net code wohl doch verbessern lässt - was
wohl keine grosse Überraschung sein dürfte.


Und das ganze individuelle clientseitige TCP/IP tweaking ist sowieso völliger Schwachsinn,
was seinen Höhepinkt bei den CS kiddies findet, die an den TCP/IP Einstellungen rumschrauben
und nicht mal raffen, dass die engine UDP benutzt...
 
Zuletzt bearbeitet von einem Moderator:
Zurück