Statistiques globales et en temps réel de la totalité des serveurs d'Urban Terror. Suivez l'évolution du nombre de joueurs sur Urban Terror !
Forums Échanges et discussions entre membres de la communauté
Paramètres réseaux et netgraphe
Guide approfondi sur le netgraphe et le réseau sous UrT
Encore une trad'.
Cette fois-ci, ça sera ce guide : http://www0.org/w/Networking,_lag_meter ... ban_Terror
Il a été écrit par la personne auteur de la rebuild du moteur ioq3 dont je vous parlais la dernière fois (mitsubishi).
Un guide très utile pour comprendre le netgraphe, savoir comment le lire, et il répond à beaucoup de questions qu'on a tous pu se poser un jour concernant le réseau sur Urban Terror.
Guide approfondi sur l'étude des paramètres réseaux et du netgraphe sous Urban Terror
"Hits ?", "Lag" ? Ce guide tente d'établir quelques vérités sur ces symptômes courants en expliquant quelques concepts intéressants relatifs au réseau et à la fluidité du jeu, comme une bonne lecture de votre netgraphe et l'utilisation de cvars. Le but est d'aider à diagnostiquer les problèmes que vous pourriez rencontrer et de constituer une base de connaissance pour des solutions potentielles. Par ailleurs, les informations données ici pourront vous aider à améliorer l'efficacité de votre jeu même si vous n'avez aucun problème en apparence.
Nous commencerons avec une section dédiée au netgraphe, à cause de son aide précieuse au diagnostique des problèmes. Puis nous continuerons avec les concepts majeurs ayant un intérêt ici. Une section dédiée à l'administration des serveurs est inclue, ce qui pourra être également utile aux joueurs. Quelques autres concepts pertinents et des question fréquemment posées concluent ce document.
Remarques introductives
Complexité du guide
Il peut paraître en effet complexe sans certaines connaissances de base concernant le réseau, et certains aspects concernant le moteur du jeu. Cependant, j'ai fait un effort pour être aussi compréhensible que possible. Vous pourriez avoir besoin de procéder à plusieurs lectures (et revenir à la première partie) si vous êtes confrontés certains concepts pour la première fois.
Précision du guide
Des omissions et des erreurs peuvent être présentes. Je tente actuellement de l'améliorer.
Les phrases [entre crochets] indiquent les parties qui peuvent nécessiter une révision ou une attention accrue. Les répétitions sont assez présentes afin d'être plus clair. Parfois des renvois sont faits à d'autres sections.
Glossaire
- Client : Le jeu côté joueur, l'installation du jeu par le joueur et son matériel.
- Serveur : Le côté serveur, les opérations effectuées par lui, la machine utilisée, son matériel réseau et sa propre installation du jeu.
- Lag meter : compteur de lag, netgraphe, lagometer, cg_lagometer...
- Client->Server : l'envoi d'infos du client au serveur.
- Server->Client : l'inverse.
Le netgraphe
(Ndr : terme utilisé pour tout le guide)
Les différentes parties du netgraphe
En termes basiques, nous distinguerons la partie du haut et la partie du bas.
Comment afficher le netgraphe
Tapez dans la console : cg_lagometer 1
Vous pouvez également introduire cette cvar dans vos .cfg ou la binder (utile).
Comment lire le netgraphe
Un netgraphe en état normal
En général, devrait être :
- Ligne du dessus : Toujours bleue, avec une forme en dents de scie régulière.
- Ligne du bas : Toujours verte et parfaitement plate.
Exemple :
Un joli netgraphe avec 64 de ping. Aucun problème n'est visible.
La ligne du dessus
Cette ligne indique l'interpolation / extrapolation. En fait, cette ligne avance d'un pixel à chaque rendu image. Une ligne entièrement bleue et avec de petits pics montre l'interpolation (c'est-à-dire que le jeu devine l'état de la "frame", (ndr : c'est-à-dire de ce que le joueur voit selon ce que le serveur lui envoie) entre 2 snapshots d'information) normalement effectuée, dans ce que le serveur envoie au client. C'est l'idéal.
Note du traducteur : la notion de "snapshot" est difficilement explicable et n'est pas traduisible, et elle sera réutilisée par la suite. Conceptuellement, un snapshot est la "mise à jour" des informations dont dispose le client pour reproduire ce qui se passe réellement sur le serveur (principalement la position du joueur et des autres joueurs par rapport à lui), ce qui lui sert bien sûr à afficher la position (réelle ou supposée) des autres joueurs, les bruits, etc. A chaque snapshot, ces informations sont réactualisées.
Le jaune sur la ligne du dessus
Le jaune signifie une fluctuation instable de plus de 50 millisecondes dans le taux de fréquence des snapshots. Cela conduit le client à "extrapoler" (il doit deviner de manière plus ou moins certaine ce qu'il doit afficher à l'écran) à partir de ce qu'il a reçu en dernier depuis le serveur. Une telle prédiction peut bien sûr être totalement erronée, ce qui cause certains problèmes dans le jeu (comme les problèmes de hits).
C'est là que ut_timenudge peut aider, car cela indique au client d'attendre plus de 50 millisecondes avant de passer à la frame suivante (et donc ne devrait pas être utilisé dans la plupart des cas). Vous en saurez plus sur le timenudge en lisant plus en avant ce manuel.
Plus techniquement, 50ms correspond à l'intervalle normal entre les différentes "update" (mises à jour des infos), sachant que le ratio sv_fps / snapshots est de 20 (20 fois par seconde, il y a 1000 msec dans une seconde, donc / 20 = 50ms). Si cette "update" - à cause d'une connexion instable ou de problèmes logiciels - arrive à une fréquence supérieure à 50ms (ou pas du tout), le client doit extrapoler (et tenter de deviner ce qui se passe sur le serveur), et l'indique sous la forme de pics jaunes.
Souvent, ce qui cause l'extrapolation, c'est le rate / sv_maxrate qui retarde la réception des snapshots par le serveur pour sauvegarde de la bande-passante. Reportez-vous à la section sur le "jaune sur la ligne du bas" ci-dessous. Similairement, les lignes rouges sur la ligne du bas (ci-dessous également) peuvent être en relation directe avec le jaune sur la ligne du dessus. La raison est simple : supprimer ou sauter des snapshots revient en fait à les retarder à l'extrême, et donc encore à forcer le client à extrapoler.
[Une autre raison possible est un CPU un peu submergé, ce qui rend le jeu incapable d'envoyer suffisamment de paquets à temps ("à temps", c'est-à-dire dans le ratio de 20 fps / snaps). Cela apparaît souvent sous la forme d'une large zone de jaune qui atteint la limite supérieur du netgraphe.]
Ligne du dessous
C'est la latence des snapshots et de leurs drops. Elle avance de 1 pixel à chaque snapshot d'information que le client reçoit du serveur (actuellement le taux est bloqué par le jeu sur un ratio de sv_fps / snaps à 20, comme vu ci-dessus). Si le dessus de la ligne (en vert) n'est pas parfaitement plat, alors le ping n'est pas parfaitement stable. Sa hauteur indique simplement l'importance du ping. S'il est bas, la ligne sera fine et inversement. L'idéal est d'avoir une ligne parfaitement plate et très fine. Le ping est également indiqué en chiffres dans le ping meter.
Lignes rouges
Cela indique que le snapshot du serveur a été sauté (perte de paquet server->client).
C'est généralement mauvais [car cela interrompt le transfert normal d'informations]. Une cause fréquente est que la connexion entre le client et le serveur (la capacité d'upload du serveur, ou la capacité de download du client) est "congestionnée" (surcharge) et que la bande-passante n'arrive pas à suivre. Un sv_maxrate plus bas (ou le rate pour le client) peut aider à résoudre le problème. Cependant, il peut s'agir de n'importe quoi entre les deux machines qui cause une instabilité ou qui monopolise la bande-passante.
Comme indiqué plus haut, c'est en relation directe avec l'extrapolation (et le jaune sur la ligne du dessus), car avoir bien sûr des paquets sautés ou perdus revient strictement à les avoir très en retard (plus de 50ms), ce qui force encore le client à extrapoler. Egalement, nous verrons plus bas comment aider à solutionner cette situation avec le ut_timenudge plus bas.
cl_packetdup n'est PAS lié directement à cette situation car il duplique les informations envoyées par le client au serveur (et non l'inverse), afin d'être plus sûr que les infos arriveront au serveur, car si un paquet se perd en route, un deuxième ou un troisième permettra quand même à l'info d'arriver à temps. Cependant, il est probable que la raison qui ait causé une perte de paquet entre le serveur et le client entraîne également une perte de paquets dans l'autre sens (un modem un peu faiblard, etc), donc quelque part, augmenter le nombre de paquets envoyés peut au moins améliorer la connexion entre le client et le serveur (sans agir dans le sens inverse). Une autre raison d'agir sur le cl_packetdup est que le netgraphe n'indique pas directement la qualité du transfert client->server (il n'affiche que l'inverse), ce qui fait qu'on est un peu dans le flou lorsqu'on s'intéresse à ce qui se passe du client au serveur (un netgraphe disponible côté serveur serait vraiment très utile, pour monitorer les infos client->serveur).
Jaune sur la ligne du bas
C'est théoriquement normal même si cela devrait être évité dans la mesure du possible. Il indique un retard du "taux de délai", ce qui signifie que selon le rate et le sv_maxrate, un snapshot du serveur a été supprimé afin de préserver la bande-passante. Donc si vous voulez un jeu fluide et fiable, vous devriez faire en sorte de l'éviter. La raison principale à cela, est qu'un taux de transfert un peu en retard entraîne (encore) une extrapolation (et du... jaune sur la ligne du dessus !), forçant le jeu à deviner la position des autres joueurs par exemple, ce qui entraîne des soucis de hits et d'autres.
Cela devrait être moins fréquent depuis que la valeur la plus basse permise par le jeu est de 8000. Cependant, un serveur fréquenté, de 16 joueurs ou plus, peut nécessiter jusqu'à 12000 ou 15000 sur le sv_maxrate, pour éviter le jaune sur la ligne du bas (lui-même source de jaune sur la ligne du dessus). Si vous pouvez vous le permettre en bande-passante (car une surcharge en upload est encore pire : lignes rouges), une valeur sûre serait de 25000 (0 est la valeur par défaut, il correspond également à la valeur la plus haute, 250000). Reportez-vous à la section concernant l'administration de serveurs ci-dessous pour plus d'infos.
Les trous sur la ligne du bas (pas de couleur du tout)
Cela arrive lors d'un "freeze" temporaire, dû au CPU ou autre, ce qui arrive souvent lors d'une lecture ou écriture sur le disque par le moteur du jeu pendant que vous jouez (par exemple). Vous pouvez constater ce phénomène lorsque vous faites "/screenshot" (écriture d'un fichier image sur le disque), mais cela peut également venir d'autres problèmes tels qu'un bug dans le pilote graphique ou d'une surchauffe de votre carte vidéo.
Un exemple :
En fait, quoique le moteur du jeu puisse faire, il peut avoir besoin d'un certain temps pour effectuer les opérations demandées. Un trou va apparaître lorsque le moteur nécessite un peu plus de temps pour finir une opération et qu'il zappe tout le reste. Cela n'est bien évidemment pas normal.
Un grand secours peut venir de cette build optimisée. Elle résout notamment les deux problèmes les plus fréquents qui causent des freezes : la radio et quelques autres samples audios et funstuff qui n'étaient auparavant pas préchargés par le jeu.
Comme un trou vient souvent d'un accès disque pendant le jeu (ce qui ne devrait pas avoir lieu), vous pouvez essayer un /fs_debug 1 et voir s'il y a des accès écriture/lecture sur le disque pendant que vous jouez.
Lignes noires
Cela indique que l'antiwarping a été utilisé côté client. Normalement lorsqu'un joueur warp, cela se voit sur le serveur (il se téléporte), mais l'antiwarp permet aux autres joueurs de ne pas le voir. Le warp se produit lorsque le serveur ne reçoit pas les infos de manière assez fréquente pour updater sa position sur la map, ce qui est dû à des pertes de paquets importantes entre le client et le serveur, ou un ping totalement instable. L'antiwarp est contrôlé par le serveur (voir plus bas). [Cela va simultanément rendre le jeu instable pour le warpeur, qui peut trouver le jeu (encore) plus difficile à contrôler.]
Comme cela peut indirectement signifier une importante perte de paquets du client au serveur (ce qui n'est pas affiché je le rappelle par le netgraphe), la commande cl_packetdup peut aider dans une telle situation (essayez de le mettre à 3 par exemple). Toutefois cela ne sera d'aucun secours si le warp provient d'un ping instable. Un cl_maxpackets peut également aider, même s'il est confiné dans une fourchette 30-42 sur UrT.
Limitations du netgraphe
La limitation la plus importante du netgraphe nous l'avons dit, et que s'il est plutôt complet au niveau de ce qui se passe entre le serveur et le client, en revanche, on ne sait pas, du moins pas directement, ce qu'il se passe pour les commandes envoyées par le client au serveur. En effet, seul un netgraphe côté serveur peut l'indiquer.
C'est la raison pour laquelle cl_packetdup est plus important en réalité qu'il n'y paraît, car si son effet n'est pas directement affiché sur le netgraphe, le fait d'envoyer plusieurs fois la même info au serveur pour augmenter les chances de réception est très utile.
Comme mentionné plus haut également concernant les lignes rouges, il faut garder à l'esprit que le rouge n'indique uniquement que les infos venant du serveur ont été perdues, et non l'inverse. Ainsi, un drop du client au serveur peut exister même si la capacité d'upload du serveur est correcte, mais que sa capacité de download se trouve poussée à ses limites, et plus généralement, lorsque la capacité d'upload du client ne suit pas (en effet la plupart des connexions de particuliers sont très limitées en upload, alors que le download peut être très correct).
En conclusion, un netgraphe sur la machine serveur pourrait être d'un intérêt significatif pour dresser un tableau complet de la situation concernant les pertes de paquets client->server ou les connexions instables.
Aspects importants concernant le jeu
ut_timenudge
ut_timenudge (également connu dans UrT sous le nom de "local net buffer") retarde l'acheminement des informations de jeu vers le client pour rendre le jeu plus "régulier", plus "lisse". Cela consiste à créer une sorte de lag local pour faire en sorte que le jeu soit plus uniforme dans son affichage. D'où l'importance de savoir quand l'utiliser, quand ne pas l'utiliser, et quelle valeur pourrait être efficace.
Pour comprendre le fonctionnement de cette commande, vous devez savoir comment le jeu marche en ce qui concerne le partage d'informations entre le client et le serveur.
Le serveur et le client ont une "discussion" pendant le jeu, ils échangent ce qu'ils savent sur le déroulement de la partie. Les informations sont envoyées au client par le serveur toutes les 50 millisecondes (intervalle dû au ratio de 20 de sv_fps / snaps et 1000 ms (1 sec) / 20 = 50ms). Parallèlement, le client envoie ses propres infos et ses commandes (avancer, tirer...) au serveur selon le cl_maxpackets et les FPS, bien que cela n'ait qu'une petite influence sur l'utilisation du timenudge.
Si la ligne du dessus a des pics jaunes, cela signifie que le client n'a pas eu les informations attendues au moment prévu (plus de 50 ms depuis le dernier snapshot, rappelez-vous) et donc la "discussion" n'est pas aussi régulière qu'elle devrait l'être. Le jeu et le serveur doivent donc deviner ce qui se passe en se basant sur les dernières infos reçues (extrapolation). En mettant le timenudge par exemple à 30, le client attend 30ms de plus avant de retranscrire à l'écran ce qu'il sait à partir des nouvelles infos obtenues, dans l'espoir d'obtenir au final un rendu plus fidèle à la réalité et de rendre le jeu plus fluide, au cas où des informations un peu en retard finiraient par arriver.
Quand ut_timenudge est utilisé, la barre du haut sur le netgraphe devient plus épaisse. Visuellement, il devient plus dur de voir du jaune, car l'épaisseur de la barre va le couvrir plus facilement [(même si cela ne signifie pas pour autant qu'il n'y a pas d'extrapolation du tout.)]
Vous pouvez tester 10 ou 20 en valeur (comme proposé par le codeur du timenudge, TwentySeven), même si vous n'avez pas de problème apparent, au moins à court terme. Vous pouvez aller de 0 à 50 (les valeurs négatives ne sont pas acceptées par le jeu).
A bas niveau, ut_timenudge altère en fait les timestamps des paquets entrants pour faire croire qu'ils arrivent un peu plus tard. cl_timenudge présent auparavant sur les mods q3 permettait également de différer les paquets client->server, mais c'était un exploit qui pouvait être utilisé pour créer du warp artificiel, et UrT a supprimé cette variable.
Ce procédé ajoute donc du lag en local, et donc ce que vous aurez à l'écran sera une représentation un peu "en retard" par rapport à ce qui se passe réellement sur le serveur (disons encore plus tard que ce qui est normalement dû à une latence classique). Par conséquent, vous ne devriez pas jouer sur le timenudge si vous n'avez pas vraiment de pics jaunes, ou plus généralement, s'il n'y a pas de problème que le timenudge serait le seul à pouvoir régler. Ce qu'on pourrait appeler les "hits" peuvent s'améliorer en évitant l'extrapolation décrite ci-dessus.
L'antilag (voir ci-dessous) est pris en compte lorsque le timenudge altère les temps de perception de la réalité du jeu, son fonctionnement n'est donc pas perturbé.
Si vous n'avez que quelques pics jaunes épars, vous ne devriez probablement pas utiliser timenudge, car avoir un jeu un poil moins fluide toutes les 10 ou 20 secondes est toujours mieux qu'un lag local permanent.
L'antilag et les "delayed hits" (hits derrière un mur)
Le "code sans lag" ("unlagged code") (opéré par le serveur), également connu sous le nom d'antilag sous UrT, évite d'avoir besoin de prédire où une cible qui se fait tirer dessus "sera" pour compenser le lag (alors que c'était le cas au tout début d'UrT). L'antilag fonctionne de manière à garder une trace de "où et quand" un attaquant (celui qui fait feu) a vu une cible, en tenant compte de la latence naturelle du jeu.
Donc, quand un joueur avec un gros ping voit un joueur avec un faible ping, il le touchera toujours à l'endroit où il pensait viser, sans avoir à prédire où la cible "se trouvera" en tenant compte du lag (même si, en tenant compte du lag du tireur, l'enregistrement du tir (lorsque le serveur traitera l'info selon laquelle le joueur a appuyé sur fire) sera toujours plus tardive que s'il s'agissait du faible ping qui tirait).
L'effet collatéral est courant : un gros ping va effectivement pouvoir toucher le faible ping "dans le coin du mur", c'est-à-dire "derrière" en fait. Le petit ping pourra avoir été dans la ligne de mire du gros ping au moment où il se faisait tirer dessus, cependant en raison du lag plus important du gros ping, le joueur avec le gros ping a vu la scène se dérouler "plus tôt" que depuis la perspective du petit ping. Si vous voulez, dans le "temps réel" du petit ping, ce dernier a effectivement pu se cacher derrière un mur mais en fait le gros ping le voit toujours bien visible sur son écran (car il a un lag supplémentaire). Donc le gros ping va tirer, et c'est là que l'antilag va "l'aider", en lui permettant d'atteindre tout de même sa cible, en se basant sur ce que voit le gros ping (plutôt que de se fier à la réalité, en fait), ce qui va éviter de devoir tenir compte du lag tout simplement. Par conséquent, le petit ping va avoir l'impression de se faire tirer dessus alors qu'il est caché derrière un mur, et c'est bien ce qui se passe. (Ce phénomène est également présent lorsque ce sont deux gros pings qui se tirent dessus, mais c'est plus compliqué à décrire. On peut également considérer la perspective du gros ping qui se fait tirer dessus par un petit ping, ça marche également.)
Toutefois, le gros ping sera toujours handicapé par rapport au petit ping, car le gros ping voit toujours ce qui se passe sur le serveur un peu en retard par rapport au petit ping. Les plus petits pings auront toujours une longueur d'avance sur les autres.
On pourrait théoriquement contrebalancer ce petit effet collatéral en faisant en sort que le netcode ignore les infos de hits lorsque ce phénomène apparaît (peut-être que cela demanderait plus de ressources), donc je ne serais pas surpris si c'était le cas dans une version ultérieure du jeu.
Gardez à l'esprit cependant que dans un jeu où toutes les armes sont en "hitscan" (c'est-à-dire que le jeu fait abstraction totale des règles physiques élémentaires de balistisque : une balle dans la réalité a un véritable chemin à parcourir, chemin qui prend du temps et qui peut être dévié - le hitscan, qui est présent dans la quasi totalité des FPS, est le nom donné au fait que les armes touchent instantanément leurs cibles), comme UrT (quake3 avait seulement des railguns et des machineguns), l'antilag reste tout de même d'une grande importance pour un jeu plus fluide. Probablement la plus grande partie des faibles pings (50-60ms) eux-mêmes trouveraient les hits plus aléatoires s'il n'existait pas.
L'antilag ne peut pas être modifié, désactivé ou altéré, du moins "légalement", et c'est probablement mieux ainsi.
Note : Sachez également que le phénomène du "hit derrière les murs" peut avoir existé sans l'antilag, à cause du lag classique, mais il était alors beaucoup moins prononcé.
L'antiwarp
L'antiwarp est un système côté serveur également qui simplement rend les gens moins susceptibles de warper. C'est plus difficile de voir les warpers "en vrai" de nos jours. Souvent, ce n'est pas vraiment eux qui warpent, mais l'observateur qui a une connexion instable. Parfois, ils warpent réellement car l'admin du serveur n'a pas bien configuré l'antiwarp. Le warp apparaît lorsque le serveur ne reçoit pas les infos du joueur assez fréquemment (ping instable, pertes de paquets).
Si l'antiwarp agit sur vous, vous le verrez avec des lignes noires sur le netgraphe. Cela peut être l'indication que vous perdez des paquets en route, et cl_packetdup peut aider dans ce cas. Cependant, vous pouvez warper à cause d'un ping fou, et alors dupliquer les paquets ne sera d'aucune aide.
Reportez-vous à la section plus bas pour savoir comment configurer l'antiwarp côté serveur.
/rate
Le "rate" contrôle la densité du trafic entre le serveur et le client (combien de bytes par seconde il l'autorise à lui envoyer). C'est également limité par la variable serveur sv_maxrate et sv_minrate (par exemple si ces variables contiennent 20000 et 12000, vous serez vous-même limité entre ces 2 valeurs).
Ce n'est plus vraiment d'une importance capitale de nos jours depuis que le jeu utilise ce qu'on appelle la "compression delta" et qu'un client utilise facilement entre 4 et 8Ko/sec (même si on peut toujours assister à un certain engorgement dans les valeurs les plus basses, 8000 correspondant à 7.81Kb/s).
Ainsi, un rate très bas, disons à 8000 ou 10000 sur un serveur fréquente (16+) est souvent une source de jaune sur la ligne du dessus et du bas, ce qui nuit à la fluidité du jeu. Reportez-vous éventuellement à la partie consacrée à l'admin serveur pour plus d'infos.
Aujourd'hui garder cette valeur à 25000 ne devrait pas poser de problèmes pour la majorité des connexions avec une bande-passante correcte. Cela correspond à un taux (bytes / secondes) de 24.41Kb/s seulement (taux qui n'est même pas atteint dans la réalité la plupart du temps). Il y a eu une rumeur selon laquelle si le serveur mettait son maxrate en dessous de 25 000, c'était mieux de mettre également une valeur inférieure, mais on peut en douter fortement (parce que le serveur vérifiera toujours le taux du client pour l'ajuster dans sa propre fourchette).
Le réglage du taux est également important pour la VoIP dans les récentes versions de ioquake3 ; si jamais IoUrT inclut cette fonctionnalité dans une version ultérieure (a priori sera le cas dans la 4.2), il est conseillé de garder cette valeur assez haute, bien sûr toujours dans la limite acceptée par votre connexion.
La meilleure indication pour définir le meilleur /rate est la présence ou non de jaune sur la ligne du bas. S'il y a du jaune au lieu du vert, cela signifie que le client indique que son taux de transfert a été perturbé. Idéalement, pour une latence minimale et pour éviter le jaune sur la ligne du dessus, vous devriez éviter cela.
Bien sûr, même aujourd'hui où les besoins du moteur du jeu sont des cacahuètes pour la bande-passante des connexions modernes, n'oubliez pas qu'un taux important sur une connexion lente est pire qu'un taux plus réduit, car un taux réduit signifie tout au plus un jeu un peu instable, alors qu'un taux de transfert important pour une faible connexion va lui causer du lag majeur. C'est également d'une certaine importance car le lag peut venir du serveur ou même de n'importe où ailleurs à travers l'internet.
cl_maxpackets et les FPS
Ce que fait cl_maxpackets
A l'inverse de rate, cl_maxpackets définit la quantité maximale d'informations envoyées par le client au serveur, par seconde. Sous UrT, cette variable est bloquée entre 30 et 42. C'est en forte corrélation avec les FPS du client.
Important (et peut-être moins compréhensible)
Les FPS constituent un élément majeur du jeu, qui gouverne bien d'autres choses que les FPS. Ainsi, le client ne peut envoyer qu'une seule "update" à chaque frame, ou une toutes les 2 frames, ou une toutes les 3 frames... Ainsi, si vous êtes à 125 FPS, vous pouvez envoyer 125 updates par seconde au serveur, ou 62.5 par seconde, ou 41.7 par seconde, 31.25, 25... (les valeurs ne sont pas arrondies par le jeu). Si vous avez un drop 100 (ou si vous avez fixé vos FPS à 100), les valeurs seront diminuées proportionnellement : 100 infos par seconde, 50, 33.3, 25, 20...
- Ce que cela signifie
Donc, si vous avez un cl_maxpackets à 30 pour 125 FPS, le client enverra 25 updates par seconde. Si vous avez 100 FPS, il enverra encore 25 infos par seconde. Si vous avez un maxpackets à 42, il enverra 41.7 up par seconde pour 125 FPS (et en fait on comprend que 42, la valeur max autorisée par le jeu, correspond à la valeur la plus optimisée pour des FPS stables à 125), et enverra 33.3 up par seconde à 100 FPS.
Aidez-vous de vos maths et de votre logique pour calculer les autres cas.
Le principe de base ici est d'obtenir la latence la plus faible possible en envoyant le plus de paquets possible au serveur, par exemple en conservant une stabilité à 125 FPS. Pour 125 par exemple, il semblerait que 42 corresponde le mieux.
Un exemple de mauvais choix serait par exemple si vous limitez vos FPS à 60 dans le jeu, le client sera capable au choix d'envoyer 60, 30 ou 20 paquets par seconde au serveur. Cela signifie que le jeu ne sera pas capable d'utiliser au max un maxpackets à 42, mais seulement de 30. Similairement, avec 100 FPS, il pourra n'envoyer que 33.3 up par sec.
Peut-être que la limite de 42 sera levée dans le futur d'UrT (jusqu'à 125 ?), ce qui rendrait le jeu bien plus fluide.
- A savoir pour régler ses FPS max avec com_maxfps
Maintenant, lorsque vous définissez votre com_maxfps pour tenir compte des informations données ci-dessus, gardez à l'esprit que les FPS qui sont effectivement affichés à l'écran sont limités en valeurs de 1000ms divisés par un nombre entier, parce que le moteur du jeu calcule la durée des frames en utilisant des nombres entiers en millisecondes. Donc vous ne pouvez que mettre 125 FPS (1000/8), 111.11 (1000/9), 100, 90, 90.9, 83.3, 76.9, 71.4, 66.6, 62.5, 58.82, etc. (sans arrondir).
[Par exception, ne tenez pas compte de ceci lorsque vous avez la vsynch activée, car le rendu sera forcé pour correspondre à la fréquence du moniteur, en général de 60Hz).
En règle générale
Selon ce qui a été dit ci-dessus, on peut conclure sur le fait que dans l'intérêt d'une latence minimale, cl_maxpackets peut être laissé à 42 quels que soient vos FPS, sauf si vous avez vraiment besoin de limiter votre bande-passante (rare sur les connexions modernes). D'un autre côté - si vous pouvez vous le permettre - avoir 125 FPS max est une bonne chose pour une efficacité optimale, car cela correspond parfaitement à un taux de 42 paquets/seconde.
N'oubliez pas que si vous ne pouvez atteindre que 80 FPS, il peut être préférable d'avoir un com_maxfps à 80 et non à 125 car dans ce cas votre maxpackets atteindra 40 (pour les raisons mentionnées ci-dessus) au lieu d'une valeur plus basse, disons 90, où le max rate ne sera que de 30 (car 90/3 = 30 mais 90/2 = 45). Cependant, cette conclusion peut être mensongère dans la mesure où un ordinateur moyen peut facilement atteindre les 90, et que de manière évidente (complexité du jeu, selon la map, le type de jeu, le nombre de joueurs, etc), la valeur réelle pourra fluctuer autour de 90, et les calculs ne seront que partiellement inapplicables.
1000 / nombre entier / nombre entier
La relation peut être résumée ainsi : FPS = 1000 / nombre entier ; paquets par seconde envoyés au serveur = 1000 / nombre entier(FPS) / nombre entier.
Un arrondissement interne pas très logique
Le plafond de la variable est arrondi en interne de manière assez illogique : com_maxfps à 84 va jusqu'à 90.090... alors que 83 reste sur 83.333...
C'est-à-dire qu'un com_maxfps à 84 donne effectivement 30.30.. paquets par seconde parce que les FPS seront vraiment mis au max à 90.090, alors que la valeur correcte pour arriver à 41.666 serait plutôt 83, alors que c'est ce que nous voulons pour une latence minime avec le plafond disponible de cl_maxpackets.
cl_packetdup
cl_packetdup duplique les informations envoyées par le client au serveur afin d'augmenter la probabilité que les infos arrivent bien (un paquet droppé sera remplacé par le suivant). La valeur peut être de 1, 2 ou 3 selon le nombre de paquets identiques qui seront envoyés.
Activer cette fonction est bien plus important qu'il n'y paraît, car si le netgraphe est plutôt généreux en ce qui concerne les infos server->client, en revanche il est totalement muet concernant le chemin inverse. Ainsi, vous pouvez être confronté à un jeu instable alors que votre netgraphe semble correct. Bien sûr, si vous êtes confiants concernant les paquets envoyés (vous êtes sûr qu'ils arrivent tous à bon port), vous pouvez vous permettre de désactiver cl_packetdup afin d'arriver à une "latence absolument minime".
Comme on l'a déjà dit, des lignes rouges dans le netgraphe ne signifient PAS que le cl_packetdup sera obligatoirement utile. Les lignes rouges indiquent une perte de paquet du client au serveur, ce qui n'est pas le sens du chemin où cl_packetdup agit. Cependant, s'il s'agit de la même cause qui produit des pertes de paquets dans les deux sens, alors dupliquer les paquets pourra toujours améliorer la transition entre le client et le serveur (par exemple un matériel défectueux entre le client et le serveur).
De la même façon, des lignes noires indiquent que vous êtes victime de l'antiwarp côté serveur, et cela indique indirectement qu'il y a des pertes de paquets entre vous et le serveur et encore une fois dupliquer vos paquets pourra réduire le warp (même si, on l'a vu, le problème peut aussi venir d'un ping instable).
Cette fois-ci, ça sera ce guide : http://www0.org/w/Networking,_lag_meter ... ban_Terror
Il a été écrit par la personne auteur de la rebuild du moteur ioq3 dont je vous parlais la dernière fois (mitsubishi).
Un guide très utile pour comprendre le netgraphe, savoir comment le lire, et il répond à beaucoup de questions qu'on a tous pu se poser un jour concernant le réseau sur Urban Terror.
Guide approfondi sur l'étude des paramètres réseaux et du netgraphe sous Urban Terror
"Hits ?", "Lag" ? Ce guide tente d'établir quelques vérités sur ces symptômes courants en expliquant quelques concepts intéressants relatifs au réseau et à la fluidité du jeu, comme une bonne lecture de votre netgraphe et l'utilisation de cvars. Le but est d'aider à diagnostiquer les problèmes que vous pourriez rencontrer et de constituer une base de connaissance pour des solutions potentielles. Par ailleurs, les informations données ici pourront vous aider à améliorer l'efficacité de votre jeu même si vous n'avez aucun problème en apparence.
Nous commencerons avec une section dédiée au netgraphe, à cause de son aide précieuse au diagnostique des problèmes. Puis nous continuerons avec les concepts majeurs ayant un intérêt ici. Une section dédiée à l'administration des serveurs est inclue, ce qui pourra être également utile aux joueurs. Quelques autres concepts pertinents et des question fréquemment posées concluent ce document.
Remarques introductives
Complexité du guide
Il peut paraître en effet complexe sans certaines connaissances de base concernant le réseau, et certains aspects concernant le moteur du jeu. Cependant, j'ai fait un effort pour être aussi compréhensible que possible. Vous pourriez avoir besoin de procéder à plusieurs lectures (et revenir à la première partie) si vous êtes confrontés certains concepts pour la première fois.
Précision du guide
Des omissions et des erreurs peuvent être présentes. Je tente actuellement de l'améliorer.
Les phrases [entre crochets] indiquent les parties qui peuvent nécessiter une révision ou une attention accrue. Les répétitions sont assez présentes afin d'être plus clair. Parfois des renvois sont faits à d'autres sections.
Glossaire
- Client : Le jeu côté joueur, l'installation du jeu par le joueur et son matériel.
- Serveur : Le côté serveur, les opérations effectuées par lui, la machine utilisée, son matériel réseau et sa propre installation du jeu.
- Lag meter : compteur de lag, netgraphe, lagometer, cg_lagometer...
- Client->Server : l'envoi d'infos du client au serveur.
- Server->Client : l'inverse.
Le netgraphe
(Ndr : terme utilisé pour tout le guide)
Les différentes parties du netgraphe
En termes basiques, nous distinguerons la partie du haut et la partie du bas.
Comment afficher le netgraphe
Tapez dans la console : cg_lagometer 1
Vous pouvez également introduire cette cvar dans vos .cfg ou la binder (utile).
Comment lire le netgraphe
Un netgraphe en état normal
En général, devrait être :
- Ligne du dessus : Toujours bleue, avec une forme en dents de scie régulière.
- Ligne du bas : Toujours verte et parfaitement plate.
Exemple :
Un joli netgraphe avec 64 de ping. Aucun problème n'est visible.
La ligne du dessus
Cette ligne indique l'interpolation / extrapolation. En fait, cette ligne avance d'un pixel à chaque rendu image. Une ligne entièrement bleue et avec de petits pics montre l'interpolation (c'est-à-dire que le jeu devine l'état de la "frame", (ndr : c'est-à-dire de ce que le joueur voit selon ce que le serveur lui envoie) entre 2 snapshots d'information) normalement effectuée, dans ce que le serveur envoie au client. C'est l'idéal.
Note du traducteur : la notion de "snapshot" est difficilement explicable et n'est pas traduisible, et elle sera réutilisée par la suite. Conceptuellement, un snapshot est la "mise à jour" des informations dont dispose le client pour reproduire ce qui se passe réellement sur le serveur (principalement la position du joueur et des autres joueurs par rapport à lui), ce qui lui sert bien sûr à afficher la position (réelle ou supposée) des autres joueurs, les bruits, etc. A chaque snapshot, ces informations sont réactualisées.
Le jaune sur la ligne du dessus
Le jaune signifie une fluctuation instable de plus de 50 millisecondes dans le taux de fréquence des snapshots. Cela conduit le client à "extrapoler" (il doit deviner de manière plus ou moins certaine ce qu'il doit afficher à l'écran) à partir de ce qu'il a reçu en dernier depuis le serveur. Une telle prédiction peut bien sûr être totalement erronée, ce qui cause certains problèmes dans le jeu (comme les problèmes de hits).
C'est là que ut_timenudge peut aider, car cela indique au client d'attendre plus de 50 millisecondes avant de passer à la frame suivante (et donc ne devrait pas être utilisé dans la plupart des cas). Vous en saurez plus sur le timenudge en lisant plus en avant ce manuel.
Plus techniquement, 50ms correspond à l'intervalle normal entre les différentes "update" (mises à jour des infos), sachant que le ratio sv_fps / snapshots est de 20 (20 fois par seconde, il y a 1000 msec dans une seconde, donc / 20 = 50ms). Si cette "update" - à cause d'une connexion instable ou de problèmes logiciels - arrive à une fréquence supérieure à 50ms (ou pas du tout), le client doit extrapoler (et tenter de deviner ce qui se passe sur le serveur), et l'indique sous la forme de pics jaunes.
Souvent, ce qui cause l'extrapolation, c'est le rate / sv_maxrate qui retarde la réception des snapshots par le serveur pour sauvegarde de la bande-passante. Reportez-vous à la section sur le "jaune sur la ligne du bas" ci-dessous. Similairement, les lignes rouges sur la ligne du bas (ci-dessous également) peuvent être en relation directe avec le jaune sur la ligne du dessus. La raison est simple : supprimer ou sauter des snapshots revient en fait à les retarder à l'extrême, et donc encore à forcer le client à extrapoler.
[Une autre raison possible est un CPU un peu submergé, ce qui rend le jeu incapable d'envoyer suffisamment de paquets à temps ("à temps", c'est-à-dire dans le ratio de 20 fps / snaps). Cela apparaît souvent sous la forme d'une large zone de jaune qui atteint la limite supérieur du netgraphe.]
Ligne du dessous
C'est la latence des snapshots et de leurs drops. Elle avance de 1 pixel à chaque snapshot d'information que le client reçoit du serveur (actuellement le taux est bloqué par le jeu sur un ratio de sv_fps / snaps à 20, comme vu ci-dessus). Si le dessus de la ligne (en vert) n'est pas parfaitement plat, alors le ping n'est pas parfaitement stable. Sa hauteur indique simplement l'importance du ping. S'il est bas, la ligne sera fine et inversement. L'idéal est d'avoir une ligne parfaitement plate et très fine. Le ping est également indiqué en chiffres dans le ping meter.
Lignes rouges
Cela indique que le snapshot du serveur a été sauté (perte de paquet server->client).
C'est généralement mauvais [car cela interrompt le transfert normal d'informations]. Une cause fréquente est que la connexion entre le client et le serveur (la capacité d'upload du serveur, ou la capacité de download du client) est "congestionnée" (surcharge) et que la bande-passante n'arrive pas à suivre. Un sv_maxrate plus bas (ou le rate pour le client) peut aider à résoudre le problème. Cependant, il peut s'agir de n'importe quoi entre les deux machines qui cause une instabilité ou qui monopolise la bande-passante.
Comme indiqué plus haut, c'est en relation directe avec l'extrapolation (et le jaune sur la ligne du dessus), car avoir bien sûr des paquets sautés ou perdus revient strictement à les avoir très en retard (plus de 50ms), ce qui force encore le client à extrapoler. Egalement, nous verrons plus bas comment aider à solutionner cette situation avec le ut_timenudge plus bas.
cl_packetdup n'est PAS lié directement à cette situation car il duplique les informations envoyées par le client au serveur (et non l'inverse), afin d'être plus sûr que les infos arriveront au serveur, car si un paquet se perd en route, un deuxième ou un troisième permettra quand même à l'info d'arriver à temps. Cependant, il est probable que la raison qui ait causé une perte de paquet entre le serveur et le client entraîne également une perte de paquets dans l'autre sens (un modem un peu faiblard, etc), donc quelque part, augmenter le nombre de paquets envoyés peut au moins améliorer la connexion entre le client et le serveur (sans agir dans le sens inverse). Une autre raison d'agir sur le cl_packetdup est que le netgraphe n'indique pas directement la qualité du transfert client->server (il n'affiche que l'inverse), ce qui fait qu'on est un peu dans le flou lorsqu'on s'intéresse à ce qui se passe du client au serveur (un netgraphe disponible côté serveur serait vraiment très utile, pour monitorer les infos client->serveur).
Jaune sur la ligne du bas
C'est théoriquement normal même si cela devrait être évité dans la mesure du possible. Il indique un retard du "taux de délai", ce qui signifie que selon le rate et le sv_maxrate, un snapshot du serveur a été supprimé afin de préserver la bande-passante. Donc si vous voulez un jeu fluide et fiable, vous devriez faire en sorte de l'éviter. La raison principale à cela, est qu'un taux de transfert un peu en retard entraîne (encore) une extrapolation (et du... jaune sur la ligne du dessus !), forçant le jeu à deviner la position des autres joueurs par exemple, ce qui entraîne des soucis de hits et d'autres.
Cela devrait être moins fréquent depuis que la valeur la plus basse permise par le jeu est de 8000. Cependant, un serveur fréquenté, de 16 joueurs ou plus, peut nécessiter jusqu'à 12000 ou 15000 sur le sv_maxrate, pour éviter le jaune sur la ligne du bas (lui-même source de jaune sur la ligne du dessus). Si vous pouvez vous le permettre en bande-passante (car une surcharge en upload est encore pire : lignes rouges), une valeur sûre serait de 25000 (0 est la valeur par défaut, il correspond également à la valeur la plus haute, 250000). Reportez-vous à la section concernant l'administration de serveurs ci-dessous pour plus d'infos.
Les trous sur la ligne du bas (pas de couleur du tout)
Cela arrive lors d'un "freeze" temporaire, dû au CPU ou autre, ce qui arrive souvent lors d'une lecture ou écriture sur le disque par le moteur du jeu pendant que vous jouez (par exemple). Vous pouvez constater ce phénomène lorsque vous faites "/screenshot" (écriture d'un fichier image sur le disque), mais cela peut également venir d'autres problèmes tels qu'un bug dans le pilote graphique ou d'une surchauffe de votre carte vidéo.
Un exemple :
En fait, quoique le moteur du jeu puisse faire, il peut avoir besoin d'un certain temps pour effectuer les opérations demandées. Un trou va apparaître lorsque le moteur nécessite un peu plus de temps pour finir une opération et qu'il zappe tout le reste. Cela n'est bien évidemment pas normal.
Un grand secours peut venir de cette build optimisée. Elle résout notamment les deux problèmes les plus fréquents qui causent des freezes : la radio et quelques autres samples audios et funstuff qui n'étaient auparavant pas préchargés par le jeu.
Comme un trou vient souvent d'un accès disque pendant le jeu (ce qui ne devrait pas avoir lieu), vous pouvez essayer un /fs_debug 1 et voir s'il y a des accès écriture/lecture sur le disque pendant que vous jouez.
Lignes noires
Cela indique que l'antiwarping a été utilisé côté client. Normalement lorsqu'un joueur warp, cela se voit sur le serveur (il se téléporte), mais l'antiwarp permet aux autres joueurs de ne pas le voir. Le warp se produit lorsque le serveur ne reçoit pas les infos de manière assez fréquente pour updater sa position sur la map, ce qui est dû à des pertes de paquets importantes entre le client et le serveur, ou un ping totalement instable. L'antiwarp est contrôlé par le serveur (voir plus bas). [Cela va simultanément rendre le jeu instable pour le warpeur, qui peut trouver le jeu (encore) plus difficile à contrôler.]
Comme cela peut indirectement signifier une importante perte de paquets du client au serveur (ce qui n'est pas affiché je le rappelle par le netgraphe), la commande cl_packetdup peut aider dans une telle situation (essayez de le mettre à 3 par exemple). Toutefois cela ne sera d'aucun secours si le warp provient d'un ping instable. Un cl_maxpackets peut également aider, même s'il est confiné dans une fourchette 30-42 sur UrT.
Limitations du netgraphe
La limitation la plus importante du netgraphe nous l'avons dit, et que s'il est plutôt complet au niveau de ce qui se passe entre le serveur et le client, en revanche, on ne sait pas, du moins pas directement, ce qu'il se passe pour les commandes envoyées par le client au serveur. En effet, seul un netgraphe côté serveur peut l'indiquer.
C'est la raison pour laquelle cl_packetdup est plus important en réalité qu'il n'y paraît, car si son effet n'est pas directement affiché sur le netgraphe, le fait d'envoyer plusieurs fois la même info au serveur pour augmenter les chances de réception est très utile.
Comme mentionné plus haut également concernant les lignes rouges, il faut garder à l'esprit que le rouge n'indique uniquement que les infos venant du serveur ont été perdues, et non l'inverse. Ainsi, un drop du client au serveur peut exister même si la capacité d'upload du serveur est correcte, mais que sa capacité de download se trouve poussée à ses limites, et plus généralement, lorsque la capacité d'upload du client ne suit pas (en effet la plupart des connexions de particuliers sont très limitées en upload, alors que le download peut être très correct).
En conclusion, un netgraphe sur la machine serveur pourrait être d'un intérêt significatif pour dresser un tableau complet de la situation concernant les pertes de paquets client->server ou les connexions instables.
Aspects importants concernant le jeu
ut_timenudge
ut_timenudge (également connu dans UrT sous le nom de "local net buffer") retarde l'acheminement des informations de jeu vers le client pour rendre le jeu plus "régulier", plus "lisse". Cela consiste à créer une sorte de lag local pour faire en sorte que le jeu soit plus uniforme dans son affichage. D'où l'importance de savoir quand l'utiliser, quand ne pas l'utiliser, et quelle valeur pourrait être efficace.
Pour comprendre le fonctionnement de cette commande, vous devez savoir comment le jeu marche en ce qui concerne le partage d'informations entre le client et le serveur.
Le serveur et le client ont une "discussion" pendant le jeu, ils échangent ce qu'ils savent sur le déroulement de la partie. Les informations sont envoyées au client par le serveur toutes les 50 millisecondes (intervalle dû au ratio de 20 de sv_fps / snaps et 1000 ms (1 sec) / 20 = 50ms). Parallèlement, le client envoie ses propres infos et ses commandes (avancer, tirer...) au serveur selon le cl_maxpackets et les FPS, bien que cela n'ait qu'une petite influence sur l'utilisation du timenudge.
Si la ligne du dessus a des pics jaunes, cela signifie que le client n'a pas eu les informations attendues au moment prévu (plus de 50 ms depuis le dernier snapshot, rappelez-vous) et donc la "discussion" n'est pas aussi régulière qu'elle devrait l'être. Le jeu et le serveur doivent donc deviner ce qui se passe en se basant sur les dernières infos reçues (extrapolation). En mettant le timenudge par exemple à 30, le client attend 30ms de plus avant de retranscrire à l'écran ce qu'il sait à partir des nouvelles infos obtenues, dans l'espoir d'obtenir au final un rendu plus fidèle à la réalité et de rendre le jeu plus fluide, au cas où des informations un peu en retard finiraient par arriver.
Quand ut_timenudge est utilisé, la barre du haut sur le netgraphe devient plus épaisse. Visuellement, il devient plus dur de voir du jaune, car l'épaisseur de la barre va le couvrir plus facilement [(même si cela ne signifie pas pour autant qu'il n'y a pas d'extrapolation du tout.)]
Vous pouvez tester 10 ou 20 en valeur (comme proposé par le codeur du timenudge, TwentySeven), même si vous n'avez pas de problème apparent, au moins à court terme. Vous pouvez aller de 0 à 50 (les valeurs négatives ne sont pas acceptées par le jeu).
A bas niveau, ut_timenudge altère en fait les timestamps des paquets entrants pour faire croire qu'ils arrivent un peu plus tard. cl_timenudge présent auparavant sur les mods q3 permettait également de différer les paquets client->server, mais c'était un exploit qui pouvait être utilisé pour créer du warp artificiel, et UrT a supprimé cette variable.
Ce procédé ajoute donc du lag en local, et donc ce que vous aurez à l'écran sera une représentation un peu "en retard" par rapport à ce qui se passe réellement sur le serveur (disons encore plus tard que ce qui est normalement dû à une latence classique). Par conséquent, vous ne devriez pas jouer sur le timenudge si vous n'avez pas vraiment de pics jaunes, ou plus généralement, s'il n'y a pas de problème que le timenudge serait le seul à pouvoir régler. Ce qu'on pourrait appeler les "hits" peuvent s'améliorer en évitant l'extrapolation décrite ci-dessus.
L'antilag (voir ci-dessous) est pris en compte lorsque le timenudge altère les temps de perception de la réalité du jeu, son fonctionnement n'est donc pas perturbé.
Si vous n'avez que quelques pics jaunes épars, vous ne devriez probablement pas utiliser timenudge, car avoir un jeu un poil moins fluide toutes les 10 ou 20 secondes est toujours mieux qu'un lag local permanent.
L'antilag et les "delayed hits" (hits derrière un mur)
Le "code sans lag" ("unlagged code") (opéré par le serveur), également connu sous le nom d'antilag sous UrT, évite d'avoir besoin de prédire où une cible qui se fait tirer dessus "sera" pour compenser le lag (alors que c'était le cas au tout début d'UrT). L'antilag fonctionne de manière à garder une trace de "où et quand" un attaquant (celui qui fait feu) a vu une cible, en tenant compte de la latence naturelle du jeu.
Donc, quand un joueur avec un gros ping voit un joueur avec un faible ping, il le touchera toujours à l'endroit où il pensait viser, sans avoir à prédire où la cible "se trouvera" en tenant compte du lag (même si, en tenant compte du lag du tireur, l'enregistrement du tir (lorsque le serveur traitera l'info selon laquelle le joueur a appuyé sur fire) sera toujours plus tardive que s'il s'agissait du faible ping qui tirait).
L'effet collatéral est courant : un gros ping va effectivement pouvoir toucher le faible ping "dans le coin du mur", c'est-à-dire "derrière" en fait. Le petit ping pourra avoir été dans la ligne de mire du gros ping au moment où il se faisait tirer dessus, cependant en raison du lag plus important du gros ping, le joueur avec le gros ping a vu la scène se dérouler "plus tôt" que depuis la perspective du petit ping. Si vous voulez, dans le "temps réel" du petit ping, ce dernier a effectivement pu se cacher derrière un mur mais en fait le gros ping le voit toujours bien visible sur son écran (car il a un lag supplémentaire). Donc le gros ping va tirer, et c'est là que l'antilag va "l'aider", en lui permettant d'atteindre tout de même sa cible, en se basant sur ce que voit le gros ping (plutôt que de se fier à la réalité, en fait), ce qui va éviter de devoir tenir compte du lag tout simplement. Par conséquent, le petit ping va avoir l'impression de se faire tirer dessus alors qu'il est caché derrière un mur, et c'est bien ce qui se passe. (Ce phénomène est également présent lorsque ce sont deux gros pings qui se tirent dessus, mais c'est plus compliqué à décrire. On peut également considérer la perspective du gros ping qui se fait tirer dessus par un petit ping, ça marche également.)
Toutefois, le gros ping sera toujours handicapé par rapport au petit ping, car le gros ping voit toujours ce qui se passe sur le serveur un peu en retard par rapport au petit ping. Les plus petits pings auront toujours une longueur d'avance sur les autres.
On pourrait théoriquement contrebalancer ce petit effet collatéral en faisant en sort que le netcode ignore les infos de hits lorsque ce phénomène apparaît (peut-être que cela demanderait plus de ressources), donc je ne serais pas surpris si c'était le cas dans une version ultérieure du jeu.
Gardez à l'esprit cependant que dans un jeu où toutes les armes sont en "hitscan" (c'est-à-dire que le jeu fait abstraction totale des règles physiques élémentaires de balistisque : une balle dans la réalité a un véritable chemin à parcourir, chemin qui prend du temps et qui peut être dévié - le hitscan, qui est présent dans la quasi totalité des FPS, est le nom donné au fait que les armes touchent instantanément leurs cibles), comme UrT (quake3 avait seulement des railguns et des machineguns), l'antilag reste tout de même d'une grande importance pour un jeu plus fluide. Probablement la plus grande partie des faibles pings (50-60ms) eux-mêmes trouveraient les hits plus aléatoires s'il n'existait pas.
L'antilag ne peut pas être modifié, désactivé ou altéré, du moins "légalement", et c'est probablement mieux ainsi.
Note : Sachez également que le phénomène du "hit derrière les murs" peut avoir existé sans l'antilag, à cause du lag classique, mais il était alors beaucoup moins prononcé.
L'antiwarp
L'antiwarp est un système côté serveur également qui simplement rend les gens moins susceptibles de warper. C'est plus difficile de voir les warpers "en vrai" de nos jours. Souvent, ce n'est pas vraiment eux qui warpent, mais l'observateur qui a une connexion instable. Parfois, ils warpent réellement car l'admin du serveur n'a pas bien configuré l'antiwarp. Le warp apparaît lorsque le serveur ne reçoit pas les infos du joueur assez fréquemment (ping instable, pertes de paquets).
Si l'antiwarp agit sur vous, vous le verrez avec des lignes noires sur le netgraphe. Cela peut être l'indication que vous perdez des paquets en route, et cl_packetdup peut aider dans ce cas. Cependant, vous pouvez warper à cause d'un ping fou, et alors dupliquer les paquets ne sera d'aucune aide.
Reportez-vous à la section plus bas pour savoir comment configurer l'antiwarp côté serveur.
/rate
Le "rate" contrôle la densité du trafic entre le serveur et le client (combien de bytes par seconde il l'autorise à lui envoyer). C'est également limité par la variable serveur sv_maxrate et sv_minrate (par exemple si ces variables contiennent 20000 et 12000, vous serez vous-même limité entre ces 2 valeurs).
Ce n'est plus vraiment d'une importance capitale de nos jours depuis que le jeu utilise ce qu'on appelle la "compression delta" et qu'un client utilise facilement entre 4 et 8Ko/sec (même si on peut toujours assister à un certain engorgement dans les valeurs les plus basses, 8000 correspondant à 7.81Kb/s).
Ainsi, un rate très bas, disons à 8000 ou 10000 sur un serveur fréquente (16+) est souvent une source de jaune sur la ligne du dessus et du bas, ce qui nuit à la fluidité du jeu. Reportez-vous éventuellement à la partie consacrée à l'admin serveur pour plus d'infos.
Aujourd'hui garder cette valeur à 25000 ne devrait pas poser de problèmes pour la majorité des connexions avec une bande-passante correcte. Cela correspond à un taux (bytes / secondes) de 24.41Kb/s seulement (taux qui n'est même pas atteint dans la réalité la plupart du temps). Il y a eu une rumeur selon laquelle si le serveur mettait son maxrate en dessous de 25 000, c'était mieux de mettre également une valeur inférieure, mais on peut en douter fortement (parce que le serveur vérifiera toujours le taux du client pour l'ajuster dans sa propre fourchette).
Le réglage du taux est également important pour la VoIP dans les récentes versions de ioquake3 ; si jamais IoUrT inclut cette fonctionnalité dans une version ultérieure (a priori sera le cas dans la 4.2), il est conseillé de garder cette valeur assez haute, bien sûr toujours dans la limite acceptée par votre connexion.
La meilleure indication pour définir le meilleur /rate est la présence ou non de jaune sur la ligne du bas. S'il y a du jaune au lieu du vert, cela signifie que le client indique que son taux de transfert a été perturbé. Idéalement, pour une latence minimale et pour éviter le jaune sur la ligne du dessus, vous devriez éviter cela.
Bien sûr, même aujourd'hui où les besoins du moteur du jeu sont des cacahuètes pour la bande-passante des connexions modernes, n'oubliez pas qu'un taux important sur une connexion lente est pire qu'un taux plus réduit, car un taux réduit signifie tout au plus un jeu un peu instable, alors qu'un taux de transfert important pour une faible connexion va lui causer du lag majeur. C'est également d'une certaine importance car le lag peut venir du serveur ou même de n'importe où ailleurs à travers l'internet.
cl_maxpackets et les FPS
Ce que fait cl_maxpackets
A l'inverse de rate, cl_maxpackets définit la quantité maximale d'informations envoyées par le client au serveur, par seconde. Sous UrT, cette variable est bloquée entre 30 et 42. C'est en forte corrélation avec les FPS du client.
Important (et peut-être moins compréhensible)
Les FPS constituent un élément majeur du jeu, qui gouverne bien d'autres choses que les FPS. Ainsi, le client ne peut envoyer qu'une seule "update" à chaque frame, ou une toutes les 2 frames, ou une toutes les 3 frames... Ainsi, si vous êtes à 125 FPS, vous pouvez envoyer 125 updates par seconde au serveur, ou 62.5 par seconde, ou 41.7 par seconde, 31.25, 25... (les valeurs ne sont pas arrondies par le jeu). Si vous avez un drop 100 (ou si vous avez fixé vos FPS à 100), les valeurs seront diminuées proportionnellement : 100 infos par seconde, 50, 33.3, 25, 20...
- Ce que cela signifie
Donc, si vous avez un cl_maxpackets à 30 pour 125 FPS, le client enverra 25 updates par seconde. Si vous avez 100 FPS, il enverra encore 25 infos par seconde. Si vous avez un maxpackets à 42, il enverra 41.7 up par seconde pour 125 FPS (et en fait on comprend que 42, la valeur max autorisée par le jeu, correspond à la valeur la plus optimisée pour des FPS stables à 125), et enverra 33.3 up par seconde à 100 FPS.
Aidez-vous de vos maths et de votre logique pour calculer les autres cas.
Le principe de base ici est d'obtenir la latence la plus faible possible en envoyant le plus de paquets possible au serveur, par exemple en conservant une stabilité à 125 FPS. Pour 125 par exemple, il semblerait que 42 corresponde le mieux.
Un exemple de mauvais choix serait par exemple si vous limitez vos FPS à 60 dans le jeu, le client sera capable au choix d'envoyer 60, 30 ou 20 paquets par seconde au serveur. Cela signifie que le jeu ne sera pas capable d'utiliser au max un maxpackets à 42, mais seulement de 30. Similairement, avec 100 FPS, il pourra n'envoyer que 33.3 up par sec.
Peut-être que la limite de 42 sera levée dans le futur d'UrT (jusqu'à 125 ?), ce qui rendrait le jeu bien plus fluide.
- A savoir pour régler ses FPS max avec com_maxfps
Maintenant, lorsque vous définissez votre com_maxfps pour tenir compte des informations données ci-dessus, gardez à l'esprit que les FPS qui sont effectivement affichés à l'écran sont limités en valeurs de 1000ms divisés par un nombre entier, parce que le moteur du jeu calcule la durée des frames en utilisant des nombres entiers en millisecondes. Donc vous ne pouvez que mettre 125 FPS (1000/8), 111.11 (1000/9), 100, 90, 90.9, 83.3, 76.9, 71.4, 66.6, 62.5, 58.82, etc. (sans arrondir).
[Par exception, ne tenez pas compte de ceci lorsque vous avez la vsynch activée, car le rendu sera forcé pour correspondre à la fréquence du moniteur, en général de 60Hz).
En règle générale
Selon ce qui a été dit ci-dessus, on peut conclure sur le fait que dans l'intérêt d'une latence minimale, cl_maxpackets peut être laissé à 42 quels que soient vos FPS, sauf si vous avez vraiment besoin de limiter votre bande-passante (rare sur les connexions modernes). D'un autre côté - si vous pouvez vous le permettre - avoir 125 FPS max est une bonne chose pour une efficacité optimale, car cela correspond parfaitement à un taux de 42 paquets/seconde.
N'oubliez pas que si vous ne pouvez atteindre que 80 FPS, il peut être préférable d'avoir un com_maxfps à 80 et non à 125 car dans ce cas votre maxpackets atteindra 40 (pour les raisons mentionnées ci-dessus) au lieu d'une valeur plus basse, disons 90, où le max rate ne sera que de 30 (car 90/3 = 30 mais 90/2 = 45). Cependant, cette conclusion peut être mensongère dans la mesure où un ordinateur moyen peut facilement atteindre les 90, et que de manière évidente (complexité du jeu, selon la map, le type de jeu, le nombre de joueurs, etc), la valeur réelle pourra fluctuer autour de 90, et les calculs ne seront que partiellement inapplicables.
1000 / nombre entier / nombre entier
La relation peut être résumée ainsi : FPS = 1000 / nombre entier ; paquets par seconde envoyés au serveur = 1000 / nombre entier(FPS) / nombre entier.
Un arrondissement interne pas très logique
Le plafond de la variable est arrondi en interne de manière assez illogique : com_maxfps à 84 va jusqu'à 90.090... alors que 83 reste sur 83.333...
C'est-à-dire qu'un com_maxfps à 84 donne effectivement 30.30.. paquets par seconde parce que les FPS seront vraiment mis au max à 90.090, alors que la valeur correcte pour arriver à 41.666 serait plutôt 83, alors que c'est ce que nous voulons pour une latence minime avec le plafond disponible de cl_maxpackets.
cl_packetdup
cl_packetdup duplique les informations envoyées par le client au serveur afin d'augmenter la probabilité que les infos arrivent bien (un paquet droppé sera remplacé par le suivant). La valeur peut être de 1, 2 ou 3 selon le nombre de paquets identiques qui seront envoyés.
Activer cette fonction est bien plus important qu'il n'y paraît, car si le netgraphe est plutôt généreux en ce qui concerne les infos server->client, en revanche il est totalement muet concernant le chemin inverse. Ainsi, vous pouvez être confronté à un jeu instable alors que votre netgraphe semble correct. Bien sûr, si vous êtes confiants concernant les paquets envoyés (vous êtes sûr qu'ils arrivent tous à bon port), vous pouvez vous permettre de désactiver cl_packetdup afin d'arriver à une "latence absolument minime".
Comme on l'a déjà dit, des lignes rouges dans le netgraphe ne signifient PAS que le cl_packetdup sera obligatoirement utile. Les lignes rouges indiquent une perte de paquet du client au serveur, ce qui n'est pas le sens du chemin où cl_packetdup agit. Cependant, s'il s'agit de la même cause qui produit des pertes de paquets dans les deux sens, alors dupliquer les paquets pourra toujours améliorer la transition entre le client et le serveur (par exemple un matériel défectueux entre le client et le serveur).
De la même façon, des lignes noires indiquent que vous êtes victime de l'antiwarp côté serveur, et cela indique indirectement qu'il y a des pertes de paquets entre vous et le serveur et encore une fois dupliquer vos paquets pourra réduire le warp (même si, on l'a vu, le problème peut aussi venir d'un ping instable).
Modifié en dernier par Tizz le 10 févr. 2010, 08:15, modifié 5 fois.
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Pour les administrateurs de serveur
Les bases
Essayer d'éviter l'engorgement du CPU, du réseaux et des autres ressources est supposé être un but global.
Ne croyez pas tout de suite un quidam qui va vous dire que votre serveur "sucks". Internet est une structure extrêmement complexe et le problème peut venir de n'importe où entre le client et le serveur : le client lui-même, le serveur, le FAI de l'un des deux, le FAI du FAI du serveur, un modem au milieu de nulle part, un antivirus, etc. De la même façon, des joueurs issus d'un certain pays pourront avoir une excellente connexion avec un serveur en particulier, et pas avec d'autres (même s'ils sont plus proches géographiquement), et vice versa. Parfois des joueurs d'une université laggent avec le serveur de leur propre université, et pas avec le reste du monde.
Le netgraphe côté client tel qu'expliqué plus haut, est ici bien sûr vital pour diagnostiquer certains problèmes. Après tout, le jeu est conçu pour le joueur avant tout.
L'antiwarp
Il y a deux variables :
g_antiwarp à 1 l'active.
g_antiwarptol définit l'intervalle "de tolérance" (par défaut à 50). Ainsi, une valeur à 70 va permettre aux joueurs de fluctuer jusqu'à un retard de 70ms après quoi ils seront victimes de l'antiwarp. Un antiwarp à 30 va infliger de l'antiwarp de manière beaucoup plus stricte, tant que la fluctuation est égale ou supérieure à 30.
[Une valeur à 50 semble être idéale si on s'en tient à la relation sv_fps/snaps à 20, ce qui signifie que les updates par le serveur sont envoyées toutes les 50ms (1 sec = 1000ms/20).]
[On peut présumer qu'une valeur inutilement trop basse va entraîner une surcharge du CPU car l'antiwarp va alors concerner beaucoup plus de joueurs.]
[On peut également présumer que l'antilag concerne également les joueurs qui font l'objet de l'antiwarp.]
Une valeur inutilement trop haute va potentiellement manquer les warpeurs "moyens" qui vont donc continuer de warper.
Bref, si vous ne savez pas trop quoi mettre, gardez 50.
Prendre soin de son upload
sv_maxrate et les problèmes du rate
Comme mentionné plus haut dans la section consacrée au /rate, cette variable permet de limiter le rate à une certaine valeur de bytes par seconde pour n'importe quel client (serveur->client). Cependant, depuis l'introduction de la compression delta dans les jeux basés sur q3, la valeur max de 25000 (24.41Kb/s) n'est jamais atteinte dans une situation normale de jeu. L'envoi de snapshots est généralement fait à 4 ou 8Kb/s pour chaque client même avec les réglages maximum. Ceci cependant peut ne pas inclure certains emcombrements dus à la valeur la plus basse possible du /rate à 8000 (7.81Kb/s), et parfois même à 10000 ou 12000.
A cause des effets de la limitation de la bande-passante, des valeurs comme 10000-12000 ou moins sur des serveurs fréquentés doivent être évitées. Jetez un coup d'oeil sur le test mené plus bas pour plus de détails.
Au cas où ioUrT embarque la future VoIP d'ioquake3, cette variable limitera également la bande-passante utilisée par cette fonctionnalité.
Un indicateur intéressant du bon usage des limitations de taux est l'état de la ligne du bas sur le netgraphe des joueurs. S'il y a du jaune au lieu du vert, cela signifie que le taux a été bridé. Ce n'est pas nécessairement mauvais, c'est même plutôt bon si votre bande-passante a effectivement besoin d'être limitée. Mais vous pouvez aussi vouloir réduire la latence et potentiellement éviter le jaune qui sera généra sur la ligne du dessus, et cela passera par l'augmentation du maxrate côté serveur.
Pour rappel, le jaune sur la ligne du dessus sera souvent en corrélation avec le jaune en bas, car la suppression d'informations destinée à préserver la bande-passante va obliger le jeu à extrapoler (et donc un jeu plus aléatoire comme on l'a vu).
Gardez à l'esprit qu'un taux plutôt bas pour le client est préférable à un taux plutôt élevé qui va provoquer une surcharge du CPU. Un taux bas va simplement créer un jeu un peu moins fidèle et aléatoire, alors qu'une surcharge CPU va carrément saturer les connexions et ainsi provoquer des lags importants (ainsi que des lignes rouges sur le netgraphe).
Si les clients ont du rouge sur leur netgraphe (des snaps d'infos sautés depuis le serveur), une raisons sous-jacente peut être une connexion entre le client et le serveur qui se trouve saturée. Donc un sv_maxrate réduit peut aider. Cependant, il peut y avoir d'autres sources de saturation entre les machines impliquées dans le processus.
La variable sv_minrate va forcer elle un taux minimum chez les clients, même si parfois le client peut avoir besoin d'un taux plus réduit que celui du serveur (s'il a une bande-passante vraiment limitée).
sv_minrate et sv_maxrate ne vont pas changer la variable retournée par le rate d'un client lorsque vous ferez /rcon status. Ces variables ne font que relever le rate du client, le comparer à celui du serveur et le forcer à un taux différent selon sv_maxrate et sv_minrate.
Si vous avez un sv_maxrate à 0, comme par défaut, cela équivaut à 25000. S'il n'y a pas de lignes rouges et si votre bande-passante se porte bien, alors laissez ainsi à la valeur maximale.
Nombre de clients
En relation directe avec sv_maxrate, le nombre de clients est important simplement pour calculer la bande-passante montante délivrée par le serveur et pour éviter la saturation de cette bande-passante ainsi que pour limiter les besoins du CPU. De plus, les développeurs du jeu (comme BladeKiller) ont démontré l'importance de ne pas dépasser le nombre de joueurs recommandé. Cela a également un effet sur la charge pesant sur les clients : un serveur va peut-être tenir le coup, mais est-ce que ce sera le cas également pour tous les joueurs ?
Besoins limités pour la bande-passante et surcharges
C'est simplement logique que la capacité requise en upload ne soit pas uniquement une question de nombre de clients et de sv_maxrate. En effet, 1) le jeu peut simplement ne pas avoir besoin d'utiliser complètement le maxrate et envoyer moins d'infos, 2) les connexions UDP utilisées pour le transfert des données peuvent avoir des surcharges, ce qui va augmenter la bande-passante utilisée.
Les besoins de download du serveur sont affectés par les valeurs du cl_maxpackets et des FPS affichés de tous les clients, même si cependant, il n'y a pas grand-chose que le serveur puisse faire pour limiter ou augmenter la réception de ceux-ci.
Surcharge du processeur (côté serveur)
C'est une raison courante de lag sur le serveur, un serveur de jeu pouvant demander pas mal de travail au CPU (comme quand par exemple il y a plusieurs serveurs sur la même machine). [Dans un tel cas, le client peut voir sur son netgraphe beaucoup de jaune sur le dessus de son netgraphe, ce qui signifie que le serveur n'a pas été capable de lui envoyer les snapshots à temps (sur la base de 20 snaps/seconde).] Le serveur peut être soulagé en donnant une priorité plus haute au processus sur le CPU, ou simplement en réduisant le nombre de programmes qui tournent. [Il peut être préférable d'éviter d'être constamment à 100% du CPU même avec des priorités de processus redéfinies, car l'OS sera toujours en mesure de redonner la priorité à certains processus vitaux s'il en a besoin.] C'est pourquoi faire tourner un serveur sur un ordinateur qui fait déjà tourner le client (qui est très gourmand en ressources) peut être problématique (même si de nos jours avec les processuers multicoeurs, ça peut tourner sans problème).
Exemple test : éviter un sv_maxrate inutilement bas
Il sera ici démontré que, si possible, un admin serveur devrait utiliser le sv_maxrate maximum, disons plus de 12000-15000 sur un serveur fréquenté par 16 joueurs et plus.
Le test montre qu'avec un taux bas, comme 8000, sur un serveur fréquenté par plus de 16 joueurs, le netgraphe ressemble à ceci :
Comme on l'a vu, le jaune sur la ligne du bas signifie que votre sv_maxrate (ou le /rate du joueur) a forcé l'info venant du serveur à arriver plus tard pour sauvegarder la bande-passante, mais qu'en contrepartie il y a donc du jaune sur la partie supérieure du netgraphe, car le client n'a pas assez d'informations pour dresser une représentation fidèle de ce qui se passe sur le serveur (extrapolation).
Plus grossièrement :
Bien sûr, n'augmentez pas votre sv_maxrate jusqu'à saturer votre connexion, car c'est encore pire pour les joueurs (lignes rouges) et cela ne signifie pas nécessairement que le serveur enverra des snapshots retardés [et ainsi ne perturbera pas la mémoire tampon de la compression delta], comme cela arrive avec la "suppression" d'infos pour la sauvegarde de la bande-passante grâce au sv_maxrate.
Un autre test :
Un serveur public très fréquenté (plus de 20 joueurs) avec un sv_maxrate à 25000 :
La même situation avec un rate à 8000 :
Vous pouvez également forcer un rate minimal avec sv_minrate, même si cela pourra causer quelques soucis aux joueurs qui ont réellement besoin de préserver leur bande-passante, mais de nos jours les connexions modernes tiennent largement le coup.
Autres aspects utiles / FAQ
Réseau
Quels sont les facteurs de base qui affectent le ping ?
Le ping est principalement déterminé par la distance qui vous sépare du serveur, et ensuite par le matériel qui va se trouver entre les deux, sans compter sur un bug ou la surcharge du serveur. Quand je dis "distance", cela tient compte du fait que la distance peut être du point de vue "réseau" aussi bien que d'un point de vue purement géographique, même s'il s'agit d'un facteur secondaire (et ceci ne constitue que la base de ce que l'on peut savoir sur le complexe cheminement d'internet).
Une partie seulement du chemin peut être saturée, ce qui arrive souvent ; vous pouvez faire quelques tests avec la fameuse commande traceroute.
Méthodes qui peuvent améliorer le ping
Le premier truc à faire serait évidemment de changer de serveur, vu que votre ping est principalement affecté par la distance géographique et par l'état du réseau entre vous et le serveur. Je dirais également d'éviter d'avoir une connexion saturée à tout prix. Sinon :
Gestion du trafic :
Vous pouvez ainsi donner une plus grande priorité aux paquets UDP (l'UDP est exclusivement utilisé par quake3, le TCP n'entre pas du tout en jeu), ou arriver au même résultat en donnant la priorité à certains ports ou adresses. Cependant il y a de fortes chances que vous ne voyiez la différence que dans le cas d'une connexion particulièrement sollicitée, et qui a donc potentiellement déjà des problèmes de surcharge. Une telle gestion de votre trafic peut être possible grâce à certaines cartes réseau à destination des gamers, même si encore une fois cela peut n'avoir d'intérêt que pour les connexions qui rament déjà un peu à la base.
Le système d'exploitation et réglage de pilote
Le trafic de paquets UDP peut être amélioré en bidouillant certains paramètres réseaux dans votre OS ou par le pilote de votre matériel. Cependant, ne jouez pas à l'apprenti sorcier en changeant quelque chose si vous ne savez pas vraiment ce que vous faites. D'autres choses peuvent se révéler totalement inutile : ainsi il y a beaucoup de programmes qui se proposent d'agir sur les connexions TCP, alors qu'UrT n'utilise QUE l'UDP !
Pilotes améliorés, et améliorations logicielles en général
Vous pouvez essayer d'upgrader votre OS ou vos pilotes (nouvelle version du kernel linux ou nouvelle version windows). Bien sûr, cela ne doit pas signifier de nouveaux bugs dans l'autre sens. En général, évitez les versions beta ou alpha.
Optimisation de votre réseau sans-fil
Un outil de diagnostic intéressant est celui qui scanne pour détecter les signaux qui peuvent interférer. Les autres signaux doivent idéalement être éloignés d'au moins 5 canaux pour ne pas interférer avec votre propre signal. Parfois des signaux faibles sur le même canal, ou du matériel vraiment très proches de votre antenne peuvent pas apparaître. Pour cela, essayez de changer de canal ou d'éteindre votre carte pour un court instant.
Le signal doit être aussi fort que possible (60% est suffisant par exemple). Si vous êtes trop loin de votre point d'accès, essayez de les rapprocher, ou d'utiliser des antennes intermédiaires ou ajuster leur position. Un pilote plus récent ou un firmware plus récent pour le routeur peut aider.
Instabilité du ping sur un ping faible ? C'est possible ?
L'instabilité du ping peut exister même sur des pings très faibles (surtout si vous avez saturé votre connexion avec votre FAI, comme lorsque vous téléchargez quelque chose pendant que vous jouez), ce qui signifie également que vous pouvez avoir un ping élevé mais stable (même si en général les gros pings sont ceux victimes d'instabilité).
Quel genre de fluctuation est dangereux ?
[Si vous dépassez la limite de 50ms dans la réception du snapshot du serveur et qu'il y a de l'extrapolation (pics jaunes), mais c'est possible également à moins de 50ms, mais beaucoup moins fréquemment. Egalement le ping peut avoir à monter au "mauvais" moment pour que les effets négatifs se produisent. C'est lié à l'échange périodique d'information entre le serveur et le client (dans l'intervalle de 50ms).]
Est-ce que les joueurs avec un gros ping sont avantagés ?
Non, très généralement. C'est parce que les gros pings voient toujours le jeu plus tard que les petits pings (même avec l'antilag). Les faibles pings ont toujours un avantage dans les situations de 1o1, tout simplement parce qu'ils tirent en premier selon le jeu (dans le scénarion hypothétique où deux joueurs tirent exactement au même moment dans le monde réel).
Un argument qui pourrait jouer sur le fait de ne pas laisser les gros pings jouer (d'un point de vue purement technique, je ne veux pas entrer dans les politiques internationales), est que le gros ping et les modifications artificielles de l'antilag rendent le jeu un peut "surréel" (dans le sens négatif du mot). Ainsi vous vous attendriez à ce que quelqu'un réagisse d'une certaine façon (en général comme vous vous réagiriez de manière instinctive), mais avec le délai du gros ping et l'action de l'antiwarp, vous vous direz que quelque chose a l'air bizarre (c'est percevable avec tous les pings mais bien évidemment beaucoup plus avec un gros ping). (Cela peut être en soi un avantage, pour le gros ping comme pour les autres). Ceci est aggravé par l'action de l'antilag comme on l'a vu ci-dessus.
Mais cela peut être accentué par la rumeur selon laquelle tous les gros pings ont un avantage par défaut, purement sur la base du ping, du moins à partir d'un certain point. C'est faux. Sur la base de la latence uniquement, les faibles pings sont indéniablement les gagnants.
"Pourquoi est-ce que je meurs toujours plus rapidement avec mon gros ping, alors qu'il y a de l'antilag et de l'antiwarp ?"
Vous mourrez plus sur des serveurs où vous avez un plus gros ping même avec de l'antilag, car vous apparaissez toujours plus rapidement sur l'écran de l'adversaire que lui n'apparaît sur le vôtre. C'est aussi simple que ça.
"Le timenudge n'est-il pas utilisé uniquement pour augmenter le ping ?"
Non. C'est un effet collatéral (voir détails plus haut). Si c'était le seul intérêt, les développeurs seraient fous de l'avoir inclu dans le jeu... En fait, cela n'augmenter même pas le ping, mais ajoute simplement un lag supplémentaire en interne dans la manière dont le jeu va percevoir ce qui se passe sur le serveur.
"Comment je peux devenir unhit ?" (en réglant mes paramètres réseaux)
Les gens "unhits" sont en général seulement ceux qui savent se déplacer.
Vous pouvez en théorie "bouleverser" votre connexion avec le serveur pour warper mais ça ne serait utile que sur les serveurs sans antiwarping, et même ainsi, le warper ne serait pas non plus capable de toucher quoi que ce soit, car lui-même n'aurait pas une vision parfaite de ce qui se passe autour de lui. Sur la plupart des serveurs l'antiwarp va éviter de tels exploits.
"J'ai de très rares traces jaunes sur ma ligne du dessus, est-ce que je dois utiliser ut_timenudge ?"
Probablement pas. La raison est que le lag que crée ut_timenudge est un handicap significatif (surtout au-dessus de 20) par rapport au simple fait d'avoir une extrapolation toutes les 10 ou 20 secondes. C'est surtout visible dans un jeu entre joueurs de même skill, où le plus petit lag peut avoir de grandes conséquences.
"Mon netgraphe est parfait. Est-ce que c'est toujours possible que ça soit la faute du serveur si je ne hit pas correctement ?"
La plupart du temps, les problèmes de hits sont juste liés au joueur qui en fait ne vise pas bien ou qui n'arrive pas à gérer la précision de son arme. C'est naturel, c'est un jeu complexe sur ce point, surtout si vous jouez contre des joueurs très expérimentés (et qui souvent savent bouger et devenir "unhit" de manière tout à fait légitime). Je ne crois pas que ce soit le bon endroit pour parler de "comment devenir un meilleur joueur", donc je ne rentrerai pas dans le débat. Mais je ne pense pas qu'avec un netgraphe clair on puisse rejeter la faute sur le serveur. Bien sûr, on ne peut jamais être à 100% sûr. Un antiwarp mal configuré ou un warp général peut être une source de hits irréguliers, même si le netgraphe a l'air bon, car le warp peut être causé par l'instabilité de la connexion d'un autre joueur, et non de l'observateur. Cependant même avec ça, le warp devrait être visible, et lorsque l'ennemi est dans votre ligne de mire, un warp avant ou après ne devrait pas être une raison pour le rater.
"Est-ce que ça peut être la faute du client si j'ai des problèmes de hits même avec un netgraphe clair ?"
C'est bien possible en fait, en tout cas bien plus que la faute du serveur. C'est parce que le netgraphe indique l'état du signal entre le serveur et vous, et non pas l'inverse (dont le taux est défini par cl_maxpackets et par les FPS). Par conséquent, cl_packetdup est toujours un bon moyen de résoudre la situation (à désactiver cependant si vous êtes absolument sûr que vos paquets voyagent bien).
Un lag matériel, comme un moniteur de connexion, la fréquence de l'écran, le temps de réponse de votre écran, la vsynch, ou même un lag de votre souris, peuvent être une source de problèmes de hits avec un netgraphe plat, même si vous ne percevez pas ces lags réellement.
"Pourquoi doit-on limiter la bande-passante plutôt que de simplement sauter quelques snapshots dans une connexion saturée ?"
[Comme la limitation de la bande-passante avec sv_maxrate et rate crée déjà un retard des informations envoyées par le serveur (ainsi que les effets collatéraux comme le jaune sur la ligne du dessus), on pourrait penser qu'il serait plus sensé de simplement laisser le serveur envoyer autant d'informations qu'il le peut, sans se soucier de l'éventuelle saturation, parce qu'avec une véritable limitation il y a déjà une certaine perturbation du jeu. Cependant, ce n'est pas le cas car avec des paquets droppés la mémoire tampon de la compression delta est aussi perturbée. Dans le même temps, mais s'il n'y a pas eu de telles perturbations, ne pas tenir compte périodiquement de certaines informations grâce à la limitation permet d'augmenter les chances d'une transmission plus régulière entre le serveur et le client. Ensuite, c'est plus sûr pour un servadmin qui souhaite garder la main sur sa bande-passante.]
Est-ce que les paquets client->serveur sont plus gros avec des FPS plus importants même avec un certain cl_maxpackets ?
[Oui, parce qu'ils contiennent des informations qui viennent de plus de frames. Cela signifie qu'il faut penser aux FPS lorsque l'on songe à prévenir la saturation de sa bande-passante.]
Traceroute - Déterminer la qualité de son réeau
Des outils tels que traceroute (tracert sous Windows) sont souvent utilisés par des spécialistes du réseau pour évaluer la qualité d'un réseau ; cela peut être également utile pour le gaming parce que vous pouvez savoir ainsi si un problème se situe sur un point particulier entre vous et le serveur. Par exemple, si vous remarquez que seul le 4ème noeud est le seul à générer des pics rouges, cela peut être la raison de l'instabilité et vous saurez ainsi que le problème ne vient pas de votre ordinateur. Il pourra alors être opportun de changer d'IP (ce qui va faire changer la route pour certains FAI), ou utiliser un FAI différent ou un serveur différent...
Changer d'IP peut aider
Cela peut vous sauver la vie ; certains FAI routent votre connexion différemment si vous changez simplement d'IP (avec une IP dynamique), ce qui peut être fait généralement en se reconnectant simplement. Cela signifie que les problèmes avec le réseau peuvent être réglés (ou apparaître) simplement en changeant d'IP.
Graphique / Visuel
Est-ce vrai qu'avec 60Hz, je dois avoir 60 FPS pour une latence optimale ?
C'est une idée fausse de croire qu'avec un moniteur réglé sur 60Hz, vous devez avoir 60 FPS sur le jeu pour avoir une bonne latence. En effet, alors alors que théoriquement le moniteur "interroge" la carte graphique 60 fois par seconde, il y a toujours une probabilité d'obtenir une latence visuelle plus basse si les FPS sont plus importants. Par exemple sur du 60Hz avec 125 FPS, il est fort possible (pas obligatoirement donc) d'avoir la meilleure latence visuelle de 1000/60 - 1000/125 msec. Le résultat sera d'environ 8.7 millisecondes.
Maintenant, un problème souvent lié - bien que pas lié directement à la latence - est le phénomène de "l'image tearing" ou "déchirement d'image". C'est un phénomène assez pénible qui apparaît lorsque le moniteur rafraîchit l'écran alors que l'image envoyée par la carte graphique est en fait contenue dans plusieurs frames (plus d'une au moins), en général en dessous de 70Hz. Pour éviter cela, on peut recourir à la vsynch pour bloquer ses FPS à 60 à 60Hz par exemple. Mais cela reste complètement différent de bloquer "manuellement" ses FPS à 60 avec com_maxfps 60, cela déchirera l'image dans ce cas et sûrement de manière encore plus importante, car au moins avec plus de FPS, votre image est "plus déchirée" et cela se voit moins que si l'image est contenue sur 2 frames seulement. De plus, la vsynch occasionne un lag sur la machine (en local), et vous devriez éviter de l'activer, sauf si vous privilégiez la qualité visuelle au détriment des performances. On pourrait répondre à cela que la beauté de l'image peut également améliorer son gameplay ; tout est histoire de compromis.
D'un autre côté, cl_maxpackets, le taux de transfert de paquets du client vers le serveur, est lui aussi affecté par les FPS. C'est-à-dire qu'à 60 FPS, vous ne pouvez avoir en réalité que 30 paquets par seconde envoyés par votre client au serveur, alors qu'à 125 FPS vous montez à 42, ce qui signifie qu'à 125 FPS la latence sera meilleure d'un point de vue purement réseau (au-delà de l'avantage visuel).
La synchronisation verticale (vsynch) en relation avec la latence
La vsynch ajoute un lag interne sur ce qui est montré au joueur sur son écran. Vous devriez donc l'éviter si vous n'en avez pas besoin. Cependant, la vsynch peut être nécessaire (au moins par préférence personnelle) pour certains joueurs qui sont confrontés à de l'image tearing avec leur écran qui tourne sur une basse fréquence (en dessous de 60Hz). L'image tearing peut également apparaître sur certaines configurations SLI.
Autres aspects du moniteur
On peut essayer d'avoir la plus haute fréquence verticale avec un CRT, et le meilleur taux de réponse et la meilleure fréquence avec un LCD. Le mieux est d'essayer d'avoir une fréquence verticale (pour les CRT) ou une fréquence (pour les LCD) à 70Hz ou mieux, et un temps de réponse à 10ms est préférable.
Améliorer et stabiliser vos FPS
Avoir des FPS stables est très important pour plusieurs raisons. En effet, au-delà de l'avantage majeur d'avoir un jeu fluide, il est important d'établir une certaine cohérence entre vos FPS et votre cl_maxpackets afin d'optimiser la latence de vos paquets entre vous et le serveur.
Pour améliorer vos FPS, on peut bien sûr mentionner brièvement tout ce qui au niveau des règlages graphiques rend le jeu un peu plus "moche" mais qui vous donnera quelques FPS supplémentaires (résolution plus basse, antialiasing désactivé, qualité de texture plus basse, filtrage anisotrope désactivé principalement). Si je devais détailler précisément toutes ces méthodes, je dépasserais probablement l'objet de ce guide, mais il y a beaucoup de ressources à ce propos sur Urban Terror. Regardez surtout la FAQ du jeu (très utile).
Sachez également les serveurs où il y a moins d'action (moins de joueurs) sont moins exigeants vis à vis de votre carte vidéo.
Enfin n'oubliez pas qu'un ordinateur suffisamment moderne peut largement faire tourner UrT à n'importe quels FPS, sans besoin pour vous de sacrifier la qualité visuelle du jeu.
Est-ce que la latence est plus faible avec des FPS plus importants même s'ils sont plus importants que la fréquence du moniteur ?
[Il peut y avoir une latence visuelle plus faible avec des FPS plus importants, par exemple comme on l'a vu à un maximum de 1000/60 - 1000/25 = 8.7msec, si vous avez 125 FPS et 60Hz).
Est-ce que j'aurais moins d'image tearing avec des FPS plus importants ?
[On pourrait supposer que des plus gros FPS aggravent le phénomène d'image tearing car dans un "déchirement" vous aurez les fragments d'images issus de plus de frame. Cependant, avec 60Hz est la vsynch activée, l'image tearing sera plus visible qu'avec 125 FPS sur du 60HZ, pour la raison que si le déchirement est plus important, il est cependant compensé par une fluidité plus importante de l'image grâce à plus de FPS.]
Est-ce vrai que l'œil humain ne peut distinguer qu'un certain nombre de FPS ?
L'œil humain et le cerveau sont des éléments organiques, ils ne fonctionnenet pas en termes de FPS ou d'Hz. On peut simplement faire des tests pour tenter de déterminer ce qu'un individu peut distinguer. Un individu moyen peut faire la différence entre deux valeurs de FPS dans un jeu, grâce à son expérience du gaming, mais cela s'arrête là. D'autant plus que cela dépend de la qualité de l'image, l'état d'esprit de la personne (fatigue...).
Des tests ont démontré que des pilotes de l'armée américaine pouvait distinguer le modèle d'un avion qui leur était montré à 1/220e seconde. Cependant, cela ne prouve pas que l'œil humain est capable de voir la différence dans les FPS dans toutes les situations car il y a beaucoup d'autres facteurs qui entrent en jeu (l'individu lui-même, son état de fatigue, et tout le côté matériel de l'ordinateur).
Concernant la souris et le clavier
/in_mouse sur les clients Windows
[Essayez de garder cette variable à -1 (API basique Windows), car 1 va utiliser DirectInput et augmenter le temps de réponse de la souris de 12ms.]
Autres réglages de la souris possibles
Voyez si vous pouvez augmenter le taux de réponse et les DPI de votre souris. Au besoin, faites quelques recherches sur Google selon le modèle que vous avez. Le taux de réponse (polling rate) est probablement plus important que les DPI concernant la latence, par exemple 1000Hz signifie un temps de réponse de votre souris de 1ms, mais à 125Hz par exemple, le temps sera de 8ms ! (1000ms/1000 contre 1000ms/125).
Pourquoi est-ce que je ne peux pas appuyer sur plus de 3 ou 4 touches en même temps sur mon clavier ?
C'est une limitation matérielle qui vient de votre clavier lui-même. Vous devez alors essayer d'autres combinaisons de touches qui peuvent marcher. Sinon, vous devrez vous orienter vers un clavier plus haut de gamme (essayez-même avant de les acheter ou renseignez-vous).
/r_finish
[Cela améliore le taux de réponse de votre souris / clavier au moins lorsque vous avez la vsynch activée.] Cependant cela diminue les FPS alors vous devriez éviter si vous n'en avez pas besoin (surtout si vous n'utilisez pas la vysnch).
Autres aspects liés au moteur du jeu
"Prendre une démo dégrade mes hits"
En fait, si vous avez l'impression que les hits ne sont pas bons (par rapport au jeu lorsque vous êtiez en train de jouer), c'est parce que les démos n'enregistrent pas très fidèlement ce qui s'est passé. C'est même pire avec g_synchronousclients à 1 pendant que vous enregistré (car cela force le jeu à attendre les infos de tous les clients avant d'enregistrer le mouvement), et vous pourriez avoir un lag si vous jouez avec cette variable activée.
sv_fps/snaps bloqués à 20, cl_maxpackets
Cela peut être une explication en soi pour les informations contenues plus haut, mais avoir le sv_fps du serveur et le snaps du clients bloqués sur 20 signifie que le serveur envoie une info au client toutes les 50ms (1 sec = 1000ms / 20 = 50ms) mais en retour cela signifie aussi qu'il y a donc un lag considérable implémenté directement dans le jeu. C'est logique de supposer que si on pouvait augmenter le sv_fps et le snaps cela réduira considérablement la latence dans le jeu. Mais cela nécessiterait également plus de ressources.
Variables de prédiction
Voici les variables qui commandent la prédiction côté client
- cg_smoothclients : si désactivée (0), le client attend que le serveur détermine la position des autres joueurs.
- cg_predictitems : similairement, à 0 le client attend que le serveur détermine l'état des objets à terre.
- (cg_nopredict : Vous ne devriez jamais mettre cette variable à 1 car cela rend le jeu très instable. Sauf si vous savez ce que vous faites.)
Vous pouvez essayer les deux premières variables à 1, mais "0" est plus "réel". Mais en même temps, devoir attendre le serveur nuit forcément quelque part à la fluidité du jeu. Vous pourriez vouloir tester.
"Est-ce que la valeur de sv_fps/snaps doit être prise en compte pour déterminer le bon cl_maxpackets ?"
[Apparemment non, même si certains sites suggèrent qu'il y a un lien. C'est parce que selon le code du jeu, la réception d'instructions ne semble pas correspondre ou du moins être en corrélation directe avec l'envoi des snapshots par le serveur.]
"Ai-je besoin de 125 FPS pour jumper ?"
Cela n'a plus d'importance, cela n'était le cas que pour les anciennes versions de Q3. Avec cg_physics sur 1 (par défaut), n'importe quels FPS donnent le même résultat au niveau des physics du jeu.
La forte corrélation entre les FPS et le réseau et la manière dont cela fonctionne en général
Vous devriez toujours garder à l'esprit que les FPS ne gouvernent pas seulement les graphismes (juste la latence visuelle), même si c'est leur but premier. Les FPS sont très liés à la manière dont fonctionne le moteur du jeu. Par exemple, s'il n'y a aucun FPS, aucune frame à afficher, il n'y a pas d'informations à envoyer au serveur par le client.
Ping, FPS, snaps, etc. Compteurs de variation et drop/pics de FPS
Cette rebuild du moteur vous permet d'afficher des outils réseaux et de mesure qui peuvent être utiles pour évaluer votre réseau, vos FPS et la stabilité de votre jeu.
"Les FPS sont le lag"
Quand je dis cela, c'est parce que les FPS sont un facteur premier du fonctionnement du moteur, et pas seulement un indicateur de nombre d'images ou de qualité comme indiqué ci-dessus, ou même uniquement un moyen de mesurer la latence visuelle. Les FPS sont également déterminés par toutes les opérations réalisées par le moteur du jeu. Donc si vos FPS sont mis sur 125, il y a forcément un lag local de 8 ms pour envoyer les informations au serveur. Ce n'est pas par hasard si le taux de transfert d'infos du serveur au client est géré par une variable qui s'appelle sv_fps.
Sources
- Les forums Urban Terror.net et les commentaires, surtout ceux des devs.
- F3quake's et sa super base de connaissance concernant les cvars.
- Dur's Quake III Arena et ses précieuses indications concernant le lagometer et les remarques de Carmack.
- Upset Chaps La très vieille référence de q3 sur la plupart des cvars
- Vsyn Study Les opinions sur la vsynch par plusieurs concepteurs de jeu.
- Internal Paper on Image Tearing and Vsynch Un point précis sur l'image tearing et sa prévention.
- Le sens commun
- Le sens pas commun
- Le code source de q3, parce que si ça n'existe pas ici, alors ça n'existe pas du tout.
- #ioquake3 sur freenode
- Les remarques de Carmack
Les bases
Essayer d'éviter l'engorgement du CPU, du réseaux et des autres ressources est supposé être un but global.
Ne croyez pas tout de suite un quidam qui va vous dire que votre serveur "sucks". Internet est une structure extrêmement complexe et le problème peut venir de n'importe où entre le client et le serveur : le client lui-même, le serveur, le FAI de l'un des deux, le FAI du FAI du serveur, un modem au milieu de nulle part, un antivirus, etc. De la même façon, des joueurs issus d'un certain pays pourront avoir une excellente connexion avec un serveur en particulier, et pas avec d'autres (même s'ils sont plus proches géographiquement), et vice versa. Parfois des joueurs d'une université laggent avec le serveur de leur propre université, et pas avec le reste du monde.
Le netgraphe côté client tel qu'expliqué plus haut, est ici bien sûr vital pour diagnostiquer certains problèmes. Après tout, le jeu est conçu pour le joueur avant tout.
L'antiwarp
Il y a deux variables :
g_antiwarp à 1 l'active.
g_antiwarptol définit l'intervalle "de tolérance" (par défaut à 50). Ainsi, une valeur à 70 va permettre aux joueurs de fluctuer jusqu'à un retard de 70ms après quoi ils seront victimes de l'antiwarp. Un antiwarp à 30 va infliger de l'antiwarp de manière beaucoup plus stricte, tant que la fluctuation est égale ou supérieure à 30.
[Une valeur à 50 semble être idéale si on s'en tient à la relation sv_fps/snaps à 20, ce qui signifie que les updates par le serveur sont envoyées toutes les 50ms (1 sec = 1000ms/20).]
[On peut présumer qu'une valeur inutilement trop basse va entraîner une surcharge du CPU car l'antiwarp va alors concerner beaucoup plus de joueurs.]
[On peut également présumer que l'antilag concerne également les joueurs qui font l'objet de l'antiwarp.]
Une valeur inutilement trop haute va potentiellement manquer les warpeurs "moyens" qui vont donc continuer de warper.
Bref, si vous ne savez pas trop quoi mettre, gardez 50.
Prendre soin de son upload
sv_maxrate et les problèmes du rate
Comme mentionné plus haut dans la section consacrée au /rate, cette variable permet de limiter le rate à une certaine valeur de bytes par seconde pour n'importe quel client (serveur->client). Cependant, depuis l'introduction de la compression delta dans les jeux basés sur q3, la valeur max de 25000 (24.41Kb/s) n'est jamais atteinte dans une situation normale de jeu. L'envoi de snapshots est généralement fait à 4 ou 8Kb/s pour chaque client même avec les réglages maximum. Ceci cependant peut ne pas inclure certains emcombrements dus à la valeur la plus basse possible du /rate à 8000 (7.81Kb/s), et parfois même à 10000 ou 12000.
A cause des effets de la limitation de la bande-passante, des valeurs comme 10000-12000 ou moins sur des serveurs fréquentés doivent être évitées. Jetez un coup d'oeil sur le test mené plus bas pour plus de détails.
Au cas où ioUrT embarque la future VoIP d'ioquake3, cette variable limitera également la bande-passante utilisée par cette fonctionnalité.
Un indicateur intéressant du bon usage des limitations de taux est l'état de la ligne du bas sur le netgraphe des joueurs. S'il y a du jaune au lieu du vert, cela signifie que le taux a été bridé. Ce n'est pas nécessairement mauvais, c'est même plutôt bon si votre bande-passante a effectivement besoin d'être limitée. Mais vous pouvez aussi vouloir réduire la latence et potentiellement éviter le jaune qui sera généra sur la ligne du dessus, et cela passera par l'augmentation du maxrate côté serveur.
Pour rappel, le jaune sur la ligne du dessus sera souvent en corrélation avec le jaune en bas, car la suppression d'informations destinée à préserver la bande-passante va obliger le jeu à extrapoler (et donc un jeu plus aléatoire comme on l'a vu).
Gardez à l'esprit qu'un taux plutôt bas pour le client est préférable à un taux plutôt élevé qui va provoquer une surcharge du CPU. Un taux bas va simplement créer un jeu un peu moins fidèle et aléatoire, alors qu'une surcharge CPU va carrément saturer les connexions et ainsi provoquer des lags importants (ainsi que des lignes rouges sur le netgraphe).
Si les clients ont du rouge sur leur netgraphe (des snaps d'infos sautés depuis le serveur), une raisons sous-jacente peut être une connexion entre le client et le serveur qui se trouve saturée. Donc un sv_maxrate réduit peut aider. Cependant, il peut y avoir d'autres sources de saturation entre les machines impliquées dans le processus.
La variable sv_minrate va forcer elle un taux minimum chez les clients, même si parfois le client peut avoir besoin d'un taux plus réduit que celui du serveur (s'il a une bande-passante vraiment limitée).
sv_minrate et sv_maxrate ne vont pas changer la variable retournée par le rate d'un client lorsque vous ferez /rcon status. Ces variables ne font que relever le rate du client, le comparer à celui du serveur et le forcer à un taux différent selon sv_maxrate et sv_minrate.
Si vous avez un sv_maxrate à 0, comme par défaut, cela équivaut à 25000. S'il n'y a pas de lignes rouges et si votre bande-passante se porte bien, alors laissez ainsi à la valeur maximale.
Nombre de clients
En relation directe avec sv_maxrate, le nombre de clients est important simplement pour calculer la bande-passante montante délivrée par le serveur et pour éviter la saturation de cette bande-passante ainsi que pour limiter les besoins du CPU. De plus, les développeurs du jeu (comme BladeKiller) ont démontré l'importance de ne pas dépasser le nombre de joueurs recommandé. Cela a également un effet sur la charge pesant sur les clients : un serveur va peut-être tenir le coup, mais est-ce que ce sera le cas également pour tous les joueurs ?
Besoins limités pour la bande-passante et surcharges
C'est simplement logique que la capacité requise en upload ne soit pas uniquement une question de nombre de clients et de sv_maxrate. En effet, 1) le jeu peut simplement ne pas avoir besoin d'utiliser complètement le maxrate et envoyer moins d'infos, 2) les connexions UDP utilisées pour le transfert des données peuvent avoir des surcharges, ce qui va augmenter la bande-passante utilisée.
Les besoins de download du serveur sont affectés par les valeurs du cl_maxpackets et des FPS affichés de tous les clients, même si cependant, il n'y a pas grand-chose que le serveur puisse faire pour limiter ou augmenter la réception de ceux-ci.
Surcharge du processeur (côté serveur)
C'est une raison courante de lag sur le serveur, un serveur de jeu pouvant demander pas mal de travail au CPU (comme quand par exemple il y a plusieurs serveurs sur la même machine). [Dans un tel cas, le client peut voir sur son netgraphe beaucoup de jaune sur le dessus de son netgraphe, ce qui signifie que le serveur n'a pas été capable de lui envoyer les snapshots à temps (sur la base de 20 snaps/seconde).] Le serveur peut être soulagé en donnant une priorité plus haute au processus sur le CPU, ou simplement en réduisant le nombre de programmes qui tournent. [Il peut être préférable d'éviter d'être constamment à 100% du CPU même avec des priorités de processus redéfinies, car l'OS sera toujours en mesure de redonner la priorité à certains processus vitaux s'il en a besoin.] C'est pourquoi faire tourner un serveur sur un ordinateur qui fait déjà tourner le client (qui est très gourmand en ressources) peut être problématique (même si de nos jours avec les processuers multicoeurs, ça peut tourner sans problème).
Exemple test : éviter un sv_maxrate inutilement bas
Il sera ici démontré que, si possible, un admin serveur devrait utiliser le sv_maxrate maximum, disons plus de 12000-15000 sur un serveur fréquenté par 16 joueurs et plus.
Le test montre qu'avec un taux bas, comme 8000, sur un serveur fréquenté par plus de 16 joueurs, le netgraphe ressemble à ceci :
Comme on l'a vu, le jaune sur la ligne du bas signifie que votre sv_maxrate (ou le /rate du joueur) a forcé l'info venant du serveur à arriver plus tard pour sauvegarder la bande-passante, mais qu'en contrepartie il y a donc du jaune sur la partie supérieure du netgraphe, car le client n'a pas assez d'informations pour dresser une représentation fidèle de ce qui se passe sur le serveur (extrapolation).
Plus grossièrement :
Bien sûr, n'augmentez pas votre sv_maxrate jusqu'à saturer votre connexion, car c'est encore pire pour les joueurs (lignes rouges) et cela ne signifie pas nécessairement que le serveur enverra des snapshots retardés [et ainsi ne perturbera pas la mémoire tampon de la compression delta], comme cela arrive avec la "suppression" d'infos pour la sauvegarde de la bande-passante grâce au sv_maxrate.
Un autre test :
Un serveur public très fréquenté (plus de 20 joueurs) avec un sv_maxrate à 25000 :
La même situation avec un rate à 8000 :
Vous pouvez également forcer un rate minimal avec sv_minrate, même si cela pourra causer quelques soucis aux joueurs qui ont réellement besoin de préserver leur bande-passante, mais de nos jours les connexions modernes tiennent largement le coup.
Autres aspects utiles / FAQ
Réseau
Quels sont les facteurs de base qui affectent le ping ?
Le ping est principalement déterminé par la distance qui vous sépare du serveur, et ensuite par le matériel qui va se trouver entre les deux, sans compter sur un bug ou la surcharge du serveur. Quand je dis "distance", cela tient compte du fait que la distance peut être du point de vue "réseau" aussi bien que d'un point de vue purement géographique, même s'il s'agit d'un facteur secondaire (et ceci ne constitue que la base de ce que l'on peut savoir sur le complexe cheminement d'internet).
Une partie seulement du chemin peut être saturée, ce qui arrive souvent ; vous pouvez faire quelques tests avec la fameuse commande traceroute.
Méthodes qui peuvent améliorer le ping
Le premier truc à faire serait évidemment de changer de serveur, vu que votre ping est principalement affecté par la distance géographique et par l'état du réseau entre vous et le serveur. Je dirais également d'éviter d'avoir une connexion saturée à tout prix. Sinon :
Gestion du trafic :
Vous pouvez ainsi donner une plus grande priorité aux paquets UDP (l'UDP est exclusivement utilisé par quake3, le TCP n'entre pas du tout en jeu), ou arriver au même résultat en donnant la priorité à certains ports ou adresses. Cependant il y a de fortes chances que vous ne voyiez la différence que dans le cas d'une connexion particulièrement sollicitée, et qui a donc potentiellement déjà des problèmes de surcharge. Une telle gestion de votre trafic peut être possible grâce à certaines cartes réseau à destination des gamers, même si encore une fois cela peut n'avoir d'intérêt que pour les connexions qui rament déjà un peu à la base.
Le système d'exploitation et réglage de pilote
Le trafic de paquets UDP peut être amélioré en bidouillant certains paramètres réseaux dans votre OS ou par le pilote de votre matériel. Cependant, ne jouez pas à l'apprenti sorcier en changeant quelque chose si vous ne savez pas vraiment ce que vous faites. D'autres choses peuvent se révéler totalement inutile : ainsi il y a beaucoup de programmes qui se proposent d'agir sur les connexions TCP, alors qu'UrT n'utilise QUE l'UDP !
Pilotes améliorés, et améliorations logicielles en général
Vous pouvez essayer d'upgrader votre OS ou vos pilotes (nouvelle version du kernel linux ou nouvelle version windows). Bien sûr, cela ne doit pas signifier de nouveaux bugs dans l'autre sens. En général, évitez les versions beta ou alpha.
Optimisation de votre réseau sans-fil
Un outil de diagnostic intéressant est celui qui scanne pour détecter les signaux qui peuvent interférer. Les autres signaux doivent idéalement être éloignés d'au moins 5 canaux pour ne pas interférer avec votre propre signal. Parfois des signaux faibles sur le même canal, ou du matériel vraiment très proches de votre antenne peuvent pas apparaître. Pour cela, essayez de changer de canal ou d'éteindre votre carte pour un court instant.
Le signal doit être aussi fort que possible (60% est suffisant par exemple). Si vous êtes trop loin de votre point d'accès, essayez de les rapprocher, ou d'utiliser des antennes intermédiaires ou ajuster leur position. Un pilote plus récent ou un firmware plus récent pour le routeur peut aider.
Instabilité du ping sur un ping faible ? C'est possible ?
L'instabilité du ping peut exister même sur des pings très faibles (surtout si vous avez saturé votre connexion avec votre FAI, comme lorsque vous téléchargez quelque chose pendant que vous jouez), ce qui signifie également que vous pouvez avoir un ping élevé mais stable (même si en général les gros pings sont ceux victimes d'instabilité).
Quel genre de fluctuation est dangereux ?
[Si vous dépassez la limite de 50ms dans la réception du snapshot du serveur et qu'il y a de l'extrapolation (pics jaunes), mais c'est possible également à moins de 50ms, mais beaucoup moins fréquemment. Egalement le ping peut avoir à monter au "mauvais" moment pour que les effets négatifs se produisent. C'est lié à l'échange périodique d'information entre le serveur et le client (dans l'intervalle de 50ms).]
Est-ce que les joueurs avec un gros ping sont avantagés ?
Non, très généralement. C'est parce que les gros pings voient toujours le jeu plus tard que les petits pings (même avec l'antilag). Les faibles pings ont toujours un avantage dans les situations de 1o1, tout simplement parce qu'ils tirent en premier selon le jeu (dans le scénarion hypothétique où deux joueurs tirent exactement au même moment dans le monde réel).
Un argument qui pourrait jouer sur le fait de ne pas laisser les gros pings jouer (d'un point de vue purement technique, je ne veux pas entrer dans les politiques internationales), est que le gros ping et les modifications artificielles de l'antilag rendent le jeu un peut "surréel" (dans le sens négatif du mot). Ainsi vous vous attendriez à ce que quelqu'un réagisse d'une certaine façon (en général comme vous vous réagiriez de manière instinctive), mais avec le délai du gros ping et l'action de l'antiwarp, vous vous direz que quelque chose a l'air bizarre (c'est percevable avec tous les pings mais bien évidemment beaucoup plus avec un gros ping). (Cela peut être en soi un avantage, pour le gros ping comme pour les autres). Ceci est aggravé par l'action de l'antilag comme on l'a vu ci-dessus.
Mais cela peut être accentué par la rumeur selon laquelle tous les gros pings ont un avantage par défaut, purement sur la base du ping, du moins à partir d'un certain point. C'est faux. Sur la base de la latence uniquement, les faibles pings sont indéniablement les gagnants.
"Pourquoi est-ce que je meurs toujours plus rapidement avec mon gros ping, alors qu'il y a de l'antilag et de l'antiwarp ?"
Vous mourrez plus sur des serveurs où vous avez un plus gros ping même avec de l'antilag, car vous apparaissez toujours plus rapidement sur l'écran de l'adversaire que lui n'apparaît sur le vôtre. C'est aussi simple que ça.
"Le timenudge n'est-il pas utilisé uniquement pour augmenter le ping ?"
Non. C'est un effet collatéral (voir détails plus haut). Si c'était le seul intérêt, les développeurs seraient fous de l'avoir inclu dans le jeu... En fait, cela n'augmenter même pas le ping, mais ajoute simplement un lag supplémentaire en interne dans la manière dont le jeu va percevoir ce qui se passe sur le serveur.
"Comment je peux devenir unhit ?" (en réglant mes paramètres réseaux)
Les gens "unhits" sont en général seulement ceux qui savent se déplacer.
Vous pouvez en théorie "bouleverser" votre connexion avec le serveur pour warper mais ça ne serait utile que sur les serveurs sans antiwarping, et même ainsi, le warper ne serait pas non plus capable de toucher quoi que ce soit, car lui-même n'aurait pas une vision parfaite de ce qui se passe autour de lui. Sur la plupart des serveurs l'antiwarp va éviter de tels exploits.
"J'ai de très rares traces jaunes sur ma ligne du dessus, est-ce que je dois utiliser ut_timenudge ?"
Probablement pas. La raison est que le lag que crée ut_timenudge est un handicap significatif (surtout au-dessus de 20) par rapport au simple fait d'avoir une extrapolation toutes les 10 ou 20 secondes. C'est surtout visible dans un jeu entre joueurs de même skill, où le plus petit lag peut avoir de grandes conséquences.
"Mon netgraphe est parfait. Est-ce que c'est toujours possible que ça soit la faute du serveur si je ne hit pas correctement ?"
La plupart du temps, les problèmes de hits sont juste liés au joueur qui en fait ne vise pas bien ou qui n'arrive pas à gérer la précision de son arme. C'est naturel, c'est un jeu complexe sur ce point, surtout si vous jouez contre des joueurs très expérimentés (et qui souvent savent bouger et devenir "unhit" de manière tout à fait légitime). Je ne crois pas que ce soit le bon endroit pour parler de "comment devenir un meilleur joueur", donc je ne rentrerai pas dans le débat. Mais je ne pense pas qu'avec un netgraphe clair on puisse rejeter la faute sur le serveur. Bien sûr, on ne peut jamais être à 100% sûr. Un antiwarp mal configuré ou un warp général peut être une source de hits irréguliers, même si le netgraphe a l'air bon, car le warp peut être causé par l'instabilité de la connexion d'un autre joueur, et non de l'observateur. Cependant même avec ça, le warp devrait être visible, et lorsque l'ennemi est dans votre ligne de mire, un warp avant ou après ne devrait pas être une raison pour le rater.
"Est-ce que ça peut être la faute du client si j'ai des problèmes de hits même avec un netgraphe clair ?"
C'est bien possible en fait, en tout cas bien plus que la faute du serveur. C'est parce que le netgraphe indique l'état du signal entre le serveur et vous, et non pas l'inverse (dont le taux est défini par cl_maxpackets et par les FPS). Par conséquent, cl_packetdup est toujours un bon moyen de résoudre la situation (à désactiver cependant si vous êtes absolument sûr que vos paquets voyagent bien).
Un lag matériel, comme un moniteur de connexion, la fréquence de l'écran, le temps de réponse de votre écran, la vsynch, ou même un lag de votre souris, peuvent être une source de problèmes de hits avec un netgraphe plat, même si vous ne percevez pas ces lags réellement.
"Pourquoi doit-on limiter la bande-passante plutôt que de simplement sauter quelques snapshots dans une connexion saturée ?"
[Comme la limitation de la bande-passante avec sv_maxrate et rate crée déjà un retard des informations envoyées par le serveur (ainsi que les effets collatéraux comme le jaune sur la ligne du dessus), on pourrait penser qu'il serait plus sensé de simplement laisser le serveur envoyer autant d'informations qu'il le peut, sans se soucier de l'éventuelle saturation, parce qu'avec une véritable limitation il y a déjà une certaine perturbation du jeu. Cependant, ce n'est pas le cas car avec des paquets droppés la mémoire tampon de la compression delta est aussi perturbée. Dans le même temps, mais s'il n'y a pas eu de telles perturbations, ne pas tenir compte périodiquement de certaines informations grâce à la limitation permet d'augmenter les chances d'une transmission plus régulière entre le serveur et le client. Ensuite, c'est plus sûr pour un servadmin qui souhaite garder la main sur sa bande-passante.]
Est-ce que les paquets client->serveur sont plus gros avec des FPS plus importants même avec un certain cl_maxpackets ?
[Oui, parce qu'ils contiennent des informations qui viennent de plus de frames. Cela signifie qu'il faut penser aux FPS lorsque l'on songe à prévenir la saturation de sa bande-passante.]
Traceroute - Déterminer la qualité de son réeau
Des outils tels que traceroute (tracert sous Windows) sont souvent utilisés par des spécialistes du réseau pour évaluer la qualité d'un réseau ; cela peut être également utile pour le gaming parce que vous pouvez savoir ainsi si un problème se situe sur un point particulier entre vous et le serveur. Par exemple, si vous remarquez que seul le 4ème noeud est le seul à générer des pics rouges, cela peut être la raison de l'instabilité et vous saurez ainsi que le problème ne vient pas de votre ordinateur. Il pourra alors être opportun de changer d'IP (ce qui va faire changer la route pour certains FAI), ou utiliser un FAI différent ou un serveur différent...
Changer d'IP peut aider
Cela peut vous sauver la vie ; certains FAI routent votre connexion différemment si vous changez simplement d'IP (avec une IP dynamique), ce qui peut être fait généralement en se reconnectant simplement. Cela signifie que les problèmes avec le réseau peuvent être réglés (ou apparaître) simplement en changeant d'IP.
Graphique / Visuel
Est-ce vrai qu'avec 60Hz, je dois avoir 60 FPS pour une latence optimale ?
C'est une idée fausse de croire qu'avec un moniteur réglé sur 60Hz, vous devez avoir 60 FPS sur le jeu pour avoir une bonne latence. En effet, alors alors que théoriquement le moniteur "interroge" la carte graphique 60 fois par seconde, il y a toujours une probabilité d'obtenir une latence visuelle plus basse si les FPS sont plus importants. Par exemple sur du 60Hz avec 125 FPS, il est fort possible (pas obligatoirement donc) d'avoir la meilleure latence visuelle de 1000/60 - 1000/125 msec. Le résultat sera d'environ 8.7 millisecondes.
Maintenant, un problème souvent lié - bien que pas lié directement à la latence - est le phénomène de "l'image tearing" ou "déchirement d'image". C'est un phénomène assez pénible qui apparaît lorsque le moniteur rafraîchit l'écran alors que l'image envoyée par la carte graphique est en fait contenue dans plusieurs frames (plus d'une au moins), en général en dessous de 70Hz. Pour éviter cela, on peut recourir à la vsynch pour bloquer ses FPS à 60 à 60Hz par exemple. Mais cela reste complètement différent de bloquer "manuellement" ses FPS à 60 avec com_maxfps 60, cela déchirera l'image dans ce cas et sûrement de manière encore plus importante, car au moins avec plus de FPS, votre image est "plus déchirée" et cela se voit moins que si l'image est contenue sur 2 frames seulement. De plus, la vsynch occasionne un lag sur la machine (en local), et vous devriez éviter de l'activer, sauf si vous privilégiez la qualité visuelle au détriment des performances. On pourrait répondre à cela que la beauté de l'image peut également améliorer son gameplay ; tout est histoire de compromis.
D'un autre côté, cl_maxpackets, le taux de transfert de paquets du client vers le serveur, est lui aussi affecté par les FPS. C'est-à-dire qu'à 60 FPS, vous ne pouvez avoir en réalité que 30 paquets par seconde envoyés par votre client au serveur, alors qu'à 125 FPS vous montez à 42, ce qui signifie qu'à 125 FPS la latence sera meilleure d'un point de vue purement réseau (au-delà de l'avantage visuel).
La synchronisation verticale (vsynch) en relation avec la latence
La vsynch ajoute un lag interne sur ce qui est montré au joueur sur son écran. Vous devriez donc l'éviter si vous n'en avez pas besoin. Cependant, la vsynch peut être nécessaire (au moins par préférence personnelle) pour certains joueurs qui sont confrontés à de l'image tearing avec leur écran qui tourne sur une basse fréquence (en dessous de 60Hz). L'image tearing peut également apparaître sur certaines configurations SLI.
Autres aspects du moniteur
On peut essayer d'avoir la plus haute fréquence verticale avec un CRT, et le meilleur taux de réponse et la meilleure fréquence avec un LCD. Le mieux est d'essayer d'avoir une fréquence verticale (pour les CRT) ou une fréquence (pour les LCD) à 70Hz ou mieux, et un temps de réponse à 10ms est préférable.
Améliorer et stabiliser vos FPS
Avoir des FPS stables est très important pour plusieurs raisons. En effet, au-delà de l'avantage majeur d'avoir un jeu fluide, il est important d'établir une certaine cohérence entre vos FPS et votre cl_maxpackets afin d'optimiser la latence de vos paquets entre vous et le serveur.
Pour améliorer vos FPS, on peut bien sûr mentionner brièvement tout ce qui au niveau des règlages graphiques rend le jeu un peu plus "moche" mais qui vous donnera quelques FPS supplémentaires (résolution plus basse, antialiasing désactivé, qualité de texture plus basse, filtrage anisotrope désactivé principalement). Si je devais détailler précisément toutes ces méthodes, je dépasserais probablement l'objet de ce guide, mais il y a beaucoup de ressources à ce propos sur Urban Terror. Regardez surtout la FAQ du jeu (très utile).
Sachez également les serveurs où il y a moins d'action (moins de joueurs) sont moins exigeants vis à vis de votre carte vidéo.
Enfin n'oubliez pas qu'un ordinateur suffisamment moderne peut largement faire tourner UrT à n'importe quels FPS, sans besoin pour vous de sacrifier la qualité visuelle du jeu.
Est-ce que la latence est plus faible avec des FPS plus importants même s'ils sont plus importants que la fréquence du moniteur ?
[Il peut y avoir une latence visuelle plus faible avec des FPS plus importants, par exemple comme on l'a vu à un maximum de 1000/60 - 1000/25 = 8.7msec, si vous avez 125 FPS et 60Hz).
Est-ce que j'aurais moins d'image tearing avec des FPS plus importants ?
[On pourrait supposer que des plus gros FPS aggravent le phénomène d'image tearing car dans un "déchirement" vous aurez les fragments d'images issus de plus de frame. Cependant, avec 60Hz est la vsynch activée, l'image tearing sera plus visible qu'avec 125 FPS sur du 60HZ, pour la raison que si le déchirement est plus important, il est cependant compensé par une fluidité plus importante de l'image grâce à plus de FPS.]
Est-ce vrai que l'œil humain ne peut distinguer qu'un certain nombre de FPS ?
L'œil humain et le cerveau sont des éléments organiques, ils ne fonctionnenet pas en termes de FPS ou d'Hz. On peut simplement faire des tests pour tenter de déterminer ce qu'un individu peut distinguer. Un individu moyen peut faire la différence entre deux valeurs de FPS dans un jeu, grâce à son expérience du gaming, mais cela s'arrête là. D'autant plus que cela dépend de la qualité de l'image, l'état d'esprit de la personne (fatigue...).
Des tests ont démontré que des pilotes de l'armée américaine pouvait distinguer le modèle d'un avion qui leur était montré à 1/220e seconde. Cependant, cela ne prouve pas que l'œil humain est capable de voir la différence dans les FPS dans toutes les situations car il y a beaucoup d'autres facteurs qui entrent en jeu (l'individu lui-même, son état de fatigue, et tout le côté matériel de l'ordinateur).
Concernant la souris et le clavier
/in_mouse sur les clients Windows
[Essayez de garder cette variable à -1 (API basique Windows), car 1 va utiliser DirectInput et augmenter le temps de réponse de la souris de 12ms.]
Autres réglages de la souris possibles
Voyez si vous pouvez augmenter le taux de réponse et les DPI de votre souris. Au besoin, faites quelques recherches sur Google selon le modèle que vous avez. Le taux de réponse (polling rate) est probablement plus important que les DPI concernant la latence, par exemple 1000Hz signifie un temps de réponse de votre souris de 1ms, mais à 125Hz par exemple, le temps sera de 8ms ! (1000ms/1000 contre 1000ms/125).
Pourquoi est-ce que je ne peux pas appuyer sur plus de 3 ou 4 touches en même temps sur mon clavier ?
C'est une limitation matérielle qui vient de votre clavier lui-même. Vous devez alors essayer d'autres combinaisons de touches qui peuvent marcher. Sinon, vous devrez vous orienter vers un clavier plus haut de gamme (essayez-même avant de les acheter ou renseignez-vous).
/r_finish
[Cela améliore le taux de réponse de votre souris / clavier au moins lorsque vous avez la vsynch activée.] Cependant cela diminue les FPS alors vous devriez éviter si vous n'en avez pas besoin (surtout si vous n'utilisez pas la vysnch).
Autres aspects liés au moteur du jeu
"Prendre une démo dégrade mes hits"
En fait, si vous avez l'impression que les hits ne sont pas bons (par rapport au jeu lorsque vous êtiez en train de jouer), c'est parce que les démos n'enregistrent pas très fidèlement ce qui s'est passé. C'est même pire avec g_synchronousclients à 1 pendant que vous enregistré (car cela force le jeu à attendre les infos de tous les clients avant d'enregistrer le mouvement), et vous pourriez avoir un lag si vous jouez avec cette variable activée.
sv_fps/snaps bloqués à 20, cl_maxpackets
Cela peut être une explication en soi pour les informations contenues plus haut, mais avoir le sv_fps du serveur et le snaps du clients bloqués sur 20 signifie que le serveur envoie une info au client toutes les 50ms (1 sec = 1000ms / 20 = 50ms) mais en retour cela signifie aussi qu'il y a donc un lag considérable implémenté directement dans le jeu. C'est logique de supposer que si on pouvait augmenter le sv_fps et le snaps cela réduira considérablement la latence dans le jeu. Mais cela nécessiterait également plus de ressources.
Variables de prédiction
Voici les variables qui commandent la prédiction côté client
- cg_smoothclients : si désactivée (0), le client attend que le serveur détermine la position des autres joueurs.
- cg_predictitems : similairement, à 0 le client attend que le serveur détermine l'état des objets à terre.
- (cg_nopredict : Vous ne devriez jamais mettre cette variable à 1 car cela rend le jeu très instable. Sauf si vous savez ce que vous faites.)
Vous pouvez essayer les deux premières variables à 1, mais "0" est plus "réel". Mais en même temps, devoir attendre le serveur nuit forcément quelque part à la fluidité du jeu. Vous pourriez vouloir tester.
"Est-ce que la valeur de sv_fps/snaps doit être prise en compte pour déterminer le bon cl_maxpackets ?"
[Apparemment non, même si certains sites suggèrent qu'il y a un lien. C'est parce que selon le code du jeu, la réception d'instructions ne semble pas correspondre ou du moins être en corrélation directe avec l'envoi des snapshots par le serveur.]
"Ai-je besoin de 125 FPS pour jumper ?"
Cela n'a plus d'importance, cela n'était le cas que pour les anciennes versions de Q3. Avec cg_physics sur 1 (par défaut), n'importe quels FPS donnent le même résultat au niveau des physics du jeu.
La forte corrélation entre les FPS et le réseau et la manière dont cela fonctionne en général
Vous devriez toujours garder à l'esprit que les FPS ne gouvernent pas seulement les graphismes (juste la latence visuelle), même si c'est leur but premier. Les FPS sont très liés à la manière dont fonctionne le moteur du jeu. Par exemple, s'il n'y a aucun FPS, aucune frame à afficher, il n'y a pas d'informations à envoyer au serveur par le client.
Ping, FPS, snaps, etc. Compteurs de variation et drop/pics de FPS
Cette rebuild du moteur vous permet d'afficher des outils réseaux et de mesure qui peuvent être utiles pour évaluer votre réseau, vos FPS et la stabilité de votre jeu.
"Les FPS sont le lag"
Quand je dis cela, c'est parce que les FPS sont un facteur premier du fonctionnement du moteur, et pas seulement un indicateur de nombre d'images ou de qualité comme indiqué ci-dessus, ou même uniquement un moyen de mesurer la latence visuelle. Les FPS sont également déterminés par toutes les opérations réalisées par le moteur du jeu. Donc si vos FPS sont mis sur 125, il y a forcément un lag local de 8 ms pour envoyer les informations au serveur. Ce n'est pas par hasard si le taux de transfert d'infos du serveur au client est géré par une variable qui s'appelle sv_fps.
Sources
- Les forums Urban Terror.net et les commentaires, surtout ceux des devs.
- F3quake's et sa super base de connaissance concernant les cvars.
- Dur's Quake III Arena et ses précieuses indications concernant le lagometer et les remarques de Carmack.
- Upset Chaps La très vieille référence de q3 sur la plupart des cvars
- Vsyn Study Les opinions sur la vsynch par plusieurs concepteurs de jeu.
- Internal Paper on Image Tearing and Vsynch Un point précis sur l'image tearing et sa prévention.
- Le sens commun
- Le sens pas commun
- Le code source de q3, parce que si ça n'existe pas ici, alors ça n'existe pas du tout.
- #ioquake3 sur freenode
- Les remarques de Carmack
-
Asche
- Expert mapping & modding + Participant Powerban
- Messages : 2650
- Enregistré le : 02 août 2009, 23:08
- Localisation : #unity-team
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Très intéressant comme article.
Je viens de tout lire et j'ai appris pas mal de choses, notamment sur le netgraph et les variable snaps et rate.
Je viens de tout lire et j'ai appris pas mal de choses, notamment sur le netgraph et les variable snaps et rate.
Asche's Soundcloud
Album en cours : Dubstination (Dubstep) et Hyptonium (Trance)
*Beaucoup d'occupation en ce moment !*
_________________
I Love Prius
Album en cours : Dubstination (Dubstep) et Hyptonium (Trance)
*Beaucoup d'occupation en ce moment !*
_________________
I Love Prius
-
rogor
- Chef de projet + Expert installation & configuration du jeu
- Messages : 1816
- Enregistré le : 31 janv. 2009, 20:33
- Localisation : La Chapelle sur Erdre (44)
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
J'ai trouvé ça très intéressant. Merci pour la traduction.
Je vais pouvoir régler quelques paramètres maintenant.
Je vais pouvoir régler quelques paramètres maintenant.
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Cool merci je savais a quoi sa servait le netgraph mais pas précisement. Thx Tizz. 
-
Seemslegit
- Messages : 86
- Enregistré le : 27 août 2009, 03:01
- Localisation : ts3 ontop
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Merci beaucoup, j'comprend mieux maintenant ;D
LIBEREZ REDWAR !!! LIBEREZ REDWAR !!!
http://www.petitionpublique.fr/PeticaoV ... 2013N34397
http://www.petitionpublique.fr/PeticaoV ... 2013N34397
LIBEREZ REDWAR !!! LIBEREZ REDWAR !!!
http://www.petitionpublique.fr/PeticaoV ... 2013N34397
http://www.petitionpublique.fr/PeticaoV ... 2013N34397
LIBEREZ REDWAR !!! LIBEREZ REDWAR !!!
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
J'avais lu pas mal de fois cette article en anglais et malheureusement j'avais pas tout capté a cause de l'anglais technique present dans l'article original
Merci pour la trad
Merci pour la trad
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Ben, disons que le mec est grec à la base, et il a une façon assez bizarre d'écrire en anglais (genre il remplace des mots très courants en anglais par d'autres qui ne sont que des traductions alternatives...).orangebud a écrit :J'avais lu pas mal de fois cette article en anglais et malheureusement j'avais pas tout capté a cause de l'anglais technique present dans l'article original
Merci pour la trad
-
W[i]ld Man
- Messages : 207
- Enregistré le : 21 déc. 2009, 08:52
- Localisation : Région parisienne
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Merci beaucoup pour ce long article très instructif.
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Son portage en tant que tuto officiel est toujours en cours. :>
HEIN LINKTIM.
HEIN LINKTIM.
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
Le tutoriel a été porté en tant que tuto officiel.
--
Veuillez noter que la version ci-dessus n'est plus à jour, veuillez vous référer à la version officielle.
--
--
Veuillez noter que la version ci-dessus n'est plus à jour, veuillez vous référer à la version officielle.
--
-
W[i]ld Man
- Messages : 207
- Enregistré le : 21 déc. 2009, 08:52
- Localisation : Région parisienne
Re: Guide approfondi sur le netgraphe et le réseau sous UrT
J'ai relu ce tutoriel, et grâce à lui, j'ai même réussi à obtenir un ping plus bas tout en étant très stable. Mon rate et cl_maxpackets étaient trop bas (casiment le minimum), et je tourne toujours à 125 FPS.