Forums CScargo

Bonjour,ce n'est pas de moi mais ça explique bien certaines commandes utilisée par certains (dont moi).
Ça servira sûrement a rien mais ça vaut le temps perdu pour le lire.

bonne lecture.
     

Pour les développeurs de jeux ou des personnes techniques: amusez-vous avec le lien ci-dessous.

[url]https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking[/url]

Le moteur de jeu Valve source engine est utilisé par les jeux :

        Counter Strike: Global Offensive

        Half-Life 2: Deathmatch

        Counter Strike: Source

        Day of Defeat: Source

        Team Fortress 2

        Left for Dead

        Left for Dead 2

Pour les personnes non techniques, voir ci-dessous, je vais expliquer comment cela fonctionne (c'est un résumé du lien ci-dessus avec des explications et des conseils):

- Le serveur simule le monde virtuel un certain nombre de fois par seconde, ce sont les ticks/seconde. Ainsi, un tickrate 128 signifie que le serveur simule le monde toutes les 7,8 millisecondes (128 fois par seconde), un tickrate 64 signifie toutes les 15 millisecondes. Simuler le monde signifie calculer les positions, les événements ...

- Les SEULES COMMANDES RESEAUX UTILES pour le client sont "rate", "cl_updaterate", "cl_cmdrate", "cl_interp", "cl_interp_ratio", "cl_predict", "cl_interpolate" et "cl_lagcompensation" :

=> "rate" : Si le serveur essaie d'envoyer plus de données que ne peut supporter votre connexion, c'est mauvais car des données seront perdues (packet loss). En théorie, la valeur de rate devrait correspondre à la vitesse maximum de téléchargement de votre connexion. Par exemple, avec une connexion avec une vitesse de téléchargement maximale égale à 1 Mo / seconde, vous devriez avoir 1 Mo = 1 * 1024 Ko = 1 * 1024 * 1024 octets = 1048576 octets / seconde (oui, 1 Mo = 1024 Ko et 1 Ko = 1024 octets, mais ce n'est pas ce dont on parle). Avec cela, vous devez écrire dans votre config rate "1048576". MAIS, dans le monde réel de l'univers réel (avec la guerre, la famine et justin bieber), il n'y a pas de jeux qui envoient 1 Mo / seconde à chaque client. Donc 400000 est assez, même 128000.

Exemples:

rate 128000 signifie 0,12 Mo / seconde

rate 400000 signifie 0,4 Mo / seconde

=> "cl_updaterate" : La valeur, 128 par exemple, signifie «hey serveur, je suis un client, envoie-moi 128 fois / seconde une mise à jour du monde". Deux limites: le serveur ne vous enverra jamais plus de mise à jour du monde que le tickrate du serveur (il ne peut pas vous envoyer 128 mises à jour / seconde si il simule 64 fois le monde / seconde ... ) et il ne peut pas envoyer plus de données que la valeur "rate" de votre config (sinon perte de données !!!). La meilleure valeur est la même que le tickrate du serveur, rien d'autre (les serveurs de Valve ont un tickrate de 64, et la plupart des serveurs dédiés sont à 128, il faut donc changer la valeur dans la console avant de se connecter au serveur)

=> "Cl_cmdrate" : La valeur, 128 par exemple, signifie «hey serveur, je vous enverrai 128 fois / seconde une mise à jour de mes input (souris, clavier, ect ...)". Aucune limite pour cette valeur. MAIS, inutile d'envoyer plus de mise à jour que le tickrate serveur (vous pouvez envoyer 128 mises à jour / seconde si vous voulez, mais si le serveur simule le monde 64 fois / seconde, vous avez 128-64 mises à jour inutiles ... Je vous laisse calculer). La meilleure valeur est la même que le tickrate du serveur, rien d'autre (les serveurs de Valve ont un tickrate de 64, et la plupart des serveurs dédiés sont à 128, il faut donc changer la valeur dans la console avant de se connecter au serveur)

=> "Cl_interpolate" : Mettre à 1, cela signifie activer l'interpolation (explication de l'interpolation ci-dessous avec "cl_interp" et "cl_interp_ratio"), le fameux "lerp" affiché dans vos net_graph depuis la nuit des temps (pour les vieux qui ont joué à cs 1.3 [url]https://www.youtube.com/watch?v=xQquwE-SdfE[/url] nostalgie quand tu nous tiens). Mettre à 0, signifie sans interpolation, de sorte que les deux commandes ci-dessous n'ont pas d'effet. La valeur à définir ici est 1, rien d'autre. Vous n'avez AUCUNE RAISON VALABLE de désactiver l'interpolation.

=> "cl_interp" : Plus compliqué. Il y a plusieurs mécanismes utilisés par le moteur de jeu pour avoir une bonne sensation de jeu (de fluidité ...). Comme la documentation le dit : "Si les objets (entités) sont affichés à chaque mise à jour reçue par le serveur, les objets en mouvement et l'animation seraient saccadés et des données perdues sur le réseau poseraient également des gros problèmes. L'astuce pour résoudre ce problème est de remonter dans le temps pour le rendu graphique.". Donc, par défaut, le client (votre jeu sur votre PC) ne montre pas la dernière mise à jour du monde reçue par le serveur, pas l'avant-dernier, mais l'avant-avant-dernier. Le problème avec cette commande c'est que c'est compliqué à calculer pour chaque serveur. En effet, une valeur égale à 0,1 signifie que votre jeu vous affiche les données reçues 100 millisecondes avant les dernières données reçues (l'unité de cl_interp est la seconde, 0,1 seconde est égale à 100 millisecondes). Cette valeur ne fonctionne qu'avec un cl_updaterate égale à 20. En effet, avec updaterate égale à 20, vous recevez une mise à jour toutes les 50 millisecondes (1 seconde = 1000 millisecondes -> 1000/20 = 50 millisecondes), donc avec un "cl_interp" à 0,1 , votre client remonte dans le temps de 100 millisecondes, ce qui correspond à 2 mises à jour (50 millisecondes + 50 millisecondes = 100 millisecondes ...). Vous devez adapter le cl_updaterate au tickrate du serveur et adapter le cl_interp au cl_updaterate ..., même pour Valve c'est chiant. Donc, ils ont introduit la commande "cl_interp_ratio" pour rendre ça très simple. La seule valeur valable pour la commande "cl_interp" est 0, rien d'autre.

=> "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 un peu plus loin 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.   

=>"cl_extrapolate" : L'extrapolation s'active lorsque l'interpolation ne suffit plus à compenser les données perdues sur le réseau (mises à jour du monde envoyées par le serveur). En effet, si plusieurs mises à jour consécutives se perdent, l'interpolation va vous permettre de puiser dans votre réserve. Avec cl_interp_ratio à 2 et cl_interp à 0, vous avez donc 2 mises à jour en réserve. C'est-à-dire que votre jeu affiche l'avant-avant-dernière mise à jour en gardant toujours deux mises à jour devant lui. Si plus d'un paquet consécutif se perd, alors la réserve ne suffit plus. Dans ce cas, avec cl_extrapolate positionné à 1, votre jeu sur votre PC va faire une simple extrapolation linéaire de la position des entités basée sur leur historique. Ce mécanisme permet encore de retarder le freeze sur votre écran en cas de pertes consécutives de données. Cependant, étant donné que plus votre client (votre jeu sur votre PC) extrapole les positions de vos ennemis et coéquipiers, plus elles seront fausses par rapport à la réalité, l'extrapolation est limitée dans la durée par la commande "cl_extrapolate_amount" (ci-dessous). Par défaut, cl_extrapolate est à 1. Je déconseille fortement de la désactiver (plus d'explications vers la fin du document dans "Autre chose numéro 8").

=>"cl_extrapolate_amount" : Indique le temps pendant lequel le client (votre jeu sur votre PC) peut extrapoler. Par défaut c'est à 0,25 seconde. C'est-à-dire qu'au-delà de 250 millisecondes, le client arrête d'extrapoler et votre jeu va freeze. En effet, après 250 millisecondes les erreurs de positions de vos ennemis et coéquipiers pourraient être trop importantes par rapport à la réalité du serveur.

=> "cl_lagcompensation" : Entre la représentation du monde que vous avez sur votre écran et la situation du monde sur lequel le serveur fonctionne, il y a une énorme différence. Mais, pas de panique, le serveur connait l'interpolation de chaque joueur et le ping de chaque joueur. Ainsi, le serveur tient compte des différences de configuration de chaque joueur. En effet, entre le moment où vous shootez un gars sur votre écran et le moment où l'information arrivera au serveur, la position de l'ennemi continuera de changer (s'il courait en avant par exemple). Pour détecter le hit, le serveur calcul donc ceci : moment d'exécution du tir = Heure actuelle du serveur - ping - interpolation. Ce qu'il faut comprendre c'est qu'il y a une différence entre le moment où le serveur reçoit l'information (temps réel) du tire de votre part et le moment où le tir s'est produit dans le jeu (temps simulé). Le serveur calcul le temps simulé à partir du temps réel en tenant compte du ping et de l'interpolation spécifique au joueur. Donc, la bonne valeur pour cette commande est 1 (cela signifie lagcompensation activé, par défaut c'est à 1).

=> "cl_predict" (input prediction) : C'est un autre mécanisme utilisé par le moteur de jeu pour avoir une bonne sensation de jeu (de fluidité ...). Pour faire simple, "l'input prediction" permet à votre jeu de ne pas attendre les données du serveur pour faire bouger votre perso après avoir appuyé sur avancer (par exemple). Si l'input prediction n'est pas activée et que vous avez un ping de 100, cela implique qu'entre le moment où vous appuyez sur la touche avancer et le moment où votre jeu fera avancer votre perso, il se passera au moins 100 ms (le temps pour les données de faire l'aller-retour). Avec l'input prediction, votre client estime (extrapole) par lui-même votre future position et la corrige si nécessaire lorsqu'il reçoit les prochaines données du serveur. Cela améliore les sensations de jeu (fluidité, précision du tir...). Il faut donc positionner cette commande à 1 pour activer l'extrapolation.

Pour conclure :

Je vous vois arriver : "Alors, je dois désactiver l'interpolation, l'extrapolation, l'input prediction et le lagcompensation pour toujours avoir la dernière représentation du jeu !!!". Non, non et non. Vous devez avoir toutes ces options activées.

Tous ces mécanismes activés vous permettent d'avoir une bonne expérience de jeu (fluidite...), vous préservent des pertes de données sur le réseau (packet loss) qui peuvent vous empêcher de toucher correctement, et ne vous désavantagent pas du tout par rapport aux autres joueurs puisque le ping et l'interpolation sont pris en compte dans les calculs du serveur.

Autre chose : tickrate 128 ou 64? Peu importe, parce que tous les joueurs jouent sur le même serveur. Ils n'auront jamais plus de mises à jour que vous, même si ils ont mis leur "cl_updaterate" à 128 sur un serveur avec un tickrate 64. Le cl_updaterate et cl_cmdrate doivent être adaptés au tickrate serveur pour ne pas être désavantagés, c'est tout. La seule différence est pour le serveur et pour votre bande passante. Le serveur va devoir calculer 128 mises à jour par seconde, d'où une augmentation des calculs pour ses processeurs, chaleur et tout ce qui va avec (il faut avoir l'infrastructure, c'est sans doute pour ça que Valve a passé ses serveurs MM de 128 à 64). Pour votre bande passante, si le tickrate et le cl_updaterate sont à 128, le serveur vous enverra deux fois plus de données par seconde qu'à 64. Il faut donc la connexion capable d'absorber ce flux de données (enfin bon, si vous n'avez pas une connexion capable d'absorber 0,12 Mo / seconde (rate 128000 suffisant), c'est que vous êtes au fin fond du périgord avec un modem 56K de club-internet (les jeunes vous comprendrez pas), et dans ce cas pensez plutôt à sortir dehors pour profiter des magnifiques paysages et de la nature plutôt que de glander comme un couillon sur votre PC).

Autre chose numéro 2 : pour les fps, d'après une doc que j'ai trouvé [url]https://developer.valvesoftware.com/wiki/Interpolation[/url], ils disent qu'une mise à jour serveur à besoin de trois frames pour être complètement affichée. Ce qui signifie que, dans l'idéal, les fps doivent être 3 fois plus élevé que le tickrate et l'updaterate. D'ailleurs, quand vous installez le jeu cs go pour la première fois, le cl_updaterate est à 20 et les fps_max à 60 (x3). Par contre, rien ne sert de mettre un fps_max qui ne sera pas supporté par votre écran. Cela va faire travailler votre carte graphique pour rien (et donc chauffer pour rien et donc abimée sur le long terme pour rien, sauf si vous la refroidissez correctement). Donc si vous avez une carte graphique très puissante, limiter la valeur de fps_max au taux de rafraichissement de votre écran. Si votre carte graphique n'est pas ultra performante, attention de ne pas la faire travailler excessivement, il est possible qu'elle galère à atteindre le taux de rafraichissement de votre écran (selon le matériel que vous avez). A l'inverse, si vous avez un écran 100Hz par exemple, avec une carte graphique dernier cri, vous n'aurez JAMAIS plus de 100 fps par seconde affichées. Le nombre de fps sur le net_graph sera supérieur à 100 parce que votre carte graphique en calcul plus que 100 (avec un fps_max à 0 par exemple, ce qui signifie fps au maximum)... pour rien.

C'est pour ça que je dis que les fps doivent "dans l'idéal" être 3x plus élevé que le tickrate et l'updaterate. Dans les faits, trouvez moi un écran qui affiche du 128 x 3 Hz (il y en a, mais très cher et pour quelle durée de vie...) ? Et même pour une carte graphique puissante, calculer 128 x 3 frames par seconde, c'est beaucoup.

Autre chose numéro 3 : Pour les lan, la seule différence est la qualité de la connexion qui est bien supérieure à celle sur internet. Pour autant, l'interpolation ne doit pas être désactivée car au-delà de la protection en cas de perte de données sur le réseau (ce qui est beaucoup moins fréquent en lan), elle sert aussi à améliorer la fluidité du jeu (en ayant toujours 2 mises à jour en réserve). Vous pouvez par contre désactiver l'input prediction (cl_predict à 0). Si vous regardez la plupart des config de pro, ce sont des config pour des conditions de connexion "parfaites" (en lan justement) et leur cl_predict est à 0 car le ping est négligeable. Pour le reste, ça ne change rien. Il faut adapter l'updaterate et le cmdrate au serveur. Le rate à 128000.

Autre chose numéro 4 : Un joueur mal configuré ne sera pas plus difficile à toucher. Çà dépend de votre config, pas de la sienne. Même si le joueur met un cmdrate inférieur (c'est-à-dire qu'il envoie moins de fois par seconde ses actions souris/clavier au serveur), c'est lui qui sera désavantagé, pas vous. Le serveur simule X fois/sec (tickrate) le monde. Il  vous enverra donc les dernières positions connues du joueur en tenant compte de sa configuration à lui. Le seul désavantagé dans l'histoire, c'est lui.

Pour la simple et bonne raison que plus son paramétrage est mauvais par rapport à sa connexion, plus les corrections effectuées par le serveur sur ses actions seront nombreuses et donc sa représentation du monde sur son écran faussée. Il aura souvent l'impression d'avoir le viseur sur vous mais de pas vous toucher pour autant.

Aussi, si il fait le contraire de ce qu'il faut faire parce qu'il est têtu : désactiver interpolation, input prediction et lag compensation en pensant avoir la dernière représentation du monde possible, ce sera encore pire pour lui mais pas pour vous. Vous aurez toujours sa dernière position connue du serveur, mais de son côté, son jeu passera son temps à corriger sa position et ses actions. Il aura cette impression de ne jamais toucher.

Comme le dit la documentation de Valve :

"Don't turn off view interpolation and/or lag compensation

It will not improve movement or shooting precision. "

Autre chose numéro 5 : Il faut vraiment relativiser les problèmes des serveurs "qui sont jamais en France donc on est toujours désavantagé". Prenez un peu de recul.

Même si vous jouez contre un joueur qui habite dans le même pays hôte du serveur de jeu, les différences sont vraiment minimes.

Un mec qui a un ping de 20 ms aura effectivement un avantage puisqu'avec cl_predict à 1, sa position va être certes extrapolée par son jeu, mais très rapidement corrigée avec la prochaine mise à jour reçue. Si vous en face vous avez un ping de 70 ms, il y a au mieux 50 ms de différence dans la correction de votre position. MAIS, l'extrapolation faite par votre jeu sur votre PC n'est :

- de un, pas toujours très différente de la réalité, on parle ici d'une toute petite extrapolation, puisque vous recevrez votre vraie position dans 70 ms. Le jeu n'a pas besoin de vous faire avancer de 100 mètres (mètres virtuels hein), ça doit se jouer au millimètres et encore (virtuels hein). Donc par rapport à la largeur du modèle 3D utilisé pour représenter l'ennemi en face de vous, c'est quedal. Même en extrapolant, il y a de fortes chances pour que votre viseur soit quand même réellement sur lui.

- de deux, l'extrapolation n'est faite que pour fluidifier votre jeu. Ce qui compte vraiment, ce sont les calculs du serveur, seuls eux font offices de vérité et communiqués à l'ensemble des joueurs du serveur. Or, pour rappel, dans les calculs du serveur pour savoir à quel moment vos différentes actions se passent (mouvements, tir...), le serveur utilise le calcul suivant "moment d'exécution de l'action = Heure actuelle du serveur - ping - interpolation". Donc même avec un ping plus faible, il n'est pas avantagé de ce côté-là.

Ce que je veux dire c'est que l'avantage d'avoir un ping de 20 ms au lieu de 70 ms est vraiment minime de chez minime, imperceptible pour l'être humain. On parle ici de millisecondes à l'echelle de l'électronique et des réseaux. D'ailleurs je parie que jusque là vous ne vous êtes jamais rendu compte que le jeu corrige votre position !!! Tout est fait dans le jeu, et dans tous les jeux en réseaux d'ailleurs, pour minimiser l'impact du réseau sur la qualité du jeu.

Autre chose numéro 6 : BEAUCOUP PLUS TECHNIQUE MAIS CA VAUT LE COUP DE COMPRENDRE CA. Il y a plusieurs manières d'échanger des données via internet. Les plus utilisées aujourd'hui sont ce qu'on appelle UDP et TCP. Pour faire très simple et aller droit au but qui nous intéresse, l'UDP ne s'assure pas que les paquets transmis par les serveurs et les clients arrivent à bon port alors que le TCP s'en assure (on peut faire le parallèle avec un recommandé à la poste. TCP c'est du recommandé avec accusé de réception, UDP c'est une bonne vielle lettre de votre grand-mère qui vous l'envoie de l'autre bout du monde pour vous montrer comment elle profite de sa retraite alors que vous travaillez comme un chien). Tous les jeux réseaux utilisent UDP. Pour la simple et bonne raison que TCP impacte trop les performances réseaux. Donc si une mise à jour envoyée par le serveur se perd sur le réseau, elle est perdue, point final. Avec TCP, votre client informerait le serveur pour lui dire "hey mon coco, ta mise à jour je l'ai pas réçue là, alors renvoie-là moi une deuxième fois et plus vite que ça". Vous comprenez alors que gérer des connexions TCP pour un FPS serait un énorme bordel. Il faudrait tenir compte des éventuels redondances d'informations pour calculer les actions des joueurs. Donc c'est de l'UDP. Mais du coup, vous comprenez l'importance de l'interpolation et de l'extrapolation ! Si une donnée se perd en route, elle est définitivement perdue mais avec une bonne interpolation, vous en avez en réserve jusqu'à recevoir une prochaine mise à jour du serveur. Sans l'interpolation et l'extrapolation, perte de donnée dans le réseau = freeze dans votre jeu. Tout simplement.

Autre chose numéro 7 : Pour le mode spectateur souvent décrié (GOTV), la documentation dit que lorsque vous observez un joueur en première personne, vous ne voyez pas vraiment ce qu'il voit car le spectateur n'a pas le lag compensation. Donc c'est normal si parfois vous ne comprenez pas comment le gars a pu shooter un autre où si vous voyez des trucs bizarres.

Autre chose numéro 8 : Vous pourriez avoir envie de désactiver l'extrapolation en vous disant que vous préférez que votre jeu freeze plutôt qu'il extrapole les positions de vos ennemis/alliés au risque de se tromper. Mais dites-vous bien que si votre jeu extrapole, c'est parce que des données sont sans arrêt perdues sur le réseau. Dans ce cas, commencez par augmenter votre cl_interp_ratio à 3 ou 4 et pensez à vérifier que votre configuration correspond à votre connexion. Lisez le "P.S. numéro 2" ci-dessous pour ça. Dites-vous bien que l'extrapolation est utile pour fluidifier votre jeu et que si erreur de position il y a elles seront rapidement corrigées (on parle en millisecondes là les gars. Vous arrivez à vous représentez ce que fait 15 millisecondes (pour un tickrate serveur à 64, ce qui veut dire que vous corrigerez les positions avec la mise à jour du monde qui arrive toutes les 15 millisecondes) ? C'est invisible pour l'être humain. Je vous l'accorde, ça peut parfais être trompeur si les positions sont trop extrapolées (d'où la limite de cl_extrapolate_amount) mais comme je vous l'ai dit, si trop d'extrapolation, revoyez votre configuration (vous ne saurez au courant qu'il y extrapolation que lorsque votre client aura extrapolé jusqu'à la limite autorisée par cl_extrapolate_amount car dans ce cas votre jeu va freeze. Si votre jeu ne freeze pas, vous n'avez aucun moyen de savoir si l'extrapolation est souvent utilisée. Enfin si avec le net_graph 2 mais là ça devient un outil de debug pour développeur et ce n'est pas le sujet).

P.S. (après 8 autres choses...) :

Selon les serveurs, certaines des valeurs susnommées (héhé, bien placé celui-là) sont forcées. Les plus courantes sont le rate limité à 128000 et le cmdrate forcé au tickrate. Mais selon les serveurs ça peut ne pas être le cas. ça ne coûte rien de les mettre dans votre config. Après vous êtes grand, vous faites bien ce que vous voulez.

P.S. numéro 2 :

Parce que ma bonté n'a pas de limite et que j'aime mon prochain, pour vérifier votre config, servez-vous de net_graph 1. Le chiffre en bas à gauche "tick" vous indique le tickrate du serveur sur lequel vous vous trouvez. Les deux chiffres en haut à droite vous indiquent votre updaterate ("up") actuel et votre cmdrate actuel ("cmd"). Il faut que ces trois-là correspondent, sinon déconnectez-vous, modifier les dans la console puis reconnectez-vous. Vérifiez que vous avez 0 en choke et loss, sinon :

      -> vérifier que votre rate est compatible avec la bande passante restante de votre connexion (il y a peut-être du monde de connecter sur votre connexion, vous n'avez peut-être pas 100% de sa bande passante pour vous, votre maman/soeur/femme regarde peut-être une superbe vidéo de Ryan Gosling sur Youtube en qualité 4K)

      -> diminuer progressivement l'updaterate (vous aurez donc moins de mises à jour du serveur ce qui désengorgera votre connexion, il vaut mieux 0 en choke loss qu'un updaterate ingérable pour votre connexion)

      -> augmenter le cl_interp_ratio à 3 voire 4. Ce qui permet de garder 3 ou 4 mises à jour en réserve et donc de diminuer l'impact du choke/loss (même si le chiffre du choke loss en lui-même ne diminuera peut-être pas, avec 3 ou 4 maj dans votre besace, vous pouvez vous permettre de perdre 1 ou 2 paquets consécutifs sans vous désavantager).

Si vous avez des chutes de fps dans les smokes ou autres, pensez à réduire le niveau de détail du jeu dans les options du jeu et de votre carte graphique et à désactiver la synchro verticale dans les paramètres de votre carte graphique.

P.S. numéro 3 :

Au final, je trouve qu'un tickrate 64 sur les serveurs de Valve est un très bon choix. Cela permet d'atteindre un bon compromis pour que le plus grand nombre est une configuration optimale (bande passante nécessaire pas trop importante donc moins de problème de choke loss pour les petites connexions, 64 x 3 fps atteignable facilement, des écrans 64 x 3 Hz existant aujourd'hui, ressources économisées pour leurs serveurs puisque moins de calculs par seconde). Mieux vaut avoir une configuration optimale avec 64 en tickrate server qu'une configuration inatteignable en 128 tickrate. Très peu d'écran grand public sont capables d'afficher du 128 x 3 hz. Et peu de carte graphique (à part les haut de gamme) sont capables de calculer 128 x 3 frames par seconde même avec une résolution d'écran pas trop élevée.

P.S numéro 4 :

Pour aider le plus grand monde, voilà une config type. Même si je suis contre ça, les config qui vont soi-disant bien à tout le monde, j'ai eu pas mal de retour où les gens apprécient les explications mais ne savent plus vraiment quelles valeurs mettre au final.

rate 128000 (baisser si vous avez des soucis de choke/loss)

cl_updaterate 128 (sur un serveur tickrate 64 vous serez automatiquement limité à 64, diminuez si avez du choke/loss)

cl_cmdrate 128 (sur un serveur tickrate 64 vous serez automatiquement limité à 64)

cl_interpolate 1

cl_interp 0

cl_interp_ratio 2 (augmentez à 3 ou 4 si vous avez du choke/loss)

cl_extrapolate 1

cl_extrapolate_amount 0.25

cl_lagcompensation 1

cl_predict 1 (mettre à 0 en LAN)

fps_max <mettre ici le taux de rafraichissement de votre écran>

LE cl_interp et le cl_interp_ratio SONT A REGLER EN FONCTION DE VOTRE LIGNE ADSL

< 30 ms - cl_interp" = "0.015625";cl_interp_ratio 1
30-59 ms - cl_interp" = "0.015625";cl_interp_ratio 2
60-89 ms - cl_interp" = "0.015625";cl_interp_ratio 3
90-109 ms - cl_interp" = "0.03125";cl_interp_ratio 2
110+ ms - cl_interp" = "0.03125";cl_interp_ratio 3

Ces réglages de base sont à affiner selon votre ressenti en jeu (touche, touche pas. sensation de lag ou même dans de tres rares cas l'impression de tirer en avance de la position du model 3D en mouvement visé), donc vous pouvez commencer avec les réglages ci-dessus et affiner vers les réglages ci-dessous si vous tirez sur quelqu'un et que vous n'avez pas l'impression de toucher.

<30 ms - cl_interp" = "0.007813"";cl_interp_ratio 1
30-59 ms - cl_interp" = "0.015625"";cl_interp_ratio 1
60-89 ms - cl_interp" = "0.015625";cl_interp_ratio 2
90-109 ms - cl_interp" = "0.03125";cl_interp_ratio 2
110+ ms - cl_interp" = "0.03125";cl_interp_ratio 2"

                            >>> copié collé conforme d'un pastbin <<<

Je vérifie tout ca en ce moment.

J'y ai retrouvé la plupart des infos trouvées par ci par là sur différents sites Fr-/De-/anglophone.

Ça m'a lair viable.

enjoy

Dernière modification par frox (21-02-2016 16:05:56)