Et ben voila. J'aimerais que l'ont m'explique un peu a quoi servent les commandes rate ,cl_cmdrate et cl_updaterate . Parce que j'ai un peu l'impression que chacun a ça théorie. Le problème majeur étant que quand je règle mes rate etc comme demandé, j'ai des chock loss et quand je ne touche ? rien j'ai aussi du chock et du loss. Parfois même je n'ai ni chock ni loss sur mon netgraph3 mais le jeu reste injouable avec des mini "lag" même si je ne pense pas que ce soit le mot le plus adapté. J'ai souvent du loss mais, aucun des ping celui de net graph et celui des score n'est au dessus de 100 ni même de 70 .Donc ça va de plein de petit blocage ? une énorme téléportation en arri?re. Ce n 'est pas un problème de fps je pense étant donné qu'ils ne descendent pas en dessous de 70. Voila, j'espère avoir donné suffisamment d'informations, merci de votre aide.
Alors pour commencer moi je ne dis jamais de changer le rate ou les autres. En premier parce que le gros important c'est de ne pas avoir de chock ou de loss. Ainsi qu'avoir une valeur identique pour cl_cmdrate et cl_updaterate. Donc sinon. Le rate dépend de ta connexion vu que c'est définit la vitesse ? laquelle tu vas récupérer les informations sur le serveur. Une connexion en 128 Kbps , il ne faut pas mettre plus de 15000. Pour du 512 c'est entre 15k et 20 000. Et enfin pour du 1024 ou plus il faut mettre minimum 20 000. 87 000 comme souvent demandé pourquoi pas. Le cl_updaterate et cl_cmdrate vont respectivement définir le nombre de paquet reçus et envoyés du serveur par seconde. Grosso modo plus on en reçoit et envoit plus le jeu sera fluide (niveau réseau). Et c'est directement lié au chock et au loss (respectivement aussi) puisque ceux-ci correspondent au nombre de paquets qu'on a pas ou mal reçus/envoyés. De la même façon que le rate. Pour une connexion 128 maximum ? 70 ou 75. Pour une 512 entre 80 et 100. Et pur une 1024 ou plus ? 100 ou 101. Après il y a aussi le fps qui rentre en jeu. Moins on a de fps moins on doit recevoir et envoyé sur le serveur de jeu. Bah oui il faut des informations pour gérer l'affichage et "inversement" (pas tout ? fait vrai et encore moins pour celui-l? mais on simplifie un peu ). En gros le calcul sera : cl_updaterate = (fps/X) + 1 (ou X definit le nombre d'images nécessaire avant de récupérer une nouvelle information, 1 pour une info tout les images, 2 pour une info toutes les deux images etc). Donc si tu as des soucis fait un petit calcul en fonction de ton fps moyen (même ? la louche ). Et ensuite test voir si ça rend les choses mieux. Ceci étant surtout valable ici ou les serveurs DiacrE sont capable de gérer les 100 rafraichissements par seconde. Ce qui n'est pas forcément le cas sur des serveurs avec tickrate plus faible. J'espère avoir été assez exhaustif et ne rien avoir oublié ou répété (ou autre) vu que j'ai fait ça en plusieurs fois à cause du boulot.
Merci pour les explications Aradar, j'y vois déjà plus clair. Mais les histoire de connexion ça a jamais été mon fort. Je télécharge 400 kbps mais certains dise 4Mega je pense, tu parles de quelle valeur ? ce moment ? Ensuite pour calculé le cl_updaterate j'ai (90/X) + 1, mais comment je trouve la valeur X?
Par défaut tu prends 1 pour que ça soit à chaque images. C'est la même chose. 4M (4096 bits) ça doit être ce que donne ton fournisseur d'acc?s en débit pour ton abonnement. Mais en réalité tu es ? 400 kB (400*8=3200 bits et un peu plus vu qu'il y aussi des bits de contrôle d'erreurs). Ce qui veut dire que tu n'atteins pas tout ? fait les 4M mais que tu n'en es pas loin non plus.
euh ...ben non, c'est pas vraiment vrai 1 Bytes = 1 octet = 8 bits.... une vitesse de transmission est décrite en bit , un volume de donnée en byte (byte = octet en anglais ). donc si ta connexion est ? 400kbit/s, en volume de donnée ça te fais l'inverse : 400/8 = 50ko/s......c'est pas la même d'un coup .....MAIS je te rassure, c'est juste une erreur de formulation, Keitach est bien ? 400 kbps et dans ce cas là on parle de byte donc d'octet, donc tu as une ligne ? 400ko/s donc une ligne ? 3,2 Mbit/s... Voilà..
Ouais me suis trompé (suis allé un peu vite pour faire mon round avec la bombe ). Mais tu sais très bien que malheureusement tout le monde parle uniquement de bits pour tout...
D'ailleurs, tant que j'y suis, je vais tenter de démystifier la chose. Voici un post tres complet : Un bon serveur ( c'est comme un bon et u mauvais chassuer, vous voyez ?? ) est un serveur configuré en tickrate 100. C?est à dire qu?il prend 100 phases (tick) de jeu par secondes, et ceci a une influence énorme sur la qualité de jeu. Ça influe sur les impacts de balles et les déplacement des joueurs car sur les serveurs qui ont le rendement de tick insuffisant, l?ordinateur doit calculer lui même la position ?officieuse? du personnage, mais pendant qu?il comble les vides, les personnes ne sont pas touchables car il n?existent pas en tant que tel sur le serveur !!! * Ce qui nous intéresse ici, c?est d?être synchro avec le serveur pour avoir un maximum de tick (sché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 connexion haut débit, on peut partir des meilleurs valeurs. Les configurations qui suivent seront efficace sur une machine capable de rouler CSS sans problèmes, doté d?une connexion haute vitesse. Les commandes de rates de base: Commande: (valeur sur un serveur a 100 tick, connexion haute vitesse) * cl_cmdrate (100) (on envoie vos actions, ou tick [déplacement, tirs, commande radio]) 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 a l?ordinateur de combler le vide de certain utilisateur qui n?envoient pas assez de tick au serveur, due a un mauvais fps ou a un cmdrate mal reglé. Mis a 0, ces joueurs seront sacadés et presque intuables. Cet interpolations est gerée par le client, et ne peut donc pas etre touché par les tirs de fusil.) * cl_interp_ratio (1) ( La valeur de cette variable divisée par l?update rate devrait donner 0.01, ou le plus proche possible, car c?est le délais de l?affichage des graphiques par rapport au données recues. ex: a 10, divisé par 100[updaterate] donne 0.1, ce qui signifie un retard de 0.09 secondes sur le reste sur monde sur le serveur. Le mieux serait d?atteidre 0.01. Sur le vieux moteur GoldSrc de Half-life 1, ce calcul etais inutile et les valeurs de délais etaient fait par la cvar ex_interp.) * rate (25000) ( C?est la limite d?octets que le serveur peut vous envoyer lors de la partie. Les limites du serveur sont pres de 30000, Plus vous etes pres de la limite du serveur, plus fluide sera votre jeu. Lorsqu?il est trop bas, le niveau de données recu est insuffisant et le jeu commence a se sacader, ce que nous appellons le choke dans le jeu.) * cl_predict (1) (Donne le droit au client de faire certaines choses sans recevoir d?autorisation du serveur, comme les tirs et les déplacements. Il se peut que des fois vous tiriez et que la balle passe au travers de la personne sans la toucher, eh bien c?est causé par cette cvar, le serveur na pas recu les info pour une raison quelconque mais le client avait pris les devans pour afficher cet info. Mis a 0 cette cvar cause un chaos, parce que certaines animations et certain déplacement sont coupé en plein milieu car le serveur a perdu linfo, ce qui aurait été comblé par le client en temps normal.) * cl_smooth (1) (Marche de paire avec cl_predict, car cette cvar adoucis le contre coup due au fait que le serveur na pas recu votre dernier tire, ou votre dernier déplacement. Mis a 0, cette cvar corrige radicalement votre position par rapport a celle que vous avez sur le serveur, ce qui cause du sacadement et certain moment ? WTF, jwarp! ? ) * cl_smoothtime (0.01) (C?est le temps accordé au cl_smooth pour faire effet, a garder le plus bas possible[0.01]. Si le smooth dépasse ce délais, le serveur va vous remettre en place brutalement. Tres peu présent sur les serveur de qualité.) Faut maintenant voir si votre configuration maintiens ces données , Comme javais dit, ces données sont celle optimales. ce qui est très peu souvent le cas pour le commun des mortels. ( les miennes sont un petit peu différentes de celle-ci car un connexion de crotte ...mais de chez naze) A+..
