sourceserver.info

Sollte man da nicht direkt beim Entwickler ansetzten,
sprich bei Valve. Wenn es von denen eine einheitliche FpsAnzahl gibt,
sowie es mit der Tickrate gemacht worden ist, würde eine Steigerung der Fps ja ein Eingriff in der Server Eninge, sprich ein gehackter Server sein. Und so etwas sollte dann natürlich in den Ligen, bzw generell nicht erlaubt sein, oder sehe ich das zu einfach?

du meinst das VALVE sowas wie fps_max 100 hardcoden soll? weil für alles andere ist VALVE nicht schuld sondern die ach so tolle CS:S community. es wäre schade jedesmal den developer zu fragen dinge zu "fixen" die eigentlich kein problem darstellen sondern nur per community maaslos übertrieben werden.

natürlich wäre für die mit grips (also uns ) die einfachste lösung einfach VALVE zu bitten einen softwarelock zu setzen. sollte auch kein großer aufwand sein aber traurig wärs schon auf solche wege anstatt anständige aufklährung zu setzten.

Hmm da hast du Recht,
wenn es gelingt die Esl Admins davon zu überzeugen, die Spieler mal aufzuklären,
dass mehr Server Fps nichts bringen solange sie stabil oberhalb der Tickrate laufen,
dann wird vieles einfacher. Also ich hab auch immer wieder, unseren neuen Mitgliedern gesagt,
das es nichts bringt wenn ein Server so und soviele Fps hat und habe sie gefragt ob sie jemals,
schonmal Laggs bei uns hatten, Ergebnis nein hatten wir nicht, Server stand auf 100 Fps :D

Ist halt einfach der blöde Effekte, der Allgemein besteht, dass mehr gleich immer besser bedeutet.
Naja ich denke bei solch einem Thema könnte man sich schonmal an den Entwickler wenden,
denn dieser könnte die Abzocke der Anbieter unterbinden, auch wenn jeder Kunde selber dafür verantwortlich ist. Man sollte halt schon wissen, was man sich bestellt und vor allem wieso.
Bestes Beispiel hier im Forum, ich habe einen VServer und kann mich per Filezilla nicht einloggen :D

Wenn die Entwickler es fest einbauen würden, würden die Anbieter es wieder aushebeln. Somit bleibt nur die Möglichkeit es zu verbieten, so dass es selbst die letzten Dummbratzen verstehen.

Es wird alles nichts bringen, den die ach so tollen 10.000 FPS oder auch mehr ist zum Kult geworden und denke das man das aus den meisten nicht aus den Kopf bekommt.

Wie einer in der ESL schon sagte wenn Provider damit Werbung machen und die Kunden dann auf so was rein fallen sind sie es selber schuld, sry das ich das so sage.

Ich für meinen teil machen nicht mehr wie 500 FPS denn alles was darüber ist ist absoluter Schwachsinn und nötiger verbrauch, denn 100-500 Stabile FPS sind besser als 1000-20.000 FPS die immer wieder einbrechen und den Server zum laggen usw. bringen.

Und wenn man selbst so ein Monster von Server hat, würde ich ihn nicht dazu bringen wollen das er mir so viel FPS liefert, dann achte ich lieber darauf das der/die Server schön und sauber Stabil laufen, damit die Spieler in ruhe und mit viel Spaß zocken können und keinerlei Probleme haben.

Den darauf kommt es an, und nicht auf die FPS.

Zitat von »"Terrorkarotte"«

Wenn die Entwickler es fest einbauen würden, würden die Anbieter es wieder aushebeln. Somit bleibt nur die Möglichkeit es zu verbieten, so dass es selbst die letzten Dummbratzen verstehen.

dann würde das aber auch dem ganzen protected prinzip wiedersprechen in dem es nunmal geht den server "pure" zu halten.

wenn die ESL dann sagen würde "aber wir machen eine ausnahme für preload hacks" würden sie ihrer protected philosophie selbs wiedersprechen.

wenn die ESL auf einheitlichkeit und fairness setzten würde hätte es in meinen augen schon längst eine einheitliche techn. spezifikation für kernel geben müssen mit verbot sämmtlicher libhacks.

da die auschlaggebenen settings distributions übergreifend funktionieren müsste man noch nichtmal eine bestimmte distribution erzwingen.
dann bastelt die ESL noch ein wenig an ihrem "wire" ode wie das AC heißt und macht es für server verfügbar.

damit lässt sich auf einen schlag alles normen und kann dies sogar garantieren. ergebniss -> fair play

war ja nur ein beispiel, da die gamed lib ja offensichtlich der sicherheit dient kann man darüber natürlich disskutieren sie als sinnvolle ausnahme zu setzten.

mir wäre es auch egal wenn die ESL 10k FPS als geforderten standart setzten würde (auch wenn es schwachsinn wäre).
aber das liegt wohl eher an mir weil -> i #care about leagues. ist eben nur ein gedanke von mir um dinge zu standadisieren denn ich finde dies sollte es im geist der fairness allgemein geben (siehe nich esport berreich).

denn was den esport bzw. deren server regelungen angeht ist man immer noch auf dem stand der 90er.

Nachteil einer solchen Sperre, es gibt bestimmt plugins die libs benutzen und viele user die NIVHT IN DER ESL spielen. Ich stimme zwar dem fps wahnsinn zu aber das spiel abriegeln, würde ich nicht. Ich würde was bereits vorgeschlagen wurde, zBlock erweitern der die libs bei aktiven zBlock sogar blockiert, wenn das möglich ist. Oder eben, wenn die lib gepreloadet ist, der server sofort wieder durch zblock abschaltet, also rcon quit if lib is preloaded.

Also unser Kernel bringt gerade mal 250 FPS auf den Prüfstand, dafür aber ohne Laggs und Einbrüche. Selbst wenn die Hütte mal voll sein sollte, haben wir nichts zu befürchten

Ich persönlich finde das mit diesem FPS Wahnsinn auch besch***en, aber die Kiddies schreien ja geradezu dannach - Was? Das geht ja gar nicht?! Amüsant finde ich dann immer wieder, wenn wir unsere Serverbeschreibung ändern ... das die Hütte gerammelt voll wird. Wenn Du dann fragst: "Und hat gelaggt? - Nö, lüppt super die Bude mit den HIGH FPS - dann lach ich mich immer halb tot wenn ich denen verklickere das unser Server nur mit 250 FPS läuft. Ich würde alles drum geben - die Gesichter zu sehen

Ja das ist immer wieder amuesant :D

PS: Im steam forum wurde das nun auch gepostet: forums.steampowered.com

Update:
PMs an Echo sowie Kimona (Hidden Path Entertainment - CSS Update Team) gesendet und nach Informationen ueber die Richtigkeit der Antwort von Garry gefragt.



Antworten werde ich hier rein zitieren.

hab mein statement auch mal in dem steam thread geäusert.

btw.: zur klarstellung (war anfangs auch etwas verwirrt)
es ist nicht "der" Garry Newman (von Gmod) sondern Gary Stanely (von http://www.vsnx.net)

Ich bin mir inzwischen relativ sicher, dass es bestimmte FPS-Wwerte gibt, mit denen der Server am besten läuft. Ich hoffe mal, dass Alfred Reynolds noch auf meine Mail anwortet und mir das bestätigt, aber eigentlich entspricht es der Logik. Ticks werden noch immer nur dann berechnet, wenn ein Frame "gerendert" wird. Wenn Tickrate und FPS nicht zusammenpassen, wird die Tickrate unregelmäßig (vgl. Alias-Effekt - auch wenn's ein etwas indirekter Alias-Effekt ist). Wichtig ist also, dass immer, wenn ein Tick kommen sollte, auch wirklich grad ein Frame da ist. Wenn man sich das ganze zeitlich überlegt, bei Tick 66 liegen 15ms zwischen den Ticks (eigenlich also Tickrate 66.66666...), also sollen alle 15ms ebenfalls Frames kommen. Wenn dazwischen noch welche liegen, schadet (und nützt) das nicht. Frames können nur ganzzahlige Millisekunden-Abstände haben, daraus folgt, die Frames müssen entweder eben alle 15ms (66fps), alle 5ms (200fps), alle 3ms (333fps) oder alle 1ms (1000fps) kommen (ld_preload-Tricks etc. ausgenommen, mit denen auch 7.5ms Abstand zwischen den Frames möglich wären).

Wer also seine Tick66 Server mit 100 fps laufen lässt, macht ihn evtl. schlechter, als wenn er mit 66 fps laufen würde! Dadurch kann es durchaus sein, dass jemand 1000fps für besser befindet, als niedrigere FPS, wenn er eben nicht exakt einen dieser Werte trifft.

Übrigens ist ein bissche höher wahrscheinlich schlechter, als ein bisschen niedriger (zumindest bei 66fps). Wenn der Server sagen wir "nur" mit 65fps läuft, ist die Tickrate auch 65fps und es kommt exakt jeden Frame ein Tick. Wenn die FPS aber sagen wir bei 68fps liegen, wir ca. 1x pro Sekunde ein Frame "ausgelassen" (also kein Tick berechnet), da sonst die Tickrate ja über 66 liegen würde. Damit gibt es plötzlich ein Loch von knapp 30ms zwischen zwei Ticks (statt wie gewollt 15ms).

Zugegebenermaßen haben so die 1000fps einen Vorteil: Wenn dieser "Alias-Effekt" passiert, fällt er nicht so dramatisch aus, denn die Ticks werden nur um +- 1ms hin- und hergeschoben. Die Millisekunde ist dabei wirklich total egal, denn die Clients erhalten ja trotzdem noch immer aktuelle Informationen (Simulation des world snapshots und Versenden an die Clients passiert im gleichen Tick/Frame), nur schwankt die Rate, mit der sie diese Informationen erhalten um 1ms. Die 1ms wird komplett abgefangen durch die Interpolation (lerp ist ja viel größer als 1ms), während die zusätzlichen ~15ms beim Alias-Effekt bei 66fps evtl. nicht mehr abgefangen werden können.

Schlußfolgerung: Bei 1000fps ist es einfacher, einen guten Server hinzubekommen. Wenn man aber alles richtig macht, ist mit einem 66fps-Server das Optimum aus der Engine herauszuholen.

das was behaartes etwas sagt hat schon seine richtigkeit würde ich sagen. als das mit dem ganzen FPS wahn angefangen hatte hab ich mich natürlich auch mal schlau gemacht und rausgefunden das die idee höherer ticks nicht im gameserver segment geboren wurde sondern schon seit ca. 15 jahren in der wissenschaft anwendung findet. nur eben mit dem unterschied das dort die effizienz weitaus höher ist da die applikationen dafür ausgelegt sind mit "schnelleren systemen" zu arbeiten.

syncrone anwendungen laufen am effizientesten. asyncrone nicht (verpuffung/delay)

leider habe ich die bookmarks nicht mehr :/

wie auch immer, es ändert nichts daran das src nicht für ein so tickendes system geschrieben geschweige dem optimiert ist.

ich glaube auch das kaum einer etwas gegen 1000FPS als viel mehr um die erhöhung in den 2 stelligen tausender bereich (teilweise gibt es auch 100000 - 250000) und ob es sinn macht das system einem hohen wait load auszusetzten und die dadurch verpuffenden kosten an den enverbraucher weiterzugeben.

denn ob alle 0.1 oder 0.01ms ein fenster bereitsteht ändert sich das verhalten von src nicht.

Zitat von »DeaD_EyE«

D.h. ein vielfaches von 66FPS wäre ideal: 132, 198, 264, 330, 396, 462, ...

Nein! Du musst das in der Zeit rechnen! 66 fps (genauer: 66 2/3 fps = 66.66666... fps) sind 15ms Zeit zwischen zwei Frames. Ein ganzzahliger Teiler von 15ms ist optimal, also 5ms, 3ms und 1ms. Entsprechend 200 fps, 333 1/3 fps und 1000 fps. Hab ich doch auch geschrieben

Wenn du die FPS verdoppelst, halbierst du die Zeit, 15/2ms sind aber keine ganze Zahl und somit nicht erreichbar. Die Engine schläft ja immer ein ganzzahliges Vielfaches von 1ms zwischen den Frames!