* Bien régler son jeu *

Un certain nombre de paramètres sont à prendre en compte pour jouer dans de bonnes conditions à Counter-Strike Source. Tout d'abord, il faut avoir une machine bien configurée, puis une connection internet bien réglée, et ensuite, une configuration qui vous convient.

Software configuration .

- Assurez vous de posséder les derniers drivers disponibles pour votre carte mère ainsi que votre carte graphique, et dans certains cas, pour votre processeur. Reportez vous directement sur le site de fabricant pour trouver les derniers drivers officiels. Pour les drivers moddés, c'est sur le site des drivers que ca se passe. Faites aussi une désinstallation / Réinstallation propre.
- Vous devez aussi posséder la dernière version de DirectX. A ce jour, il s'agit de la version DirectX 9.0 c Maj 08/2006. Disponible ici. DirectX 9.0c 08/2006 (52 Mo)
- Vérifiez que vos fichier CSS ne sont pas corrompus en lançant cette commande dans votre navigateur internet: steam://validate/240
- Pour une meilleur optimisation, steam propose aussi une défragmentation des fichiers du jeu. Pour la lancer, copier cette commande dans votre navigateur internet: s team://defrag/240
- En fonction de votre quantité de ram, vous pouvez autoriser le jeu à utiliser plus de mémoire vive que celle allouée par défaut (voir comment faire ci dessous). Il est en général recommandé d'allouer la moitié de votre ram au jeu. Mais ceci depend encore de la quantité que vous avez.

Pour les ordinateurs possédant 512 Mo de ram, la quantité par defaut utilisée etant déjà de 256 Mo, il est théoriquement inutile d'y toucher, mais parfois, on peut constater de meilleures performances lorsque celui ci est réglé sur 512 Mo ( à ce moment la, c'est windows qui gère seul ce qu'il doit prendre pour tourner correctement avec le jeu de lancé).
Pour les ordinateurs possédant 1024 Mo de ram, il est donc conseillé de mettre 512 Mo pour HL2.exe
Le processus ne dépasse que très rarement ce seuil, voir jamais, vous pouvez tout de meme allouer 1024 Mo pour le processus, mais les différences ne se feront théoriquement pas ressentir. Au dessus de 1024 Mo de ram, vous pouvez laisser sur 512 ou 1024, au choix.
Pour paramétrer la quantité de ram à utiliser, vous devez entrer dans les propriétés de lancement du jeu (clic droit sur le jeu, puis propriété). Dans l'onglet "Général", cliquer sur "définir les options de lancement". Une ligne apparaît alors pour entrer les commandes. Celle du screenshot permet de lancer la console au lancement, et de régler le heapsize sur 1024 Mo.

 Réduction à 54% de la taille originale [ 936 x 552 ]

La commande -heapsize permet donc de définir cette quantité de ram. -heapsize 1048576 permet d'allouer 1048576 octets, ce qui correspond à 1024 Mo. Pour trouver la valeur, il suffit simplement de multiplier la quantité souhaitée par 1024 (1024*1024 => 1048576). Pour allour 512 Mo, 512*1024 = 524288. La commande pour allouer 512 Mo sera donc -heapsize 524288.

- Les options graphiques vous permettent d'augmenter vos FPS pour jouer avec une meilleur fluidité. Si votre machine ne suit pas, il est recommandé de baisser la qualité graphique pour augmenter votre fluidité. /!\ Il ne faut pas se limiter à 24 FPS comme une TV pour avoir une sensation de fluidité. Pour plus d'information techniques (ou biologique ) à ce sujet vous pouvez aller lire l'article Framerate & FPS, vous comprendrez pourquoi il faut beaucoup plus de FPS qu'au cinéma pour être à l'aise. De plus vous devez tenir compte des baisses de FPS lors de multiples combats. Par exemple, si vous avez 24 fps en vous baladant dans la map, il est sur et certain que vous tomberez bien bas lorsque vous verrez à l'écran 2-3 joueurs en train de se tirer dessus, le tout mélangé avec quelques explosions de grenades, que vous tomberez sous la barre des 10 FPS, et la, c'est quasiment injouable. Pour ne pas ressentir de baisse de FPS et avoir une bonne impression de fluidité, il est conseillé d'en avoir environ 60 minimum en temps normal (c'est à dire en se baladant sur la map).
/!\ Pour des conditions optimales, le 100 FPS est recommandé. Il n'est pas question ici de savoir si l'oeuil distinguera la différence entre 100 FPS ou 60 FPS, mais il est question de netcode (décrit plus bas dans les configurations internet). En effet, il faut savoir qu'un des défaut majeur du moteur est d'être limité en cmdrate par les FPS. On verra plus loin l'utilité du cmdrate, et pourquoi il est préférable de l'avoir a 100. Ce qui implique de pouvoir se rapprocher le plus possible des 100 FPS pour des condition OPTIMALES de jeux. Bien évidemment, un FPS a 66 avec un cmdrate de 66 n'est pas énormément pénalisant.

- Plusieurs commandes sont disponibles en plus des options graphiques. Vous pouvez les écrire dans un fichier nommé autoexec.cfg (pour le créer, voir la partie "configuration / commandes" ) Voici une listedes principales mais il en existe beaucoup d'autres influant plus ou moins sur la qualité / les fps. (a updater)

Les commandes principales influant sur la qualité graphique sont:

CITATION

cl_phys_props_enable 0 // Désactive les petit objets qui ne dérangent pas les déplacement. (petite boites, briques ...)
cl_ragdoll_physics_enable 0 // (Efface les corp des perso mort. Pas de corp par terre)
cl_ragdoll_collide 0 // (Pas de gestion de collision entre les corps)
cl_show_splashes 0 //(pas d'effet d'éclabousures quand on tire dans l'eau)
fog_enable 0 //(désactive le brouillard)
fog_enable_water_fog 0 //(désactive le brouillard au dessus de l'eau)
mat_antialias 0 //(désactive l'anti aliasing)
mat_bumpmap 0 //(désactive le bumpmapping)
mp_decals 8 //(n'affiche que 8 tag perso des joueurs)
r_decals 10 //(affiche que 10 decals du jeu en même temps. 1 decal = 1 impact de balle, une tache de sang ...)
mat_fastspecular 0 //(désactive le fast spécular lighting. La plupart des reflet devienne inactifs. Ex: sniper scope)
mat_specular 0 //désactive le specular lighting
r_dynamic 0 // désactive les lumière dynamique
mat_forceaniso 0 //(désactive le filtrage aniso)
mat_forcemanagedtextureintohardware 1 //(je sais pas trop, mais il parait que ca aide un peu les vielles config )
mat_hdr_enabled 0 //(Désative la gestion du HDR)
mat_picmip 2 //(Texture peu détaillées)
mat_trilinear 0 //(désactive le filtrage trilinéaire)
r_rootlod 2 //(Qualité des models généraux pas très élevés)
r_rainradius 0 //(désactive la pluie)
r_shadows 0 //(désactive les ombres. Peu reommandé car elles sont utiles sur source)
r_waterforceexpensive 0 //(Une Optimisation de l'affichage de l'eau, mais je sais pas trop quoi)
r_3dsky 0 //(Désactive les texture 2D autour de la map. Ex les buildings qui font croire a un centre-ville)
rope_smooth 0 //(désactive l'anti aliasing des cables)
rope_wind_dist 0 //(désactive l'effet de vent qui fait bouger les cables)
r_worldlights 1 //(Une seule source de lumière)
r_modellodscale 0.6 //(abaisse la qualité des personnages avec la distance plus vous êtes loins, plus la qualité du perso baisse).

Si vous êtes patients, la Version 2 du CSS HUD TWEAKER (voir la section customize) devrait intégrer la possibilité de modifier ça beaucoup plus simplement et de manière plus complète.

- Vous pouvez aussi forcer votre carte graphique à utiliser un DirectX inférieur à celui qu'elle peut gérer. Par exemple, si votre carte a du mal a gérer le directX 9, telle une 9600 par exemple. Vous pouvez la forcer à utiliser un directX 8.1 ou 8.0, voir même un directX 7 au détriment de la qualité graphique biensur. Pour cela, il suffit d'ajouter un ligne dans l'autoexec, comme les commandes si dessus.

Pour forcer en directX 9 => mat_dxlevel 90 (95 pour les dernières nvidia en directX 9.0c)
Pour forcer en directX 8.1 => mat_dxlevel 81
Pour forcer en directX 8.0 => mat_dxlevel 80
Pour forcer en directX 7 => mat_dxlevel 70
Pensez aussi à réduire la résolution de jeu si votre machine est difficulté.

- La commande fps_max 101 permet d'avoir une bonne fluidité sans ressentir de ralentissements. En passant d'une scène peu chargée a une scène très chargées, vous sentez une légère baisse de FPS en passant de 250 a 90 par exemple. Ce qui peut être genant. Par contre si vous passez de 100 a 90, le ralentissement est beaucoup moins perceptible.
De plus, si l'on ne tien pas comptes des variations de FPS, Il est inutile de monter plus haut que la fréquence de rafraîchissement de votre écran, vous ne verrez pas plus d'images par seconde que ce que peux vous afficher votre ecran, par contre, si la fréquence de rafraîchissement de votre écran est inférieure à 100 Htz, vous devez tout de même laisser une valeur minimum de 100 pour ne pas que vos FPS brident votre cmdrate comme il est précisé plus haut. Par exemple si vous avez un ecran lcd a 60 Htz. Il faut désactiver la synchro verticale et avoir un fps_max > 100 pour ne pas limiter le cl_cmdrate a 60.


- La console permet d'effectuer plusieurs réglages sur le jeu qui ne sont pas accessibles par les options. Vous pouvez l'obtenir au lancement du jeu en ajoutant -console dans les options de lancement, comme sur le screen de la partie décrivant le heapsize. Par contre vous risquez de la perdre en pleine partie si vous la fermez, et ce, sans pouvoir la récupérer. Pour ca, on va pouvoir rentrer ces lignes dans l'autoexec.cfg

CITATION

con_enable 1
bind "'" "toggleconsole"

Ca va vous permettre d'avoir la console en plein jeu en appuyant sur la touche ² et de pouvoir la réouvrir même après l'avoir fermée.

Network configuration.

- Un bon serveur est un serveur configuré en tickrate 100. C'est à dire qu'il prend 100 phases de jeu par secondes, et ceci a une influence énorme sur la qualité de jeu. Un serveur qui a un tickrate 33 est un serveur qui « ne touche pas » comme ont dit car le nombre d'informations par secondes est trop bas. Ca influe sur les impacts de balles et les déplacement des joueurs. Pour mieux comprendre ce phénomène, vous pouvez lire l'excellent article sur le netcode source traduit en français: Le moteur Source : une analyse du Netcode

Il n'est pas nécessaire d'avoir des connaissances avancées pour comprendre cet article.

- Coté client

- Ce qui nous intéresse ici, c'est d'être synchro avec le serveur pour avoir un maximum de tick (shéma du jeu) par secondes, et donc une meilleur qualité de jeu. La majeur partie des serveurs étant en tickrate 100, et la majorité des joueurs possédant une connection haut débit, on peut partir des meilleurs valeurs. Ces valeurs peuvent être entrée dans l'autoexec.cfg (voir la partie configuration pour créer le fichier).

On va donc simplement entrer ces valeurs.

cl_cmdrate 100 (on envoie vos actions, ou tick [déplacement, tirs...]) 100 fois par secondes, au serveur)

cl_updaterate 100 (on reçoit les actions du jeu, ou tick, 100 fois par seconde, par le serveur, si ce dernier est en tickrate 100)

cl_interpolate 1 Permet d'avoir une image fluide des joueurs. Avec l'interpolate a 0, si un joueur envoie 20 paquets par seconde au serveur (cause: fps faibles, ou cmdrate mal réglé) alors vous verrez ce joueur saccader (on dit aussi se téléporter) car vous n'aurez que 20 images par secondes de ce joueur.
Avec l'interpolate à 1, le client va combler le manque de position du joueur par des images (tick) insérée entre chaque déplacement du joueur avec une trajectoire calculée en fonction des 2 dernière positions reçue, pour ainsi le rendre plus fluide. Inconvénient: les images générée par l'interpolation ne sont pas touchable. Comme si c'etait un model virtuel etant donné que c'est géré uniquement chez le client.

cl_interp_ratio 1 Temps / cl_updaterate sur lequel est généré l'interpolation. C'est aussi le temps de retard qu'aura l'affichage par rapport au jeu. Voir description plus bas. (Lag Compensation)
si votre cl_updaterate est a 100 et que votre ratio est a 1 vous aurez un temps d'interpolation de 0.01, ce qui correspond a l'ancienne variable cl_interp 0.01.


rate 1048576 ou moins . C'est le taux de transfert maximum (serveur => client uniquement). Il s'agit en fait de la limite fixée par le source Engine. Si votre connection n'accepte pas ce débit, il est préférable d'en informer le serveur et de baisser votre rate. Un rate 1048576 correspond donc a une connection de 1 Mo/sec plus couremment exprimée par 8 Mbits/sec. Si vous avez une connection 512 K de bonne qualité (soit environ 64 Ko/sec de récéption max, vous pouvez baisser votre rate a 65536.
Pour une classique connection 1 MBits (128 Ko/sec) vous pouvez le mettre a 131072. Pour les détenteur de très mauvaises connexions ADSL, (ligne 512 très longues et de très faible qualité, ligne 256K etc...) Vous pouvez vérifier l'etat de vote downlad maximum et régler le rate en conséquence.
Il faut savoir que le serveurs possèdent leur propres restrictions sv_maxrate et sv_minrate qui définissent les maximum et minimum qui peuvent être appliquée par le clients. Beaucoup de serveur sont encore en sv_maxrate 30000 ou sv_maxrate 25000. Il est clair que dans ce cas, avoir un rate a 1048576 ne servira a rien puisque le serveurne vous everra pas plus de 30 ou 25 Ko/sec. C'est un débit qui suffit dans la plupart des cas, mais en phase intense, ce débit peut instantanément être largement dépassé. C'est pourquoi il est préférable de débrider totalement cette limite haute via la commande sv_maxrate 0. De cette manière, le débit maximim entre serveur et client sera d' 1 Mo/sec. Le serveur possède aussi une restriction minimum du rate. Si le serveur est par exemple réglé sur sv_minrate 5000 (proche du défaut mais plutot mauvais), cela veux dire qu'un client pourra régler son rate sur 5000, ce qui revient a lui envoyer pas plus de 5 Ko/sec. Ca revient a jouer en 56K et ca devient vite pénible. Pour cela, vous pouvez augmenter la valeur sv_minrate de votre serveur a environ 20000 ou 30000 ce qui evitera au client de simuler une connexion trop lente (pas en dessous de 20 Ko/sec).
Ca peux paraitre faible face aux connexions actuelles, mais beaucoup de personnes sont encore loins des dslams avec des lignes de très basse qualité, et leur débit en est souvent amoindri. De plus, 20 Ko/sec c'est largement suffisant en situation de jeu "normale".

cl_predict 1 . Permet d'avoir un jeu plus réactif chez le client. En fait, le jeu n'a pas besoins d'attendre une confirmation du serveur pour effectuer certaines action comme les animation de tir ou les déplacement.
Sans prédiction coté client, il faut que le client envoie l'info de son action au serveur, ensuite le serveur confirme l'action au client, et la, le client effectue son action. Avec la prédiction, le client envoie ses actions au serveur et c'est tout. Il arrive (rarement) que le client fasse quelques erreur de prédicion, notemment en ce qui concerne les déplacement. Si le client s'est trop déplacé par rapport au jeu réel (controlé par le serveur), le serveur va corriger la trajectoire chez le client. C'est en général tellement léger et peu fréquent qu'on ne s'en apercoit pas. (voir le cl_smooth)

cl_smooth 1 Cette valeur autorise le serveur à adoucir la correction de vos erreurs de predictions. Par exemple lorsque vos déplacement ont été trop important (tout est relatif encore, ca reste très faible en général) du coté client, le serveur va vous replacer très doucement à votre bonne position.

Si cette valeur est a 0, le client vous replacera brutalement et la vous vous apercevrez du changement. La prédiction n'est valable que pour vos déplacement et vos tirs.

cl_smoothtime 0.01/ 0.02 . C'est le temps maximum autorisé pour"smoother". C'est a dire pour vous replacer en douceur par rapport au serveur. Si l'erreur de prédiction est trop importante pour être corrigée en douceur dans le temps imparti, alors vous êtes replacé brutalement a votre position.
Cet variable doit être assez faible car si votre PC vous replace a votre position en 0.1 sec, vous aurez un décalage entre l'endroit d'ou vous voyez le joueur et l'endroit ou vous êtes réellement pour le serveur. Et les 2 différentes trajectoires de balles etant colinéaire avec un point de départ différent, n'auront pas le même point d'arrivée (impact). Mais cette valeur ne doit pas être trop faible car dans ce cas, le moteur n'a pas le temps de vous smoother et vous êtes brutalement replacé.



- Coté serveur

On vas déjà voir comment se débrouille le serveur pour gérer les latence générée par les différentes connexions. Ca s'appelle la compensation de Lag.

Lag compensation

Voila une petite explication du fonctionnement du mécanisme de compensation de lags. Dans l'exemple, Nous somme sur un serveur tickrate 100, avec un ping de 50 ms et des valeur network correctes (cmdrate 100, updaterate 100, et rate 25000, donné le plus souvent sous la forme 100/100/25000).
Pour comprendre le fonctionnement on va suivre le trajet d'une information reçue, ainsi que celui d'une information envoyée suite a une réaction du joueur, et voir comment le serveur analyse le tout (en simplifiant au maximum).
Ceci et théorique. Le lag compensation comporte de petit bug, il suffit de se rendre sur le forum steam pour le constater

 Réduction à 63% de la taille originale [ 805 x 398 ]

Dans cet exemple, le serveur envoie la position d'un joueur (ennemi ) à 15,03 sec. Le ping étant (temps mis pour faire aller retour) de 50 ms, le trajet d'un aller simple durera 25 ms. L'information arrive donc 25 ms plus tard chez le client, soit a 15,055 sec.

C'est la qu'entre aussi en jeu le cl_interp. Pour pouvoir créer des positions supplémentaires sur la position des joueurs dont vous ne recevez que peu d'informations, votre pc vous fait joueur dans le "passé". Pas 15 ans en arrière non plus, juste la valeur cl_interp de retard. Ca permet de laisser 0.01 ou 0.02 secondes d'avances au pc, soit 1 ou 2 tick, pour pouvoir calculer les points de trajectoire intermédiaires et ainsi inventer des positions pour rendre les joueurs plus fluides.

Donc entre le temps ou le serveur vous envoie une info et le temps ou vous la voyez à votre écran, il s'est ecoulé 0,045 sec. (rien de grave théoriquement puisque le serveur va compenser tout ca).
Suite a ses 0.045 sec, il faut ajouter le temps de réaction du joueur (client) avant qu'il tire. On va dire qu'il met 0.05 sec pour l'exemple ce qui nous amène a 15,125 sec. La, pas de décalage entre le pc et l'affichage, l'information est directement envoyée a 15,125 sec.
Par contre, on retrouve un nouveau décalage de 25 ms dû au ping (50 ms) entre le moment ou le client recoit l'information et le moment ou le serveur la reçoit.

A u final, le temps qu'il s'écoule entre le moment ou le serveur envoie la position d'un joueur et le moment ou il reçoit l'information de tire du joueur et assez conséquent, même si l'on enlève le temps de réaction du joueur. Et ca parait énorme avec un ping de 80 ms et un cl_interp par défaut (0.1). Ca nous donnerais un décalage de 180 ms sans le temps de réaction.

C'est pour ca que le serveur va compenser tout ce lag (sv_unlag 1). Le serveur connait vos paramètres (ping + cl_interp) Il va donc facilement pouvoir calculer le temps qu'il a fallu au informations pour circuler à travers le réseau. Ainsi, a la réception de l'info de votre tir, le serveur va retourner voir ses "archives".
A 15,15 sec (réception de votre commande tir), il va retourner voir comment était le jeu au moment ou il vous a envoyé les info de positions. (temps réel - temps de latence - temps d'interpolation)
Ainsi, rien est décalé. Mais ca c'est théorique car l'interpolation introduit un retard d'affichage de 100 ms apparemment et ceci quel que soit le cl_interp chez le client. Ce qui a amené un lourd débat sur la valeur cl_interpolate a adopter.

Note: La valeur cl_interp est maintenant remplacé par cl_interp_ratio / cl_updaterate, mais ca ne change rien. Ca reste un temps d'interpolation

Voila maintenant les variables serveur principales concernant le network.

sv_maxrate 0, sv_minrate 30000 . Il faut savoir que le serveurs possèdent leur propres restrictions sv_maxrate et sv_minrate qui définissent les maximum et minimum qui peuvent être appliquée par le clients. Beaucoup de serveur sont encore en sv_maxrate 30000 ou sv_maxrate 25000. Il est clair que dans ce cas, avoir un rate client à 1048576 ne servira a rien puisque le serveur ne vous enverra pas plus de 30 ou 25 Ko/sec. C'est un débit qui suffit dans la plupart des cas, mais en phase intense, ce débit peut instantanément être largement dépassé. C'est pourquoi il est préférable de débrider totalement cette limite haute via la commande sv_maxrate 0. De cette manière, le débit maximim entre serveur et client sera d' 1 Mo/sec. Le serveur possède aussi une restriction minimum du rate. Si le serveur est par exemple réglé sur sv_minrate 5000 (proche du défaut mais plutot mauvais), cela veux dire qu'un client pourra régler son rate sur 5000, ce qui revient a lui envoyer pas plus de 5 Ko/sec. Ca revient a jouer en 56K et ca devient vite pénible. Pour cela, vous pouvez augmenter la valeur sv_minrate de votre serveur a environ 20000 ou 30000 ce qui evitera au client de simuler une connexion trop lente (pas en dessous de 20 Ko/sec).
Ca peux paraitre faible face aux connexions actuelles, mais beaucoup de personnes sont encore loins des dslams avec des lignes de très basse qualité, et leur débit en est souvent amoindri. De plus, 20 Ko/sec c'est largement suffisant en situation de jeu "normale". Vous pouvez aussi vous dire que beaucoup de personnes sont encore en 56K, mais il y a un moment ou il faut trancher entre les 2 pour avoir le meilleur compromis "contenter tout le monde / avoir de bons rates"

sv_minupdaterate 66, sv_maxupdaterate 101 Encore une fois, ce sont des limites hautes et basse pour le client concernant sa valeur cl_updaterate. Voir la partie "coté client pour plus de détails"

sv_mincmdrate 66, sv_maxcmdrate 100 Il s'agit la aussi de limite hautes et basse, mais celle ci concernent la variable cl_cmdrate. cette fameuse variable qui a mené a tant de pleintes sur le serveur. En effet, un joueur avec un cmdrate très bas, enverra ses information de jeu au serveur a intervalles assez espacées. Le problème, c'est l'interpolation, qui affiche des positions de ce joueur qui n'existent pas. cf la partie "cl_interpolate 1" pour plus d'explication. En bref, il s'agit ici d'eviter les personnes qui règlent ce cmdrate trop bas pour être difficilement touchable par les autres. 66 semble être une bonne valeur minimum. Les intervalles sont assez proches (66 position /sec) et les connection supportent pratiquement toutes ces delais. Le seul réel problème qu'il reste, ce sont les joueurs ayant des FPS plus bas que cette limite qui ne peuvent envoyer plus de paquet que ce que leur framerate leur permet. Rappel: le cmdrate réel ne peux pas dépasser le framerate. Un joueur ayent 30 FPS ne pourra pas envoyer plus de 30 paquets par secondes au serveur, même si le sv_mincmdrate est a 66. Mais dans ce cas, le joueur est plutot pénalisé par son framerate bas. La limite haute (100) est simplement la limite du serveur. Il est donc inutile de mettre un cl_cmdrate a 200 par exemple. Le serveur ne traîtera pas plus de paquet par secondes que son tickrate le permet.


sv_client_cmdrate_difference 20 . Ici, il s'agit de forcer le client a utiliser des valeur cl_cmdrate et cl_updaterate proches. Le serveur se base sur l'updaterate réglé par le client pour réajuster le cmdrate si nécéssaire. Par exemple, si un joueur demande 100 paquet / sec (cl_updaterate 100) et n'en renvoi que 66 (cl_cmdrate 100). Cette variable va remonter la variable cl_cmdrate client a 80 (100-20).
Bien evidemment, si l'ecart entre l'updaterate et le cmdrate est inférieur a 20, la commande ne rectifie rien.

sv_client_interpolate 1 . Cette variable force le client a utiliser l'interpolation. Si un serveur est en sv_unlag 1 et qu'un client règle son interpolation sur 0, il peux avoir un avantagesur les hitbox. Il lui suffit simplement de sniper derrière le model. Pratique pour sniper les CT aux début du round sur dust2 par exemple . Pour eviter ca, on force tout le monde a 1 (en LAN, on force tout le monde a 0)

sv_client_predict -1 . Le -1 permet de laisser libre choix au client sur sa variable. (voir cl_predict dans la partie client)

sv_client_min_interp_ratio 1; sv_client_max_interp_ratio 2 . La variable cl_interp n'etant plus a jour, on s'interesse maintenant la la variable cl_interp ratio, qui règle de délais d'iterpolation en fonction de l'updaterate. Ainsi, un client avec un cl_updaterate 100 et un ratio de 1, aura un delais d'interpolation de 1/ 100 = 0.01, avec un ratio de 2, 2/100 = 0.02. Avec un c_updaterate 66 et ratio de 2 => 2/66 = 0.03. L'interpolation client agit en fonction des paquets recu par le serveur. Plus l'updaterate est haut, plus le délais d'interpolation peut être faible.

- Avec ces valeurs, les conditions de jeu sont très bonnes. Il faut maintenant voir si votre connection tien le choke

Pour ça, il faut afficher le net graph. Il suffit de taper net_graph 3 dans la console, vous verrez alors un ligne indiquant loss et choke (voir détail du netgraph plus bas. Votre choke doit etre de 0 en condition normal de jeu. Il peut monter jusqu'à 4-5 en phase de combat et un peu plus à chaque début de round, mais au dela, c'est que votre connection ne peut pas suivre avec les valeur rentrée. Il suffit donc de baisser progressivement et simultanément le cmdrate et l'updaterate, vous pouvez passer a 85, puis 75 puis 66. En général on ne descend pas en dessous de 66. S'il y a encore du choke a cette valeur, vous pouvez essayer de descendre votre rate a 30000 puis 20000 voir 15000 si votre débit est très faible.

Si vous avez du loss, alors soit vous avez du choke important, soit votre connection est mauvaise. Y'a pas vraiment de réglage pour ça.

- Au niveau du ping, il ne faut pas se fier au tableau des scores qui affiche un ping de 5 voir moins en cas de cmdrate très bas. Le ping réel d'un joueur se situe dans le netgraph seulement, et il ne faut pas etre obsédé par cette valeur parce que votre adversaire a 20 ms de moins que vous. Les serveurs sont équipés de systèmes de compensation qui font très bien leur travail. Privilégiez surtout de hautes valeurs de rates, même si votre ping doit monter de 10 ms pour ça.


- Comprendre le netgraph:

Savoir lire le netgraph n'est pas difficile, et permet simplement de bien configurer sa connection.
Le Net_graph 3 permet d'avoir pas mal d'info.

 Réduction à 93% de la taille originale [ 547 x 99 ]

En première ligne on retrouve les FPS actuel ainsi que le ping réel.
La deuxième ligne concerne les paquets reçus par le serveur. Le premier chiffre indique la taille du dernier paquet reçu. La deuxième indique la bande passante utilisée et le troisième étant le plus intéressant, le nombre de paquets reçu du serveur. Il s'agit de l'updaterate réel. Ce chiffre permet aussi de voir si le serveur tien un tickrate élevé puisqu'il s'agit en fait du nombre de tick par secondes qu'envoie le serveur. Ca permet de voir la qualité d'un serveur.
La troisième ligne concerne les paquets envoyés, avec comme au dessus, la taille du dernier paquet envoyé, la bande passante utilisée, et le plus intéressant aussi, le cmdrate réel. C'est le nombre de paquets que vous envoyez au serveur par seconde. C'est aussi cette valeur qui ne dépassera jamais le nombre de FPS instantané.

Vous devriez maintenant pouvoir régler votre connection pour avoir la meilleur qualité de jeu.

Configuration / Commandes.

Ici, il s'agit d'apprendre à paramétrer ses commandes le mieux possible.

- Il est quasiment indispensable pour entrer des commandes personnelles ou d'optimisation, de créer un fichier autoexec.cfg qui se chargera directement lors du lancement du jeu. Il faut savoir aussi que si une commande apparaît déjà dans le config.cfg, c'est la valeur de celle de l'autoexec qui prendra le dessus car ce fichier est chargé après le fichier config.cfg.

Pour créer un fichier autoexec, vous ouvre un simple éditeur de texte comme notepad, et vous l'enregistrez en « autoexec.cfg » dans le dossier cfg qui se trouve par défaut dans:
C:\Program Files\Steam\steamapps\"votre_compte"\counter-strike source\cstrike\cfg\

Un petit aperçu pour montrer la simplicité du fichier

- Dans ce fichier, vous pouvez entrer toutes les commandes qui correspondent à ce que vous voulez. Les commandes d'optimisations graphiques et network données plus haut peuvent y etre insérées.

Voici d'autre commandes qui peuvent être utiles.

CITATION

cl_crosshairscale 2200 (Permet de rétrécir le viseur au centre de l'ecran. Plus la valeur est grande, plus le crosshair sera petit, le maximum doit etre de 6000 environ. Vous obtenez alors un tout petit crosshair)
cl_crosshairusealpha 1 (permet d'avoir un crosshair non translucide => meilleur visibilité)
cl_crosshairalpha 255 (permet d'augmenter la visibilité du crosshair)
cl_crosshaircolor 1 (permet de changer la couleur du crosshair. 0=vert 1=rouge ... => 4)
cl_dynamiccrosshair 0 (permet de ne pas avoir d'agrandissement du crosshair lorsque vous courez / sautez)
cl_radaralpha 255 (permet d'augmenter la visibilité du radar)
sensitivity xx (permet de sauvegarder votre sensibilité souris)
cl_downloadfilter nosounds (permet de ne pas télécharger les sons à l'entrée d'un serveur)
cl_forcepreload 1 (permet de précharger la map et les models. Moins de lag ingame)

bind x "incrementvar cl_crosshaircolor 0 4 1". (Ce bind permet d'incrémenter une variable. Dans l'exemple du crosshaircolor, la varible prendre pour première valeur 0 et pour dernière valeur 4. A chaque pression sur la touche X, la valeur augmentera de 1).
bind x "incrementvar cl_crosshaircscale 1000 6000 500" (A chaque pression de la touche, le crosshair prendra une valeur de 1000 puis 1500 puis 2000, jusqu'à 6000. Ensuite l'incrémentation reviendra a 1000).
Vous pouvez incrémenter toutes les variables que vous voulez de cette manière.

bind "x" +graph (Cette commande vous affichera votre netgraph uniquement lorsque vous restez appuyé sur x)

cl_restrict_server_commands 0 (Permet de rentrer sur les serveurs possédent des plug in [mani, matties,cvarblock,zblock...]. C'est a dire presque tous)

Pour les binds d'achats, je vous conseille le Css Script Générator de m00t,


Jusqu'à la sortie du CSS HUD Tweaker V2 (cf ci dessous).

Radar/Overview

Le Radar de CS Source est l'un des éléments les plus utiles du jeu.
Il est un peu plus chargé qu'avant, et il est nécessaire de le connaître dans ses moindres détails.
Voici a quoi correspondent les principaux éléments.

Notes:
Les ennemis ne se déplacent pas. Les points qui les représentent restent fixe quelque soit leur mouvement. Ils sont allumés uniquement lorsque vous, ou l'un de vos allié en a repéré un. Le point reste affiché quelques secondes puis disparaît.
Attention aux couleurs. Le bleu ne représentes plus vos alliés, mais l'équipe anti-terroriste. Si vous êtes dans l'équipe terroriste, vous et vos alliés serez représentés par des points rouges sur le radar.
Pour les maps CS_ Les icônes des otages prennent les même formes, mais sont de couleur jaune.
Lorsque vous êtes flashé, le radar disparaît quelques secondes de votre écran, jusqu'à ce que votre vue redevienne normale.
Vous pouvez activer la rotation de la carte ou non dans les options du jeu, ou en entrant la commande cl_radar_locked 0/1. Afficher l'alpha du radar en réglant cl_radaralpha entre 0 et 255 (0 = radar non visible)

Lorsque vous êtes en vue spectateur, ou mort, le radar s'agrandit par défaut.
Voici quelques commandes utile pour suivre le déroulement du jeu (spectateur uniquement).

CITATION

overview_preferred_mode 0/1/2 => 0=Off; 1=Mini map (defaut); 2=overview en fullscreen.
overview_health 1 => Permet d'afficher le niveau de vie des joueurs sur le radar.
overview_names 1 => Permet d'afficher le nom des joueur sur le radar.
overview_tracks 1 => Trace un trait derrière le joueur, représentant son parcours.
overview_locked 1 => Permet de ne pas rentrer dans les murs de la map en vue 3° personne.
overview_alpha 0 =>1 => Règle la transparence de la map entre 0 et 1. exemple: overview_zoom 0.7
overview_zoom => Règle le zoom du radar 1=> Map entière; 4 => zoom important. Vous pouvez jongler entre ces valeur avec des décimales. exemple: overview_zoom 2.33

Customize

Le HUD de cs source a la possibilité d'être modifié en changeant plusieurs variables dans certains fichiers du jeu.

Tout se passe en ligne de configuration difficilement configurables si l'on ne connait pas bien toutes les fonctions. Heureusement, chez INpact Team, on pense à vous . Le CSS HUD TWEAKER V 1.19 , vous permet de modifier tout votre HUD à souhait, le tout via une interface graphique très intuitive (thx m00t ) Vous pouvez sélectionner, déplacer; modifier chaque élément de la fenêtre d'un simple clic. Voici un exemple de HUD customisé (cliquez sur le HUD pour l'agrandir et sur le tweaker pour accéder a la page officielle de présentation ):



Vous pouvez aussi modifier l'apparence de vos armes et personnages en changeant les skins et parfois les models. Le site le plus complet (pour l'instant) à ce sujet est fpsbanana. (skins, models, tag ...)

/!\ Les scripts et packs complets sont totalement déconseillés . Ils vous installent souvent beaucoup de fichiers inutiles et modifient l'apparence de votre jeu (skin, model, qualité graphique) sans que vous puissiez en avoir un apercu au préalable. Certain scripts douteux ont déjà été détéctés pour contenir des cheats camouflés (c'est a dire que le joueur ne voit rien à l'écran, il joue sans cheat, mais certains fichier sensibles du jeu sont modifiés. => BAN permanent VAC²).

Une Bonne Communauté

La dernière chose pour jouer dans des condition agréables est de jouer sur de bons serveurs, avec des gens sympas.
Donc si vous avez un serveur, vous pouvez dans un premier temps charger la banlist ACP source pour eviter pas mal de cheater sur votre serveur.

Ensuite, pour avoir un serveur pas trop mal niveau tickrate, évitez d'installer trop de plugins & scripts dessus.