Une mise à jour pour le moteur Source

[thedark]

*popcorn*saucisse*frites*

[LeSage]

je t'assure que sa fonctionne, le faite est la, trouve toi un serveur avec du choke et test par toi même

et si tu veux un raisonnement, le seul que j'ai trouvé c'est ça :

le serveur à un historique d'image dans lequel il va voir pour dire si tu touche ou non, plus le serveur à de fps plus il calcule d’image (ce qui demande de la ressource) qu’il stock son historique, plus l’historique est grand plus il faut (probablement) du temps pour les parcourir ce qui demande plus de ressource à nouveau

bref plus de fps_max serveur est grand plus le serveurs à besoins de ressource, en diminuant le fps_max, tu diminue la demande en ressource

hors le fait qu'un serveur à du choke c'est sans doute la ressource qui lui manque, en diminuant la le fps_max, il ce soulage

maintenant ne connaissant pas ce que sa à comme autres effets je conseil toujours au personne de le mettre à 130 et de l'augmenter petit à petit jusqu'a ce que le choke réaparraisse et de diminuer la valeur à un rien en dessous

[e-t172]

Ton raisonnement est faux pour deux raisons :

L' "historique" dont tu parles (qui n'est rien d'autre que le lag compensation dont je parle dans mon document) dépend du tickrate et non pas des FPS serveur (ça tombe sous le sens si on connaît la définition d'un tick).

Le choke n'est jamais dû à un manque de ressources de calcul côté serveur. Il est toujours dû à un manque de bande passante. Rien d'autre. Fais le test : fais tourner un serveur avec 100 bots, en tickrate 100 et avec des programmes qui bouffent 100% du CPU à côté. Tu lagueras à mort, le tickrate réel du serveur sera complètement pourri, donc ton updaterate réel aussi, mais tu n'auras pas de choke.

Qui te dit que lorsque tu augmentes ces FPS, tu ne diminues pas le choke, mais tu empêches le serveur de calculer correctement le choke, et la valeur affichée dans ton net graph serait ainsi erronée et te montrerait un choke plus bas alors qu'il ne l'est pas ? C'est avec ce genre de raisonnement fallacieux qu'on en arrive à sortir des trucs absurdes à propos du netcode. Avant de prétendre avec certitude que ça marche, il faut d'abord se demander pourquoi ça marcherait.

J'étudierai ce problème lorsque j'aurai fini mon bac. En attendant, j'aimerais savoir à quel tickrate tournent les serveurs que tu as "améliorés", et leur valeur de fps_max initiale avant tes modifications, puis après.

[SekYo]

J'ai beaucoup aimé l'article de e-t172, mais c'est vrai qu'il date un peu, peut être certains conclusions ne sont plus valables.

Vous avez l'air tous deux d'être intéressés par ce Netcode et d'en avoir déjà des connaissances importantes, pourquoi ne pas vous associer vous le (re)mettre à l'épreuve sous toutes les coutures ?

En différanciant bien les effets pour lesquels vous avez une explication "logique" de ceux qui sont plus "mystérieux"

Sinon ça fait longtemps qu'on peut participer au programme Béta de Source ( c'est une commande à rajouter dans la ligne de commande qui démarre SRCDS, mais il est évident que pour 99% des serveurs qui sont chez un GSP ils vont pas s'amuser à le faire ).

Par contre y a la mailing-list des loueurs de serveurs de Valve qui est très active en ce moment (d'ailleurs dans le programme Beta, la sv_pure_kick_clients est maintenant à 1 par défaut ).

[slink3]

Enfin augmenter la valeur maximale des rates c'est bien gentil,

mais tant qu'au aura les 3/4 des serveurs matchs bourrés de plugins type Cvar-Block qui pour la plupart forcent la cvar rate à 30000

ça sera toujours pas glop...

*popcorn*saucisse*frites*

[dunedain]

Vi mais le cvarblock est franchement useless sur la gestion des rates.... Le cvarblock impose les rates mini et maxi sans que ça soit possible de les changer via la console ou le server.cfg, ce qui ne serais pas une mauvaise chose si ça ne donnait pas "sv_minrate 5000; sv_minupdaterate 30 et sv_mincmdrate 30" d'ou le manque de connaissance des dévellopeurs dans ce domaine.

J'aime bien aussi le dossier de e-t172, je l'avais découvert sur nofrag quand mes connaissances se limitait à se qu'est le tickrate et les cmdrate et updaterate, il est très complet mais mérite une bonne maj quand même

[thedark]

Vi mais le cvarblock est franchement useless sur la gestion des rates.... Le cvarblock impose les rates mini et maxi sans que ça soit possible de les changer via la console ou le server.cfg, ce qui ne serais pas une mauvaise chose si ça ne donnait pas "sv_minrate 5000; sv_minupdaterate 30 et sv_mincmdrate 30" d'ou le manque de connaissance des dévellopeurs dans ce domaine. [.Quote]

si j'ai bien lu la MAJ, ce problème est maintenant résolu puisque les valeurs minrate et maxrate sont bien forcées sur le serveur et donc chez le client.

[m000t]

Enfin augmenter la valeur maximale des rates c'est bien gentil,

mais tant qu'au aura les 3/4 des serveurs matchs bourrés de plugins type Cvar-Block qui pour la plupart forcent la cvar rate à 30000

ça sera toujours pas glop...

*popcorn*saucisse*frites*

[/quotemsg]

+1 -> halte au plugins

[dunedain]

C'est pas ça le problême thedark, c'est seulement que la dernière version du cvarblock imposait ses valeurs et que donc tous le monde pouvaient jouer avec des rates pourrie sans que même un admin ne puisse rien y faire.

Le pire c'est que sur cette dernière version il n'y a plus moyen pour tous de vérifier les rates de la totalitée des joueurs sur le server, le cvarblock_check_all ne montrant plus que le dxlevel, picmic, specular, bumpmap ect... seulement les réglages graphiques, plus rien sur les réglages du netcode :sarcastic: pour le plugin officiel de l'ESL ça fait pas très sérieux ...

Il y avait effectivement un bug avec le sv_minrate et sv_maxrate, mais pas avec sv_minupdaterate, sv_maxupdaterate, sv_mincmdrate et sv_maxcmdrate.

[Shelkz]

cay pas bien d'utiliser des skins perso !

[e-t172]

J'aime bien aussi le dossier de e-t172, je l'avais découvert sur nofrag quand mes connaissances se limitait à se qu'est le tickrate et les cmdrate et updaterate, il est très complet mais mérite une bonne maj quand même [/quotemsg]

Oui, je sais. C'est juste que je manque un peu de temps en ce moment. Quand j'aurais du temps à y consacrer je réécrirai le document en détaillant en prime les expériences faites et les raisonnements logiques qui m'ont mené au résultat exposé, pour poursuivre le but original du document, qui est de faire une étude sérieuse du Netcode débarassée des préjugés et des "mythes urbains".

[SekYo]

Parce que malheursement on en croise toujours beaucoup trop de ces mythes :/