Germany
EU
Action: Counter-Strike: Source 
[INFO] Wissenswertes
| Author | Posting |
| Hallo! Habe mir mal gedacht, dass ich den CS:S-Spielern, die nicht so viel mit CFGs zu tun haben, einen kleinen Gefallen tue und mal ein paar Sachen aufschreibe, womit sie ihr Spielgefühl verbessern können. Dazu gibt es aber auch ein bisschen Hintergrundwissen. Also für Leute, die nicht Fan von langen Texten sind, können den Thread ignorieren  1. Erklärung des Datentransports anhand von CS:S (mit UDP/TCP Vergleich) Um das ganze mal etwas anschaulicher für Leute zu machen, die keine Lust auf Fachausdrücke und syntaktisch korrekten Bezeichnungen haben, sehen wir uns doch mal den Datentransport als bildlichen Vergleich mit einer Autobahn an (Das wohl am meisten genutzte bildliche Beispiel ): Größe der Autobahn = Bandbreite Die LKWs = Pakete Ladung eines LKWs = Paketinhalt/Daten Köln = Client Düsseldorf = Server Zeit => Köln-Düsseldorf = Ping "rate" steuert die größe der Autobahn in 2 Richtungen, sodass mehr LKWs fahren können, ohne dass ein Stau entsteht. Und wie wir alle wissen sorgt eine größere Autobahn ja nicht für eine kürzere Fahrtzeit, aber das ist ja ein altes Thema. "cl_updaterate" sagt, wieviele LKWs pro Sekunde von Düsseldorf nach Köln fahren (Server -> Client). Es sagt NICHT aus, wieviel ein LKW an Ladung dabei hat (Menge an Daten pro Paket nicht durch cl_updaterate gesteuert, zumal sie eh vom Server bestimmt wird). "cl_cmdrate" bestimmt die Anzahl der LKWs pro Sekunde von Köln nach Düsseldorf (Client -> Server). Selbe wie "cl_updaterate" nur umgekehrt. "net_maxfragments" bestimmt, wieviel EIN LKW an Ladung MAXIMAL (!) haben darf, bevor der Rest der Ladung an einen weiteren LKW übergeben wird. Wir wissen alle, dass vollgeladene LKWs langsamer fahren, als leichtbepackte (kleinere Datenmenge -> schneller beim Server), allerdings limitieren wir ja die maximale Anzahl der LKWs pro Sekunde durch die 2 Befehle "cmdrate" und "updaterate". Was ich damit sagen will ist: Selbst wenn wir die Ladung verringern, fahren nicht mehr LKWs nach Düsseldorf, weil wir nur maximal 100 fahren lassen dürfen. Im Grunde schicken wir einfach nur weniger Ladung hin, als wir die eigentliche Möglichkeit dazu hätten, wenn wir "net_maxfragments" (oder von mir aus auch die MTU) verringern. Was aber passieren kann ist, dass weniger beladene LKWs schneller von der Annahmestelle in Düsseldorf durchsucht und verarbeitet werden (niedriger net_maxfragments/MTU Wert sorgt für eine schnellere Bearbeitung der Daten). Schnelligkeitsvorteil wäre es hier, allerdings schicken wir auch weniger Daten hin. (Man muss dabei aber auch bedenken, dass "net_maxfragments" die MAXIMALE Bytezahl definiert... Es kann ja auch sein, dass diese niemals eingehalten wird und man oft unter dem 1280 Wert bleibt). Jetzt der Vergleich mit UDP und TCP: Würden die Spieldaten von CS:S per TCP übertragen, so würden wir erst einen weiteren LKW von Köln nach Düsseldorf schicken, wenn Düsseldorf gesagt hat "Jungs, der LKW ist angekommen!". Was das an verzögerung bedeutet, könnt ihr euch selber zusammenrechnen (Pro Paket 20ms -> 50 Pakete pro Sekunde maximal). Daher läuft CS:S und auch der Vorgänger über das UDP Protokoll... Sonst würden wir ziemlich stark die Verzögerung merken, indem alles durchgehend Ruckeln würde, sogar unsere eigene Bewegung wäre abgehakt. Ihr wollt es testen? Installiert euch mal das Bomberman Online Game. Da könnt ihr am Start (Bzw. konntet damals, lange nich mehr gespielt) wählen, ob ihr per UDP oder TCP Protokoll spielen wollt. Da merkt ihr dann den Unterschied. 2. WTF ist eigentlich "Interpolation" und warum redet jeder über einen Bug ? Interpolation ist in der hohen Mathematik eine bekannte Methode, um zwischen 2 Positionen einen nicht vorhandenen Zwischenweg zu berechnen (Interpolation von lat. 'interpolare' = "verfälschen, entstellen", im übertragenen Sinne auch "zwischen einfügen"). Weil ein Server Datenpakete nicht konstant in einem durchgehenden "Strang" zum Spieler gesendet werden, sondern immer Abschnittsweise, ist die Interpolation auch in Games bzw. CS:S wichtig. Gegnerpositionen werden bekanntermaßen in Datenpaketen überliefert und kommen visualisiert so beim Spieler an: x x x x x x x x 0 15 30 45 60 75 90 105 Die Zahlen geben in Millisekunden an, wann das nächste Paket ankam (Nur fiktive Zahlen ums anschaulich zu halten). Denkt man jetzt logisch, so kommt man zu der Erkenntnis, dass jede Position des Gegners auf dem Monitor alle 15ms verändert wird. Da wir keine Interpolation haben, bewegt sich der Gegner also mit "Miniteleports" (= Laggendes Model = cl_interpolate 0) im 15ms Takt vorwärts. Er hat ja keine Zwischenbewegungen!!! Mit Interpolation sähe das Ganze so aus: x-----x-----x----x-----x-----x-----x-----x 0 15 30 45 60 75 90 105 Die "-"-Striche geben die hinzuberechnete Zwischenbewegung an. Ihr seht, dass egal wieviele Pakete pro Sekunde ankommen würden, wir immer eine flüssige Gegnerbewegung hätten. Da diese Positionen allerdings hinzuberechnet wurden und nicht wirklich existieren, sind sie 1. ungenau und wenn die Rechnungen aufgrund von Fehlern falsch laufen 2. falsch. Heißt im Klartext: Falsche Interpolation führt zur Anzeige einer falschen Gegnerposition (= "ALTER ICH WAR SO DRAUF, ABER ES GEHT NICHTS REIN!") Die Interpolation findet auf eurem PC statt und nicht auf dem Server. Darum gibt es viele Faktoren bei euch, die diese Interpolation nochmals verfälscht oder beeinträchtigt. Nun zum Interpolationsbug: Interpolation ist eine Rechnung. Rechnungen beanspruchen Zeit. Zeit verzögert Ausgaben. Wenn ihr die Aufgabe "1+1" bekommt, antwortet ihr für euch blitzschnell "2!", aber bis zur Antwort vergehen trotzdem an die 50ms. Ein PC rechnet zwar viel schneller, brauch aber für diese komplexe Rechnung auch eine gewisse Zeit. cl_interp steuert diese Zeit in Sek. Die Daten müssen ja erstmal gespeichert werden, dann muss damit die Zwischenbewegung berechnet werden und DANN kann man erst diese Bewegung sehen! Kurz und im Klartext: Daten kommen zum Client-PC -> Interpolationsrechnung wird durchgeführt -> Bewegung und Position auf dem Monitor erst JETZT sichtbar! Die Daten werden erstmal verwertet bevor sie ausgegeben werden und genau da steuert (wie bereits gesagt) cl_interp/ex_interp. cl_interp 0.01 heißt, man sieht das Model also 10 ms später aufm Bildschirm, wenn es sich bewegt. Der Interpolationsbug ist nichts anderes, als eine Fehlkalkulation, die immer dafür sorgt, dass auf diesen 10ms nochmals 66ms hinzuaddieren. Keiner weiß wieso. Bedeutet im Klartext: Steht man still und kommt ein Gegner ums Eck gelaufen, so sieht dieser einem 76ms früher, als man ihn sieht. Umgekehrt würde man selber ihn fürher sehen, darum sollte man selten stillstehen mit dieser CS:S Engine. In der neuen Engine is dieser Bug gefixt! Warum man trotzdem trifft, auch wenn alles verzogen und verfälscht is: Es gibt die sog. "Lagcompensation" (cl_lagcompensation). Man schießt, der Server schaut "Wo hat der Spieler vor <PING>ms hingeschossen und stand ein Model dort?". Er spult quasi das Spielgeschehen ein Stück zurück pro Schuss und wertet dann aus, ob es ein Treffer war. 3. Gerüchte über CVARS - "cl_smooth" und "cl_smoothtime" sind KEINE Netsettings und beeinflussen euer Trefferverhalten GAR NICHT! "cl_smooth" gibt an, ob man bei einem Predictionfehler (Krasser Lag, wo rechts die Waffensymbole auftauchen und das Kaufgeräusch zu hören ist) zu einer Postion direkt ( = 0 ) oder ganz sanft ( = 1 ) gebracht werden soll. "cl_smoothtime" regelt in Sekunden, wielange diese geglättete Bewegung dauern soll. - "cl_lagcomp_errorcheck" ist seit mehreren Jahren deaktiviert und hat keinen Effekt mehr. - "cl_interp" könnt ihr nicht beeinflussen, das regelt "cl_interp_ratio" - "cl_interp_all" sagt aus, ob Entities (= Bewegte Elemente jeglicher Art) auch interpoliert werden, wenn sie nicht sichtbar sind ( = 1) oder nur, wenn sie sichtbar sind ( = 0). Auf 0 entlastet das die Interpolationsroutine. - "net_maxfilesize" ändert nichts am Spielgefühl! - "fps_max" beeinflusst das Recoil! - "cl_cmdrate +100" setzt den Scoreboardping zwar auf "1", aber der reelle Ping ändert sich nicht! - Lowrates sorgen NICHT für Durchschuss!!!!!!!! <--- - Zu viele FPS lässt euch länger geflasht sein! - Je höher auer "fps_max" Wert, desto schneller geht euer Fadenkreuz wieder zusammen! 4. Clientsettings Theoretisch wären die folgenden Settings PERFEKT (unter PERFEKTEN Vorraussetzungen): rate 30000+ cl_updaterate 100 cl_cmdrate 100 cl_interpolate 0 cl_lagcompensation 0 - Ping von 1-5ms - Konstant 100 FPS - Ein Server der IMMER JEDEM CLIENT 100 Snapshots pro Sekunde an Updates sendet (Tick 100 konstant) - Kein Paketloss Jeder weiß, dass diese Vorraussetzungen zumindest heutzutage nichtmal dauerhaft im LAN gehalten werden können. Aber so sehen sie aus. Grundsätzlich gilt bei der Findung der perfekten Settings der Grundsatz: KONSTANZ ist das A und O! Es bringt nichts, wenn man eine cmdrate von 100 hat und man hat nur manchmal 100 FPS. Jeder sollte eigentlich den cmdrate Wert auf die FPS setzen, die man unterm Durchschnitt hat, um ein bestmögliches Gefühl unter seinen Vorraussetzung zu erhalten. Ebenfalls bringt es meist nichts eine updaterate von 100 aufzufahren. Besonders bei miesen Server werden die 100/s nicht gehalten. Dann lieber auf Konstanz setzen. Dazu möchte ich aber auch noch etwas persönliches anmerken, was mein eigenes "Gefühl" ist: Ich finde, dass man maximal eine cl_updaterate von 60 bräuchte. Warum? 1. Man wirkt Datenstau entgegen (Weniger Choke -> Datenpakete kommen in richtiger Reihenfolge beim Client an -> Besser) 2. Der Interpbuffer erhöht sich nur um 0.007 (7 ms Modelverzögerung merkt kein Schwein). Da hab ich dann lieber konstante Daten in richtiger Reihenfolge, womit das "Reingeh"-Gefühl MASSIV gesteigert wird, als 100 Pakete pro Sekunde, die gerne mal Stau verursachen, sodass man oft beim DF Durchschuss hat oder es zu anderen abnormalitäten kommt (Übrigens ist damit auch die cmdrate angesprochen, bevor jetzt einer flamt "Updaterate und Dauerfeuer? HÄ?". 3. Wenn ein Mate vor euch rennt und ihr hinter ihm rennt und ihn oft "anrempelt", dann werdet ihr bei updaterate 100 unregelmäßig zurückgestoßen, bei updaterate 60 nicht. Ist mir zumindest aufgefallen. Für mich ein Indiz auf verfälschte Positionsberechnung durch schwankende Paketvergabe (Interpolation fehlerhaft dadurch?) Die "rate" Sollte so hoch wie möglich gehalten werden ohne dass man seine Bandbreite sprengt. Aber denkt bitte dran: "rate" Gibt nur die MAXIMAL verwendete Bandbreite an, die man CS:S zur Verfügung stellt. Sie wird selten bis zum Anschlag genutzt. 5. PC Settings Weniger Flashed sein: - dxlevel 80 + mat_monitorgamma >1.8 + Nicht zu hohe FPS Wenn man den Gammawert nicht aufs Maximum drängt, ist der Schliereneffekt nicht so intensiv und man sieht manchmal deutlicher. Die eigentliche Flashzeit wird aber nicht verkürzt. Zu hohe Gamma sorgt aber dafür, dass der Effekt intensiver ist, darum nicht unbedingt mit Monitorgamma 1.6 spielen, sondern mal höher probieren. Im übrigen ist das ganze auch Hardwareabhängig Besser durch Smokes gucken: - mat_picmip 1 + dxlevel 80-90 + Kontrast entweder hoch stellen oder niedrig lassen, je nach Monitor Je komplexer eine Smoke ist, desto mehr löcher hat sie. mat_picmip steuert, wie komplex die Smoke ist und mat_picmip 1 ist ein guter Mittelwert. Man könnte auch noch ein paar Settings in Powerstrip ändern, aber das werde ich euch nicht erläutern, sonst habt ihr 12PPs  Auch hier gilt, dass es Hardwareabhängig ist. Mausgefühl verbessern (Besonders bei nVIDIA): - Im Treibermenü die "Prerendered Frames" auf 0 oder 1 setzen + -noforce Befehle Die -noforce Befehle könnt ihr ergooglen. Für alle die glauben, dass es nichts bringt: Bei mir hat's geholfen, also wird's auch bei anderen helfen. Nur nicht bei allen, das hab ich auch festgestellt. Betriebsystem abhängig. TFT-Ruckelgefühl beseitigen: - fps_max auf eure Hz Zahl stellen oder auf ein Vielfaches davon Bsp.: 60 Hz = fps_max 60, 120, 180, 240... 75 Hz = fps_max 75, 150, 225, 300... Warum das so ist, könnte ich bei Bedarf nochmal erklären, aber ist relativ komplex. Sounds früher hören: - snd_mixahead (Std.: 0.1) runtersetzen. Bei OnBoard-Karten geht's meistens nur bis 0.05 (Ihr hört den Sound 50ms früher), bei guten Soundkarten wie der X-Fi geht es mittels snd_digital_surround 1 sogar bis auf 0.01 (90ms früher). (snd_digital_surround lässt sich nur ab 2 Boxen aufwärts einstellen und mit der X-Fi könnt ihr ja 5.1 mit CMSS-3D runtermixen (; ) X-Fi Soundsettings: - Treiber: Gamemode, Headset, Crystalizer AUS, CMSS-3D alles AN, EQ AN auf "Flat" stellen, Bassboost AKTIVIEREN (7db, 60Hz) Ingame: 5.1 Sound einstellen, snd_digital_surround 1. Empfohlen mit Steelseries 5hv2. Hört sich anfangs alles ungewohnt an, aber spielt mal 2-3 Wars und ihr gewöhnt euch dran und hört die Gegner viel krasser. (Wer sämtliche Gegnersteps auch auf weiter Distanz besser hören will, kann SVM aktivieren. Problem dabei ist nur, dass ihr dann nicht mehr so präzise Orten könnt, sondern nur leise Sounds lauter hört. SVM versucht laute Sounds den niedrigeren anzugleichen und umgekehrt, istn netter Effekt) Ekeligen "Hall"-Effekt im Sound beseitigen: - dsp_slow_cpu 1 + dsp_enhanced_stereo 0 Mehr reingehen: - Lest den Text oben, passt eure rates an und hört nicht immer auf das "100 100 25000 (bzw. 100000)" Geschwafel. TCP/UDP Settings bringen maximal was zu 5-10%, der Rest is Plazebo. Und was kaum einer rafft: Jeder hat mal Phasen, wo nichts geht. CS:S ist zu 80% Kopfsache, lasst den PC einfach mal fürn paar Tage aus und lenkt euch ab. Und wem es noch nicht aufgefallen ist: Wer im War Respekt vorm Gegner hat (Weil er EPS spielt oder so) trifft sowieso schonmal schlechter. Schießt ihn doch einfach um, jeder der spielt ist auch nurn Mensch (selbst Cheater machen Fehler). Bevor mir jetzt einer schreibt, dass alles haltlos wäre: Die meisten Infos sind Sachen, die ich für mich selber herausgefunden habe und die auch so bei mir funktionieren. Ich garantiere nicht dafür, dass jeder dieselben Effekte hinbekommt. Es bleibt jedem selber überlassen, was er probiert und was für Ergebnisse er hat. Viele Dinge die hier stehen beruhen auf Fakten, andere auf subjektives Empfinden. Sollte jeder für sich selber herausstellen. Ich hab das Zeugs hier so zusammengestellt, weil ich ein wenig Chancengleichheit denen gegenüber schaffen will, die solche Sachen benutzen, wenn andere sie nicht kennen. -- VALVe Mitarbeiter sind auch nur Menschen :P edited by moderator
[ quote ]
|
|
| xD [ quote ]
|
|
| Sticky!
-- Cu [ quote ]
|
|
| gj
-- x1 [ quote ]
|
|
| mario for president
-- kennste wayne, kennste alle [ quote ]
|
|
| nice mario
-- Der Dativ ist dem Genitiv sein Tod [ quote ]
|
|
| Yes we can do !
-- ... geh dem erst besten Mensch an die Kehle ... [ quote ]
|
|
| n1 [ quote ]
|
|
| Alles unnützer Schrott! (; <3 [ quote ]
|
|
| also ich kann so gut wie allem nur zustimmen, nur habe ich ein paar kleine fragen bzw anmerkeungen... 1. wie beeinflusst fps_max das recoil? das einzige was passiert, is das sich das crosshair schneller zusammenzieht bei mehr fps... von mehr weiß ich nicht => erklärung bitte  2. wieso ist man "länger" (es wird sich wohl nur um einige frames handeln nehme ich an) flashed durch mehr fps? => erklärung bitte 3. durch selbstversuche mit demos (stichwort: tick) konnte ich keinen zusammenhang zwischen dxlevel 80 <=> 81 und flashzeit feststellen => erklärung bitte 4. wieso vorrausberechnete frames reduzieren? könntest du das genauer erklären? 5. hm also EQ auf flat kann ich nicht ganz verstehen... schritte (eigtl die einzig wichtigen sounds ) sind ja auf den frequenzen ab 1khz... ich habe bei mir alles unter 1khz ziemlich runtergemixed und bis 16k treppenmäßig aufwärts, und ich finde meinen sound besser denn je... desweiteren spiele ich sogar noch mit crystalizer auf 65%, da ich finde es hört sich um einiges "klarer" an... im prinzip könnte ich mir schon vorstellen, dass die umrechnung auf 24bit sounds wohl eher "schlecht" sein müsste, aber ich höre besser denn je. cmss-3d brauche ich nicht, da ich ein 5.1 headset habe und snd_surround_speakers 5 spiele... 6. hier glaube ich hast du dich vertan, vllt sogar nur vertippt: der halleffekt kommt eben durch 2verschiedene werte bei dsp_slow_cpu und _enhance_stereo... wenn man beide auf gleiche werte stellt ist er weg... 7. hierzu gleich nochwas... wieso sollte man dsp_slow_cpu auf 1 stellen (was ja bedeutet dass soundberechnungen auf der cpu stattfindet) wenn man ne x-fi karte hat, was in deinem post ja rauskommt? Soll keinerlei flame oder sonstiges sein, im gegenteil... freue mich auf antworten und vllt mal ne wirkliche "diskussion", was bei dieser community zur echten rarität geworden ist. -- ... [ quote ]
|
|
| 1. Also bei mir wars bei fps_max so: feste Werte wie 100 und 101 brachten immer konstantes Recoil, aber es war irgendwie "härter", also man muss mit der Maus krasser ausgleichen und weiter runterziehn. Bei fps_max 0 z.B. hab ich geringeres Recoil, was man leichter kontrollieren konnte, aber es ist einfach "random" ( = Springt öfter von links nach rechts und das immer im Zufallsprinzip, was es bei mir bei 100/101 nich gemacht hat). Begründe ich damit, dass es wohl höhere FPS-Schwankungen gibt, wenn man keinen Limiter setzt (Logisch) und Schwankungen sich aufs Recoil übertragen 2. Anti-Flash Scripte waren damals mit fps_max <30. Man hat sich das zunutzen gemacht, wenn eine Flash ankam, ein Binding zu benutzen, was die FPS kurzzeitig <30 gesetzt hat und dadurch wurde der Flash Effekt verkürzt. Deswegen hat VALVe den Wert auf 30 festgelegt (und um den Ratechangern entgegenzuwirken). Umkehrschluss sollte damit klar sein, zumal ich mit fps_max 100/101 bzw. 111 weniger Probleme habe mit Flashes habe, als mit höheren Werten. 3. Steht doch da, dass keine Flashzeit verkürzt wird, oder ? 4. Weil die Frames im Buffer landen und danach erst ausgegeben werden. Du hast also immer ein gewisses Inputdelay, auch wenns minimal ist. Ein Buffer von 0 heißt: Kein delay. 5. Crystalizer macht Geräusche ein wenig ungenauer. Weil gewisse Frequenzen hervorgehoben werden, dabei kann es vorkommen, dass die Distanz ned so gut erkennbar is. Ist persönliche Präferenz, aber rein objektiv wäre es besser Crystalizer aus zu lassen. Und EQ "Flat" würde ich nehmen, um alle Frequenzen auf einem norm Level zu haben. 6. + 7. Nein, da habe ich mich ned vertippt. So wie es da steht, läufts bei mir. ich brauch nur dsp_slow_cpu 1, dann is der Nachhalleffekt weg. Und die Theorie, dass der CVAR beeinflusst, ob der Sound auf der Karte oder auf der CPU berechnet wird, ist falsch. dsp_slow_cpu Bedeutet, dass der Befehlssatz für den Hall-Effekt deaktiviert wird, um einer "slow CPU" ( = Low CPU / Rechner) entgegenzukommen. Dabei deaktivierst du einfach den Hall, spart Performance und du hast genaueren Sound. Ist zumindest bei mir so. -- VALVe Mitarbeiter sind auch nur Menschen :P [ quote ]
|
|
| 1. okidoki 2. okidoki 3. naja, du schreibst "dxlevel 80 + monitorgamma > 1.8" um weniger flashed zu sein^^ 4. okidoki, logisch soweit 5. jo hatte ich auch geschrieben, wäre rein logisch gedacht wohl besser, weil ja umgemixed wird... aber finds mit irgendwie trotzdem besser 6. hm... also das kann ich keineswegs bestätigen, ka warum... irgendwie habe ich allgemein eigtl keinen unterschied, ob ich 1 oder 0 mache... ich weiß das ist jetzt viel verlangt aber könntest du (wenn du kb hast np, vllt machts ja jemand anders ) mal ne .mp3 mixen mit und ohne den effekt, von irgend ner szene, wo mans "deutlich" hört?shorsh //edit: 7. hab ich vergessen... hm also die begründung kann ich net ganz nachvollziehen... wieso sollte man "wollen" dass bass-reiche nebengeräusche (brummen der generatoren auf nuke, tiefer schuss-sound der awp, uswusw) genauso laut sind wie die höheren frequenzen, auf denen unter anderem eben die wichtigen schritte liegen? -- ... [ quote ]
|
|
| zu 6.: dsp_slow_cpu 0 bewirkt, dass versucht wird so ein räumlicher sound effekt zu berechnen, der jenach umgebung anders ausfällt. bestimmt wird der hall effekt von der cvar "room_type", die sich automatisch entsprechen der umgebung ändert. setzt man nun dsp_slo_cpu auf 1, bleibt der room_type unverändert auf 0, egal bei welcher umgebung. damit bleibt eben dieser "hall"-effekt aus. hören kann man das in hellen räumen wie d1/d2 katas oder so. je nach umgebung aber auch in großen offenen plätzen. [ quote ]
|
|
| ich bemerke nirgends einen hörbaren unterschied, weiß auch nicht warum
-- ... [ quote ]
|
|
| ist ping nicht die zeit, die der server zum antworten braucht? also köln -> düsseldorf -> köln -- wer mir geld schenken will... pm und ich gebe die daten raus. [ quote ]
|
|
shorsh wrote: 1. okidoki 2. okidoki 3. naja, du schreibst "dxlevel 80 + monitorgamma > 1.8" um weniger flashed zu sein^^ 4. okidoki, logisch soweit 5. jo hatte ich auch geschrieben, wäre rein logisch gedacht wohl besser, weil ja umgemixed wird... aber finds mit irgendwie trotzdem besser 6. hm... also das kann ich keineswegs bestätigen, ka warum... irgendwie habe ich allgemein eigtl keinen unterschied, ob ich 1 oder 0 mache... ich weiß das ist jetzt viel verlangt aber könntest du (wenn du kb hast np, vllt machts ja jemand anders ) mal ne .mp3 mixen mit und ohne den effekt, von irgend ner szene, wo mans "deutlich" hört?shorsh //edit: 7. hab ich vergessen... hm also die begründung kann ich net ganz nachvollziehen... wieso sollte man "wollen" dass bass-reiche nebengeräusche (brummen der generatoren auf nuke, tiefer schuss-sound der awp, uswusw) genauso laut sind wie die höheren frequenzen, auf denen unter anderem eben die wichtigen schritte liegen? 3. Bestes Ergebnis bei mir. Würde 80 bevorzugen für die Leute, die nen LowRechner haben. Im Endeffekt isses wurscht ob 81 oder 80. Und naja, mir kommt es so vor, dass ich weniger flashed bin, weil die Intensität geringer is 6. Bei mir bei Playervideos da isn Video von de_nuke, wo ich mit AWP unzoomed schieße. Da ist dieser Hall zu hören. Da sind auch andere Videos ohne Hall. 7. Mit SVM wird das Brummen tiefer gesetzt, wenn ein Step kommt, damit du den step genausogut wahrnehmen kannst, wie das Brummen und das auf jeder Distanz. @ enemy: Genau so (: @ mmmmmax: Streng genommen wäre das "PingPong". Da man das heutzutage aber alles unter "Ping" zusammenfasst, hast du eigentlich recht. Aber ich wollte das relativ verständlich halten, deswegen. -- VALVe Mitarbeiter sind auch nur Menschen :P [ quote ]
|
|
| du spielst demzufolge mit svm?
-- ... [ quote ]
|
|
shorsh wrote: du spielst demzufolge mit svm?Nein. Ich habs probiert, ist zwar schön und gut, aber ich hab dann doch lieber die Präzision. -- VALVe Mitarbeiter sind auch nur Menschen :P [ quote ]
|
|
| wenn man die sounds so einstellst wie du sagst hören sich die leute im ts so grottig an, dass man es keine 2 min so lassen kann.
-- wer mir geld schenken will... pm und ich gebe die daten raus. [ quote ]
|
|
mmmmmax wrote: wenn man die sounds so einstellst wie du sagst hören sich die leute im ts so grottig an, dass man es keine 2 min so lassen kann.Mach mal "Mit Systemsteuerung synchronisieren" raus. -- VALVe Mitarbeiter sind auch nur Menschen :P [ quote ]
|
|
| #sticky plz =) [ quote ]
|
|
| Ich finde, dass man maximal eine cl_updaterate von 60 bräuchte. Ich habs mal ausprobiert...finde ich besser aber ist das nicht eigentlich egal? Da die rates sowieso auf 100 gefixt werden??? War da nichtmal was? Und ist dann die AK nicht unpräzise? Wie z.b. auf einem 60 Tick Server? mfg ingo -- voll das deutsch [ quote ]
|
|
ingo wrote: Ich finde, dass man maximal eine cl_updaterate von 60 bräuchte.Ich habs mal ausprobiert...finde ich besser aber ist das nicht eigentlich egal? Da die rates sowieso auf 100 gefixt werden??? War da nichtmal was? Und ist dann die AK nicht unpräzise? Wie z.b. auf einem 60 Tick Server? mfg ingo Also rates werden nicht auf 100 100 geforced. Stell dir mal vor, du wärst DSL Light oder ISDN User. Die hätten dann ein Problem :> Und Waffen werden dadurch nich unpräziser, sondern du wirst dich an ein anderes Spielgefühl gewöhnen müssen, aber dafür ist es kosntanter. Mir ist z.B. mal aufgefallen, dass man krassen Durchschuss bei Leuten hat, die gerade Bombe legen, wenn mann 100 100 Rates hat. Mit einer niedrigeren updaterate hatte ich das nich (Warum auch immer, aber da wars bei mir am Extremsten). -- VALVe Mitarbeiter sind auch nur Menschen :P [ quote ]
|
|
| kk, ich versuchs mal ne zeitlang mit 60 60 auch wenn ich jetzt schon weiß wie oft ich geflamed werde, wegen "lowrates"
-- voll das deutsch [ quote ]
|
|
| hm also ich kann jetz bisher wirklich allem zustimmen, endlich mal jemand mit ahnung und jemand der nicht nur auf dummes gequatsche zählt und jemand der auch argumente hat und mit dem man reden kann, nice mT... Nur eine Denkweise hab ich noch nich verstanden. du sagst du hast flat-EQ, weil du alles "normalisiert" haben willst... dann sag ich, dass das doch schlecht is weil basssounds unwichtig und hochfrequenzen wichtig... dann sagst du: "ne passt schon , svm regelt das" aber sagst gleich darauf, dass du ohne svm spielst. demzufolge spielst du mit der sinnlosigkeit von lauten tief-frequenten tönen, oder hab ich immernoch was verpeilt? also würde ich dir empfehlen, die frequenzen unter 1khz vllt leiser zu mixen... hoffe man kann es verstehenshorsh //EDIT: nochwas... du spielst doch aber trotzdem mit 100 100, wegen eps settings oder? -- ... [ quote ]
|
previous
1
-
25
next
