Centralisation Counter Strike Source

[Psylokh]

Salut!

Le cl_smooth permet de corriger la représentation du jeu coté client si elle ne correspond pas exactement a celle du serveur il me semble.

Lorsqu'elle est a 0, la représentation du monde coté client est corrigée instantanément. Lorsqu'elle est a 1, le delais de correction est egal a cl_smoothtime.

Le cl_forcepreload te permet de charger tous les élément nécessaire au jeux avant d'arriver dessus. Le temps de chargement est légèrement plus long, mais tout est chargé, alors que si tu nje force pas le preload, tu risque plutôt d'avoir des a-coup durant le jeu, du au chargements des fichiers (textures, models...) manquants.

Le r_propsmaxdist permet de définir à partir de quelle distance tu va commencer a apercevoir les petit objets a terre (ce qui n'influent pas sur le jeu. Tu peux te déplacer dessus sans problème contrairement aux bidons, saut ... qui te gènent dans tes déplacements.

Le r_lod défini la qualité des personnages. de 0 a 7. 0=meilleur qualité, 7 = qualité horrible.

Le r_decal_cullsize défini a quelle distance tu va voir les decals. Impact de balles sur les mur par exemple. Ca va de 0 a 5 je croi, et a 0, ca veux dire que tu les voit tout le temps. A 5 tu les voit uniquement quand tu en est très près.

Le cl_c4dynamiclight est censé t'afficher ou non la lumière en même temps que le bips du C4. Perso j'ai jamais vu la différence entre 0 et 1

Le cl_ragdoll_collide Active (1) ou désactive (0) la gestion de la physique sur les corps mort. S'il est actif, les corps a terre ne se rentrent pas dedans. S'il est désactivé (par défaut car utilisation cpu plus importante) alors les corps a terre qui sont a proximité sont susceptible de se rentrer dedans. Par exemple, le bras de l'un qui est a la même place que la jambe de l'autre. Ca ne gêne pas et se voit quasiment pas puisque par défaut tout le monde tourne comme ca :)

Pour la qualité graphique, tu jettes un petit coup d'oeil sur la première page du topic. La ou se trouve le tuto. C'est expliqué.

[Killerspre]

Merci beaucoup pour ta réponse complète

Juste pour le "r_lod" c'est par défaut à -1 et le mieux c'est -5 je crois.

Et le "cl_c4dynamiclight" permet de voir un flash blanc sur les murs au alentour du clignotement de la bombe... c-à-d que si tes sur d2 par exemple que ta du mauvais sons et que la bombe est posé en b et que tes corn tu pourra voir en regardant en mid un clignotement blanc et donc savoir quelle est en b.

Pour la 1er page je les bien lus, d'ailleurs elle m'a appris pas mal de chose notamment pour la config serveur, mais ma questions portait sur les commandes graphique données mais non définit :

cl_phys_props_enable 0

cl_phys_props_max 0

cl_phys_props_enable 0

cl_ragdoll_physics_enable 0

cl_ragdoll_collide 0

cl_show_splashes 0

fog_enable 0

fog_enable_water_fog 0

mat_antialias 0

mat_bumpmap 0

mp_decals 8

r_decals 10

mat_fastspecular 1

mat_forceaniso 0

mat_forcemanagedtextureintohardware 1

mat_hdr_enabled 0

mat_hdr_level 0

mat_specular 0

mat_picmip 2

mat_trilinear 0

muzzleflash_light 0

r_rootlod 2

r_decals 0

r_eyegloss 0

r_eyemove 0

r_rainradius 0

r_shadows 0

r_teeth 0

r_waterforceexpensive 0

r_3dsky 0

rope_smooth 0

rope_wind_dist 0

r_worldlights 1

r_modellodscale 0.6

Merci beaucoup

[Psylokh]

r_lod a -1 par defaut oui, mais j'ai jamais vu de différence entre -1 et -5 :\

Par contre entre 0 et 7, c'est très net

Merci pour le dynamic_light, j'avai pas capté que ca se reflechissai sur les murs

Par contre, tu veux toutes les correspondence des commandes ?

[Killerspre]

Mais alors pour le "r_lod" c'est quoi le mieux xD ?!

Sinon de rien pour le dynamic_light mais c'est normale vue l'aide que toi tu m'a apporté ^^

Ba pour les correspondance oui j'aimerai bien puis ca pourrai aidez les autres, merci!

[Psylokh]

pour r_lod faut voir dans la console. (je suis en train de redl css, je peux pas tester)

Tu tape r_lod tout seul et il devrait t'afficher les valeur min et max. Sinon faut voir sir entre -1 et -5 y'a une réelle différence.

Pour les correspondence, je ferai ca quand j'aurai le temps. J'suis en train de scripter un prog d'admin avec m00t (le codeur maison ) qui devrait sortir d'ici peu Et avec le taf toussa, pas trop de temps

[Killerspre]

Je tape r_lod et voici ce qu'il me met:

] r_lod

"r_lod" = "-5" ( def. "-1" )

Ne t'inquiète pas je comprend tout à fait, c'est normale puis tout ce que tu as fait c'est déjà super

A la prochaine

[Psylokh]

Oai, il te met -5 car tu as deja entré -5 dans ton cfg :\

Je vérifie ca quand css sera DL. (Serv steam saturés avec red orchestra :'( je dl a 20 Ko/sec .... RDV dans 2 mois )

[Psylokh]

Bon, voila qui est fait pour les descriptions.

J'ai viré les commandes inutiles a css.

C'est pas véritablement complet. je verrai ca quand j'aurai un peu plus de temps.

[-fL-]

Salut tout le monde, j'ai une petite question et peut-être que m00t est le mieux placé pour y répondre.

Voila je me sers du programme de m00t pour modifier le HUD mais malheureusement il n'est pas inclus la possibilité de modifier la police d'écriture au niveau de l'affichage des frags (le nom des joueurs) et des messages en milieu d'écran (genre "counter-terrorist win").

Avant d'utiliser le programme de m00t, j'avais trouvé des fichiers modifiables avec le bloc note ( HUD_layout.inf un truc du genre), dans lesquels je pense que l'on pouvait définir la police pour ces textes. Malheureusement je ne trouve plus ces fichiers.

Comment faire, car je pense que c'est loin d'être impossible. Merci

[Space]

Tu as tenté le bouton "reset" du programme ?

[m00t]

Salut tout le monde, j'ai une petite question et peut-être que m00t est le mieux placé pour y répondre.

Voila je me sers du programme de m00t pour modifier le HUD mais malheureusement il n'est pas inclus la possibilité de modifier la police d'écriture au niveau de l'affichage des frags (le nom des joueurs) et des messages en milieu d'écran (genre "counter-terrorist win").

Avant d'utiliser le programme de m00t, j'avais trouvé des fichiers modifiables avec le bloc note ( HUD_layout.inf un truc du genre), dans lesquels je pense que l'on pouvait définir la police pour ces textes. Malheureusement je ne trouve plus ces fichiers.

Comment faire, car je pense que c'est loin d'être impossible. Merci

Salut

En effet ça doit tout à fait être possible. Par contre j'ai peur que ça ne modifie pas que les messages de frags (mais je suis pas trop sur de ça qd même).

On va regarder ça . Enfin surtout psylohk quand il sera de retour du taf, parce que tout ce qui concerne la bidouille de fichier dans le HUD Tweaker, c'est lui

[Franck03]

Salut tout le monde,

Je vais bientôt rejoindre votre communauté puisque à noël je vais avoir un HP pavillon 9051 ea qui je pense me permettra de jouer allegrement a CS:source

Depuis le temp que je voulais m'y remettre

Bye

[Psylokh]

Salut tout le monde, j'ai une petite question et peut-être que m00t est le mieux placé pour y répondre.

Voila je me sers du programme de m00t pour modifier le HUD mais malheureusement il n'est pas inclus la possibilité de modifier la police d'écriture au niveau de l'affichage des frags (le nom des joueurs) et des messages en milieu d'écran (genre "counter-terrorist win").

Avant d'utiliser le programme de m00t, j'avais trouvé des fichiers modifiables avec le bloc note ( HUD_layout.inf un truc du genre), dans lesquels je pense que l'on pouvait définir la police pour ces textes. Malheureusement je ne trouve plus ces fichiers.

Comment faire, car je pense que c'est loin d'être impossible. Merci

Salut !

Pour modifier les message de frags, tu ouvres le fichier clientshemes.res

Tu trouve la ligne: "Default" dans la partie Fonts

Tu vas sur le paragraphe qui correspond a ta résolution verticale ingame. (exemple: par 4 ""yres" "1024 1199"" pour une réso en 1280*1024)

Dans ce paragraphe, tu modifies la taille de la police. Tu peux modifier la police aussi. Dans ce ca, tu met le nom de la police voulue. Si ce n'est pas une police windows standart, il va falloir que tu copie le fichier police dans le même répertoire que le fichier clientshemes.res, et en bas du fichier clientshemes, tu indique la présence de la police par une ligne supplémentaire.

exemple: "4" "resource/toto.ttf"

voila

Ce sera certainement inclue automatiquement dans une version futur, mais on ne sais pas quand.

A savoir: La modification de cette police change aussi les nom dans le tableau des scores.

Pour les screen message, je sais pas si c'est posible. Je me pencherais dessus quand j'aurai le temps. Mais je l'ai pas vu pour l'instant.

[-fL-]

Salut psylochk

Effectivement, juste apres avoir posé mon post j'ai réussi à chopper le fameux fichiers clientshemes.res, mais après avoir vu un nombre conséquent de polices utilisée par le programme j'ai éteint le PC et je suis allé au dodo

Du coup je vais tester ce que tu me dis, et je ferais un up des que cela sera fait.

Merci l'ami

[Killerspre]

Bon, voila qui est fait pour les descriptions.

J'ai viré les commandes inutiles a css.

C'est pas véritablement complet. je verrai ca quand j'aurai un peu plus de temps.

Merci beaucoup

Juste encore une tite question... dsl

C'est pour "sv_client_predict" qui a était inclus dans la MAJ avec les autres commandes de blocage (vachement utile d'ailleurs) qui correspond à "cl_predict" je crois (1 par défaut) et qui selon la console est pour "Perform client side prediction." mais ca m'aide pas trop enfaite. Voilà, dsl de te déranger encore ! Merci

[Psylokh]

Met le a 1, ca va le forcer chez tout le monde, et ainsi soulager le serveur au niveau du lag compensation

Je vais pas rentrer dans les détails, lit l'article linké dans la partie netcode du tuto en 1° page si tu veux plus de technique, mais en gros, ca autorise la prédiction des actions chez les joueurs.

L'exemple de l'article se résume à ca:

Pour avoir un jeu plus réactif, le client n'attend pas forcément les confirmations du serveurs en ce qui concerne les tir et déplacement. Par exemple sans prédiction (cl_predict 0), tu appuies sur ton bouton de tir, l'information est envoyée au serveur. Le serveur confirme l'action de tir (étant donné que c'est lui le maitre du jeu ) et te renvoie la confirmation. A ce moment, tu va voir l'animation de ton arme qui va commencer a tirer. Ensuite, tu envoies l'information de ton tir au serveur. Ce qui fait 3 voyage de l'info entre le serveur et toi. Soit une latence d'environ 3 fois ton ping

Avec la prédiction d'activée, tu tires, ton pc crée l'animation et envoie directement l'info de ton tir au serveur. A ce moment la, tu n'a qu'un voyage et le retard de ton tir est égal à ton ping.

Globalement, ca ne change pas grand chose au niveau du netcode étant donné que le mecanisme de compensation de lag compense les retard dû au 3 voyages dans le cas d'un cl_prédict 0, mais du coté client, ca rend le jeu plus réactif.

Voila. J'espère m'être bien fait comprendre

Petit complément: Il arrive (rarement) que le client fasse quelques erreur de prédicion, notemment en ce qui concerne les déplacement. Si le client s'est trop déplacé par rapport au jeu réel (controlé par le serveur), c'est le cl_smooth qui rentre en jeu. Comme je l'ai dit a la page d'avant, le cl_smooth corrige les actions du client qui sont légèrement décallée par rapport au serveur, tout en douceur si le delais de l'erreur ne dépasse pas le cl_smoothtime

Voila :) C'est tellement faible qu'on ne s'en rend meme pas compte, sauf quand on se prend un vieu retour en arrière. Mais quand la connection est bonne, c'est très très rare.

Faudrai que je complète la centralisation avec toutes ces explications, mais j'ai que 4 posts en première page, et j'ai pas enormément de place

[Psylokh]

Bon voila!

J'ai détaillé les cvars principales concernant la partie network coté client en première page

Ca donne ca :)

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

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

cl_interpolate 1 Permet d'avoir une image fluide des joueur. Avec l'interpolate a 0, si un joueur envoie 20 paquets par seconde au serveur (cause: fps faibles, ou cmdrate mal réglé) alors vous verrez ce joueur saccader (on dit aussi se téléporter) car vous n'aurez que 20 images par secondes de ce joueur.

Avec l'interpolate à 1, le client va combler le manque de position du joueur par des images (tick) insérée entre chaque déplacement du joueur avec une trajectoire calculée en fonction des 2 dernière positions reçue, pour ainsi le rendre plus fluide. Inconvénient: les images générée par l'interpolation ne sont pas touchable. Comme si c'etait un model virtuel etant donné que c'est géré uniquement chez le client.

cl_interp 0,02 Règle l'intervalle sur lequel est effectué l'interpolation. Plus la valeur est petite, et mieux c'est car les paquets utilisés pour l'interpolation sont très récent (mais attention: lire la suite). En gros, l'interpolation se sert du dernier tick généré et du paquet reçu 0.02 seconde avant le dernier pour créer une trajectoire.

- Dans le cas d'un cl_interp 0.1, l'interpolation se sert du dernier paquet reçu et du paquet reçu 0.1 seconde avant le dernier. La valeur idéale dépend de votre cl_updaterate, du tickrate serveur et peut être (se renseigner la dessus) de votre framerate.

- Prenons exemple avec un cl_interp 0.01. Si vous recevez les info du serveur peu fréquemment, alors il se peut que le paquet recu 0.01 sec avant le dernier n'existe pas ou ne soit pas renouvelé, et dans ce cas, c'est l'extrapolation qui rentre en jeu, et c'est pas réglable et peut précis.Ce que je me demande, c'est dans le cas ou vous avez 50 FPS (je rappelle que l'interpolation est générée chez le client uniquement), votre dernier tick aura été généré 0.02 sec avant le dernier et dans ce cas, le premier tick sur lequel se base l'interpolation (celui 0.01 sec avant le dernier) n'existe pas.

- Cl_interp 0.01 est a utiliser dans un cas parfait (tick 100, 100 fps, updaterate 100). 0.02 est deja bien plus adapté. 0.1 etant par défaut est en fait adapté aux cas les pires, car l'interpolation fonctione avec un tickrate 10, un updaterate 10 et (peut être) 10 fps chez le client )

rate 30000 ou plus. C'est le taux de transfert maximum (serveur => client uniquement) (30000 octets par secondes), ce sont les serveurs qui fixent une limite en général a 25 ou 30K , mais mieux vaux être au maximum autorisé par le serveur. De plus un rate trop bas avec un updaterate assez élevé provoque du choke.

cl_predict 1. Permet d'avoir un jeu plus réactif chez le client. En fait, le jeu n'a pas besoins d'attendre une confirmation du serveur pour effectuer certaines action comme les animation de tir ou les déplacement.

Sans prédiction coté client, il faut que le client envoie l'info de son action au serveur, ensuite le serveur confirme l'action au client, et la, le client effectue son action. Avec la prédiction, le client envoie ses actions au serveur et c'est tout. Il arrive (rarement) que le client fasse quelques erreur de prédicion, notemment en ce qui concerne les déplacement. Si le client s'est trop déplacé par rapport au jeu réel (controlé par le serveur), le serveur va corriger la trajectoire chez le client. C'est en général tellement léger et peu fréquent qu'on ne s'en apercoit pas. (voir le cl_smooth)

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

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

cl_smoothtime 0.02. C'est le temps maximum autorisé pour"smoother". C'est a dire pour vous replacer en douceur par rapport au serveur. Si l'erreur de prédiction est trop importante pour être corrigée en douceur dans le temps imparti, alors vous êtes replacé brutalement a votre position.

Le smoothtime doit être egal ou inférieu au cl_interp. Car si votre jeu se sert de 0.02 sec pour interpoler la trajectoire d'un joueur et que votre smooth vous replace a votre position en 0.1 sec, vous aurez un décalage entre l'endroit d'ou vous voyez le joueur et l'endroit ou vous êtes réellement pour le serveur. Et les 2 différentes trajectoires de balles etant colinéaire avec un point de départ différent, n'auront pas le même point d'arrivée (impact)

[psikobare]

Psylohk, les pistolets vont être revus pour concurrencer le Deagle qui deviens trop cher sur les serveurs qui ont activé le steammarket, mais est-ce que les changement de caractéristiques serons aussi effectifs sur les serveurs normaux?

pour moi qui ait l'habitude de jouer aux dual et au 57 ce serait une super nouvelle

[Psylokh]

Oui la maj concernant la puissance de certain gun est générale. Ca concerne tous les serveurs.

[Amokers]

Bonsoir :)

Tout d'abord, je tiens à vous féliciter pour votre topic qui en aideras plus d'un

Accro du netcode depuis 5ans, je suis fier de voir cette article bien rédiger et ce en francais.

En revenche, je voudrais vous faire part de quelques remarques :

Déja concernant la config serveur, il y à un detail :

vous avez mis : sv_lan 1

Donc ce qui veux dire que votre config est fais pour ceux qui veulent faire des lan chez eux mais ce qu'il faudrais rajouter et ce en BIEN GRAS et surligné c'est que c'est une config lan !!

Je dis ca car je supposes que ceux qui vont lire le topic, notemment ceux qui débutent risque de faire l'erreur de mettre

sv_lan 1 sur leur serveur du net et donc avoir des lag etc,

Ensuite, j'ai constater que vous ne mentionez pas le cl_lagcomp_errorcheck (defaut 0)

n'est-elle pas importante ?

Autre chose, à propose du rate la dessus peut être je me trompe mais partout on lis qu'il faut le mettre à 30000

Or ayant de l'experience à cs (1.5, css) et ayant été en 56k auparavent, si javais mis rate 30000 il metais alors impossible de jouer :) je jouais en rate 3300

Tout ca pour dire que maintenant je suis en 512k et que j'ai constater que j'ai moins de decal en rate 20000 que en rate 30000

Si je suis les variables par defaut de steam, je devrais tourner en 512k en rate 9999 et bien sur comme vous le savez cela entraine entre 30 et 50 de choke sans action

Donc pour conclure avec un petit rate on obtiens beaucoup de choke, mais avec un rate elevé notemment 30000 cela entraine un enorme décalage.

Peut-être devriez vous préciser que rate 30000 ne s'applique que pour les connection au dessus de 8mo par exemple.

Pour information mon binome est en 2mo et à constater lui aussi moins de décal en rate 25000 ou rate 20000 que en rate 30000.

Enfin un dernier détail :

J'ai lu beaucoup d'articles sur le netcode, et il est vrai que tout le monde parle de mettre l'interp 0.01, votre article est le seul sur le NET et sur Source qui spécifie une valeur différente notement 0.02 je concoit fortement votre opinion, car vous avez argumenter le pourquoi du comment.

En revenche le problème est que vous mettez dans la config server la variable sv_client_interp -1 ce qui laisse le choix aux client, or j'avais lu sur un article de netcode que justement il fallais que tous les clients aient les même valeur soit 0.1 ou 0.01 mais tous la meme valeur, tout comme la précieuse valeur cl_interpolate qui fu d'ailleur un long débat maintenant résolu.

Enfin pour conclure un autre problème ce pose c'est le cvarblock ou encore le zblock qui lui le défini à 0.01 donc il est vrai que tous les client aurons le même ce qui est bien mais en revanche si le client ne s'en appercois pas et qu'il est a 0.01 et que sont cl_smoothtime est à 0.02 il y auras la encore un problème (cf votre article)

Sinon encore félicitation pour ce topic, je repasserais de temps en temps pour voir l'évolution et pourquoi pas y contribuer

[Psylokh]

Merci pour les remarques et le critiques objectives. C'est ce que j'attends depuis que j'ai repris cette centralisation (a l'abandon) il y a quelques mois.

J'ai beau avoir pas mal de connaissance dans le domaines, je ne suis pas un Dieu (du moins je ne croi pas ). Et donc je doit faire des erreur / oublis qui sont rarement relevé .

Donc ce qui veux dire que votre config est fais pour ceux qui veulent faire des lan chez eux mais ce qu'il faudrais rajouter et ce en BIEN GRAS et surligné c'est que c'est une config lan !!

Je dis ca car je supposes que ceux qui vont lire le topic, notemment ceux qui débutent risque de faire l'erreur de mettre

sv_lan 1 sur leur serveur du net et donc avoir des lag etc,

Pour la configuration serveur, oui, c'est pour faire du LAN, d'ailleurs il est réglé pour. Mais en effet, je n'ai précisé ca que dans le fichier cfg, et c'est pas très visible. Je vais corriger ca d'ici peu.

Ensuite, j'ai constater que vous ne mentionez pas le cl_lagcomp_errorcheck (defaut 0)

n'est-elle pas importante ?

Le cl_lagcomperror_check, je ne peut pas cacher que je suis pour le moment incapable de définir sa fonction exacte.

Selon le nom, il doit s'agir d'une vérification client de la compensation de lag gérée par le serveur. Il est apparemment conseillé de la mettre a 1, mais par manque d'info je ne l'ai pas mise. Mais si tu peux m'eclairer sur son fonctionnement, ce serait génial

Autre chose, à propose du rate la dessus peut être je me trompe mais partout on lis qu'il faut le mettre à 30000

Or ayant de l'experience à cs (1.5, css) et ayant été en 56k auparavent, si javais mis rate 30000 il metais alors impossible de jouer :) je jouais en rate 3300

Tout ca pour dire que maintenant je suis en 512k et que j'ai constater que j'ai moins de decal en rate 20000 que en rate 30000

Si je suis les variables par defaut de steam, je devrais tourner en 512k en rate 9999 et bien sur comme vous le savez cela entraine entre 30 et 50 de choke sans action

Au niveau du rate, on a tendance a conseiller 30000, car il y a de plus en plus de connection haut voir ultra haut débit, et en général, c'est les serveur bloquent a 30000 voir avant (25 ou 20K pour certain).

En fait, tu devait avoir énormément de problèmes en 56K car le serveur t'envoyais beaucoup plus d'info que ce que tu pouvais recevoir donc les paquets n'arrivaient pas, ou arrivaient en retard par rapport au jeux. En cas de faible connection (512K, enfin faible.... tout est relatif, en faisant ce tuto je me suis basé sur une connection standard 1024 qui doit logiquement suffire pour avoir un excellent netcode 100/100/rate 25k) tu peux baisser ton cl_updaterate. Ca va diminuer la fréquence de réception des paquet et logiquement diminuer les erreurs du jeu. Enfin après beaucoup de paramètres rentrent en compte, mais on ne peux pas faire du cas par cas :\

Il faudrait tester s'il est préférable de baisser le taux de transfert ko/sec client/server ou diminuer la fréquence de rafraichissement des paquets paquets/sec avec ces connections. J'essaierais de faire un petit paragraphe la dessus :).

Pour le 56K c'est encore pire car le debit est si faible que ca fait comme un goulot d'étranglement énorme et la, meme en diminuant la fréquence d'arrivée des paquets, c'est la taille des info qui sature la ligne. Dans ce cas, il faut en effet limiter au maximum le taux de transfert serveur / client. Mais cette connection etant en voie de disparition, je ne pense pas la mentionner dans le tuto. Il me semble aussi qu'il est écrit dans les recommandation de configuration du jeu de posséder une ligne internet haut debit (a vérifier).

Pour le problème du rate trop bas, c'est l'effet inverse, la connection serveur / client est bridée, du coup t'as des probèmes de récéptions des info. De toute facon, les paramètres par defaut sont vraiment bidon sur cs source

Peut-être devriez vous préciser que rate 30000 ne s'applique que pour les connection au dessus de 8mo par exemple

J'appliquai un rate 30K avec mon ancienne connection 2 MBits, et avec ma nouvelle connection 8 MBits, je ne voit aucune différence. Donc ca doit dépendre aussi de la qualité de la ligne, mais ca ne représente qu'un peux plus de 30 Ko/sec en download (maximum) pour le client, donc la, je voit pas comment une connection 2 MBits, même 512 KBits peut saturer.

En revenche le problème est que vous mettez dans la config server la variable sv_client_interp -1 ce qui laisse le choix aux client, or j'avais lu sur un article de netcode que justement il fallais que tous les clients aient les même valeur soit 0.1 ou 0.01 mais tous la meme valeur, tout comme la précieuse valeur cl_interpolate qui fu d'ailleur un long débat maintenant résolu.

Moi aussi j'ai beaucoup lu 0.01 pour le cl_interp, mais si cvarblock permet un réglage entre 0.01 et 0.1, c'est pour laisser le client choisir en fonction de ses paramètres non ? Ensuite, en lisant et comprenant les articles sur le netcode source (de chez valve ) j'ai pu comprendre comment fonctionne le mécanisme. Et j'en ai tiré les conclusion que j'ai citées dans le tuto, 0.01 étant la valeur parfaite, mais ceci dans une configuration client/serveur parfaite, mais si quelqu'un me démontre que j'ai tord, je reverrais le tuto. Mais je ne suis pas le seul a avoir recommandé 0.02.

Pour le fait que tous les clients doivent avoir la même valeur, je ne comprend pas pourquoi. C'est un calcul réalisé sur deux tick précédent, mais les écart entre les ticks précédent ne sont pas les même chez tout le monde. Si X recoit 66 infos du serveur par seconde et que Y en recoit 100, alors le tick généré 0.01 seconde avant le dernier ne sera pas du tout le même. De plus ca n'affecte en rien le serveur ou la vision des hitbox. La prédiction de la trajectoire (qui ne s'effectue que chez le client sera juste calculée avec le dernier point et un autre point plus ou moins récent.

Par contre, j'ai vu quelque part sur le forum steam qu'il serait bien d'avoir la possibilité de mettre cl_interpolate 1 avec un cl_interp de 0. Va falloir que je voit ca de plus près car il s'agirait d'interpoler une trajectoire avec un seul tick . Soit une infinité de possibilité

Pour ce qui est de l'activation de l'interpolation (cl_interpolate), la en effet c'est une autre histoire qui est bien plus problématique au niveau de la vision du jeu coté client.

Enfin pour conclure un autre problème ce pose c'est le cvarblock ou encore le zblock qui lui le défini à 0.01 donc il est vrai que tous les client aurons le même ce qui est bien mais en revanche si le client ne s'en appercois pas et qu'il est a 0.01 et que sont cl_smoothtime est à 0.02 il y auras la encore un problème (cf votre article)

Il me semblai que cvarblock bloquait entre 0.01 et 0.1 Je ne suit pas l'evolution des plugin. Chez INpact, le serveur tourne tout nul, sans plugin

[Amokers]

Ben écoute pour le lagcomp g pas d'info, sinon pour le serv inpact j'ai vu ya rien et ta bien raison

Un bon serv ffa c'est un serv sans plugin

Perso g un serv ffa bien config avec le mani mais ya le strict minimum

Sinon je tente de tenvoyer mon msn en pv

[Psylokh]

OK.

Pour le serveur, on est en train de faire un petit truc chez INpact qui permet d'administrer facilement sans plugin. C'est un tout petit prog qui ecrit les fichier cfg du client en fonction des personnes présentes sur le serveur. Tout ce qu'on demande au serveur c'est la commande statu. Du coup c'est très leger, et le serveur s'en sort beaucou mieux.

Sinon, tu m'a fait relire quelques article de valve sur le netcode, et en fait, la réponse au cl_interp 0.01 a l'air toute bête. si le tick n'existe pas dans les 10 dernières ms, il va simplement chercher le premier tick qui trouve avant ces 10 ms Je vais cogiter un peu plus la dessus et peut être changer les cvars Mais la différence entre une interpolation sur 20 ms ou 10 ms doit pas être enorme non plus ^^. Et du coup, l'extrapolation entre en jeux si aucun tick n'a été recu dans les .25 dernière secondes uniquement :)

[Amokers]

Ha ?

Sinon des que tu est la tu peu go msn stp ?

Merci :)

[Killerspre]

(Re)Bonjour,

J'ai était confronté à ces commandes que je ne connais pas, alors j'aurai aimé des explications si vous le voulez bien

Merci

sv_wateraccelerate 10

sv_accelerate 5

sv_airaccelerate 10

host_framerate 0

sv_stepsize 18

sv_stopspeed 100 (c'était à 75 mais comme je connais pas j'ai mis par défaut)

sv_waterfriction 1

mp_autocrosshair 0

tv_transmitall 1