Excellent, très bien présenter et mérite d’être épinglé ainsi que partagé.

J'ai une petite question, de mon coté, cl_interp à 0 ce n'est point possible. Le jeu force automatiquement la valeur à 0.015625.

Si tu mets cl_interp 0, il va calculer l'interpolation avec cl_interp_ratio / cl_updaterate soit 2 / 128 (j'imagine) = 0.015625. L'interp n'est jamais à 0 dans le jeu. C'est juste nous qui dans la config lui indiquons comment la calculer en mettant cl_interp à 0.

Pour rappel : période d'interpolation = max (cl_interp, cl_interp_ratio / cl_updaterate)

Ok j'avais pas vraiment compris le 0 dans ce sens là. Autant l'aspect calcul ratio pas de prob. En tous cas bien joué. T'as dû chopper de belles migraines au passage :D

Vu que je bosse dans la simulation informatique où les problématiques temps réelle sont souvent présentes et que je joue de temps en temps à CS, ça m'intéressait de comprendre les choix que Valve a fait. Le FPS est parfait pour ça : c'est un type de jeu où on essaye de créer artificiellement un temps réel en donnant l'impression au joueur que tout est immédiat. En réalité, c'est tout sauf du temps réel, on compense les pertes de temps dû au réseau par des mécanismes logiciels. C'est toujours un compromis entre exactitude du rendu et performance.
Mais ce que je voyais sur le net ici et là m'effrayait un peu, les gens préféraientt mettre n'importe quoi dans leur config en recopiant celle d'un "pro" plutôt que de laisser les valeurs par défaut. Changer ces valeurs sans savoir ce qu'elles font peut s'avérer moins efficace que de laisser par défaut. Valve le dit très bien :
"Don't change console settings unless you are 100% sure what you are doing
Most "high-performance" setting cause exactly the opposite effect, if the server or network can't handle the load. "
Le meilleur exemple est celui du cl_predict à mettre à 1 sur le net et 0 en lan. Or la plupart des config récupérées sur le net le positionnent à 0 car elles sont optimisées pour le offline.

Après pas de mystère, une fois que votre config est bien faite, le reste, c'est de l'entraînement !

Salut,

Vous trouverez dans le lien pastebin toutes les explications techniques concernant les commandes rate cl_updaterate cl_cmdrate cl_interp cl_interp_ratio cl_lagcompensation cl_predict sur les fps le tickrate serveur la configuration en lan et sur la GOTV souvent décriée.

Toutes les infos proviennent de la documentation du Valve source engine, moteur utilisé dans cs go notamment. Le lien de la doc est dans le pastebin également.
Cela permet d'avoir une explication une fois pour toute par rapport à tout ce qu'on voit sur le net comme conneries.

En français :

http://pastebin.com/52spr03U

En anglais :

http://pastebin.com/2bBFijFY

Je ne connais pas beaucoup de forums spécialisés pour counter strike. J'ai bien essayé de créer un nouveau thread sur le subreddit /r/GlobalOffensive mais comme je viens de créer le compte reddit, je ne suis pas autorisé à créer un nouveau thread (à vrai dire je comprends pas grand chose à reddit...)

Bref, si vous voulez/pouvez, hésitez pas à propager le lien. Je me fous pas mal d'être nommé ou quoique ce soit. C'est fait pour servir, servez-vous en librement.

Moultes tendresses.

Merci de partager cette article qui est vraiment très intéressant, dans l’ensemble je suis d'accord avec tout ce qui est dit dans l'article à une exception prêt.

"Cl_interp_ratio": Comme je l'ai dit avant, pour rendre l'interpolation (interp = interpolation si vous ne comprenez pas) très simple à utiliser, l'interpolation est calculé comme ceci "période d'interpolation = max (cl_interp, cl_interp_ratio / cl_updaterate)". Cette équation signifie «interpolation en seconde est égale à la valeur maximale entre la commande cl_interp et la division de la commande cl_interp_ratio par la commande cl_updaterate". Nous avons placé "cl_interp"à 0 juste avant (si vous ne comprenez pas, vous n'avez pas lu les explications de "cl_interp" bad boy), de sorte "cl_interp" ne sera jamais le maximum. La commande "Cl_updaterate" doit correspondre avec le tickrate du serveur (si vous ne comprenez pas, vous n'avez pas lu explications de "cl_updaterate" bad boy). Donc, il y a cette "cl_interp_ratio". C'est très simple. Vous voulez revenir dans le temps de 2 mises à jour ? OK, cl_interp_ratio est égale à 2. Point final. Au lieu de calculer le temps en seconde pour remonter dans le temps de 2 mises à jour à partir du tickrate serveur, il vous suffit d'indiquer le nombre de mises à jour que vous voulez garder. Maintenant, je vous vois arriver: "Donc, je dois avoir le moins d'interpolation possible pour avoir la dernière représentation du monde et les hitboxes !!" NON, NON et NON. Pourquoi? A cause du "lagcompensation" (voir ci-dessous). Donc, une bonne valeur pour "cl_interp_ratio" est 2. Avec cela, vous gardez la fluidité dans votre jeu, la protection en cas de perte de données sur le réseau et ce ne sera jamais un désavantage par rapport aux autres joueurs.

Cette partie de l'article me chagrine un peux, alors je vient à la pêche au information, et je pose deux questions.

Nous somme bien d'accord que le "Lerp" qui était autre fois visible sur le netgraph découle directement de la configuration de deux commande CL_INTERP et CL_INTERP-RATIO hors de puis les débuts de Counter Strick il est conseiller d'avoir la commande cl_interp_ratio à 1 alors pour quoi la conseille tu as 2 ??

Ma deuxièmes question est plus une information technique qu'une vrais questions.
J'ai moi aussi fait pas mal de recherche sur le netcode de CS et j'ai lut à plusieurs reprise que le LERP "cette valeur qui à temps fait parler d'elle sur CS du fait de sa couleur orange / jaune qui a susciter énormément de théorie " définissez en faite le taux de rafraîchissement du positionnement de la hitbox.

un exemple :

Quand un joueur ce déplace d'un point A à un Point B le LERP définie toute les combien de MS le positionnement de la HTBOX est rafraîchie donc sur un serveur tick 64 le LERP devrais par conséquent être de 15.6 ms pour un 102.4 / 9.6 MS pour un 128 / 7.2 MS plus le lerp est cour plus le rafraîchissement est rapide et le positionnement précis c'est une explication qui pour moi est tout à fait plausible et depuis des années sur tout les CS en compétition le netcode Obligatoire est le suivant:

cl_inter "0"
cl_inper_ration "1"

Donc j'aimerais avoir ton avis ??

Très intéressant mais je tiens à préciser deux choses de mon expérience :

1) j'ai toujours observé que que le tickrate reste le max pour un client sur cl_cmdrate et cl_updaterate. Donc j'ai TOUJOURS observé qu'avec une config à 128/128, sur un serveur tickrate 64, ces deux valeurs sont mises à 64. L"inverse par contre sur CSGO est très souvent faux. Aucun serveur ne force une config client 64/64 à passer à 128/128.

Par conséquent mettre cl_updaterate 128 et cl_cmdrate 128 n'est jamais un problème car ces commandes passent à 64/64 sur un serveur tickrate 64

2) avoir un net_graph qui affiche aucun loss, aucun choque, ne signifie ABSOLUMENT pas que la connexion est stable. Juste que la config est bonne pour le jeu. J'ai changé 2 fois de FAI en 3 mois car je ne touchais plus rien sur le jeu (du fait que les serveurs sont à l'étranger). Et je peux garantir que je n'ai jamais eu de chocke/loss chez aucun des 3 FAI et que je touche beaucoup mieux chez mon nouveau fournisseur d'accès. La stabilité de connexion et surtout les accords de peering sont super importants dès que l'on joue à l'étranger. Ca peut tout changer.

Sinon, RAS, j'ai de meilleurs résultats aussi avec cl_interp_ratio 2 contrairement à ce que tout le monde dit sur les forums.