Comme à son habitude, Valve vient de mettre à jour son moteur Source. Cette mise à jour apporte de nouvelles fonctions mais aussi corrige également quelques bugs.

On notera l'arrivée d'une fonction utile pour les administrateurs de serveurs de jeux : la possibilité de forcer les clients à n'utiliser que les fichiers d'origines présent sur un serveur, créant ainsi la notion de "pure server".

Du côté des corrections, voici une liste exhaustive :

• La page de recherche des serveurs "in-game" affiche désormais que les joueurs humains. Les bots sont affichés dans une autre colonne au lieu des mentions "quelques bots" ou "aucun bots".
• Augmentation du rate maximum jusqu'à 1 Mo.
• Le VAC bloque désormais certains cvars et commandes.
• La commande cl_restrict_server_commands a été supprimée.
• Fixe des plantages lors de l'authentification.
• Fixe des cvars sv_minrate et sv_maxrate qui n'étaient pas correctement appliquées chez les clients.

L'ensemble des corrections est visible en anglais à cette adresse.

Voir la news entière

J'ai remarquer aussi agrandissement de la boite de dialogue quant un serveur shutdown ou timeout ou kicker.
Ce qui permettras je pense à faire des raisons quant on ban ou kick plus grande avec lien ou autre

Oui en effet, le texte en anglais rentrait parfaaitement mais le texte français pas forcement.
 
"Augmentation du rate maximum jusqu'à 1 Mo."
ça peut servir chez moi si j'ai le 1024?

tu n'es pas en 1024 réel ?
 

Ce n'est pas une mise a jour avec énormement de corrections, mais ce sont de tres bonnes corrections

plutot utile le truc des bots quand notre serveur favoris  a planté et qu'il faut en trouver un autre
 
Je suis tombé sur des serves uniquement avec des bots et c'est trop lourd ^^

ENFIN !

Dans la news officielle, personne n'a relevé la phrase :
 

 
C'est moi ou c'est la première fois que Steam remercie des admins d'avoir testé en pré-version leur mise à jour ?
 
M'enfin en tout cas c'est plutôt rassurant, ils testent désormais ( mieux ? ) leur mise à jour.

Valve ouvre steam de plus à d'autres editeurs (cf la news de Capcom) donc ils sont bien obligés d'etoffer leurs moyens..

Globalement c'est donc trés bon cette ouverture.
 
Tarif, stabilité, on y gagne ... sauf en espace disque ...  

C'est génial cette màj
 
Surtout les bots qui ne sont plus dans le browser

le bug de "crash" lors des changements de team en war n'a toujours pas été corrigé malheureusement.

Pas mal la mise à jour du "Pure servers" ... 3 nouvelles cvars :
 
sv_pure ( 0 = désactivé, 2 = complète, 1 = se base sur le fichier pure_server_whitelist.txt )
 
sv_pure_kick_clients ( 0 = Warning, 1 = Kick ) à 0 par défaut !!!
 
sv_pure_trace ( 0 = pas de traces/logs de vérification de CRC, 1 = log )
 
Plus d'infos chez Steam.

sv_pure_kick_clients ( 0 = Warning, 1 = Kick ) à 0 par défaut !!!  
 
ça n'a aucun interet alors...

me suis posé la même question ...
 
En fait, à mon humble avis, Source force les modèles originaux et vérifie le CRC, si le CRC n'est pas bon il ne kickera pas
mais le joueur se retrouvera avec les modèles/sons/... originaux extrait du .gcf qui est forcément "original" ( encore que ... ).
 
A mon avis kicker par défaut génerait beaucoup de joueurs qui veulent garder leur fichier "customs".
( Obligé de tout désinstaller pour venir sur le serveur ... )
 
Il leur faudra juste trouver des serveurs "non purs" pour voir les fichiers "customs" mais ils pourront les conserver
y compris sur des serveurs "purs" ( ils seront juste non pris en compte ).

je pense plutot qu'au contraire le joueur est loggé ou averti mais pas kické et peut continuer a jouer avec ses models.

A vérifier ... m'enfin vu la gestion du cache Steam, il peut forcer les modèles originaux comme il veut en ne lisant que le .gcf
et en ne prenant pas en compte les fichiers persos ...

 
non, DanRaZor a raison    
 
comme c'est ecrit sur le Wiki Valve Developer Community :
 
In most cases, even clients who have modified content sitting on their disk are still allowed to play on a pure server. The Source Engine will ensure that the content from Steam (instead of the content from their disk) is used when a client plays on a pure server. This way, clients don't have to wade through their game directories to clean out old content before they play on a pure server. Instead, they just join servers and the correct allowed content is automatically used.
 
en gros, le fait que la variable soit à 0 est plutôt un avantage, les personnes ne seront pas kickées mais joueront avec leur fichiers originaux, en revanche si un jour un hack tout droit sortant des forums mygot ou autre sort... on pourra toujours forcer le kick...
 
sinon, j'ai remarqué une option dans mon menu "settings" qui me donne le droit de participer aux futures betas de Valve    
j'ai en ce moment une "beta participation" disponible  

Normalement ça kick par défaut les joueurs qui ont des modifications.
 
Sinon c'est l'admin du serveur qui choisit si on utilise les fichiers originaux ou les fichiers modifié, et il semblerais que si un joueur utilise des fichiers modifiés, les autres joueurs en sont avertis.
 
http://developer.valvesoftware.com/wiki/Pure_Servers
 
 
 
PS : Bon ba grilled..

 
Toujours ... non je plaisante, mais c'est comme ça que je l'aurais fait, tout ça me rassure un peu ...  
 

 
Intéressant ...

Bonne nouvelle pour la commande cl_restrict_server_commands...Depuis l'temps qu'elle me gavait celle-là !!  

La meilleur Maj sur css depuis bien avant leur system de prix dynamiques c'est ce genre de maj que css a besoin pour dévelloper la compétition.  
 
Pour le rate ça fait donc rate "1048576" vue que la valeur est à entrer en bytes, déja qu'avec la valeur 81920 je me fesais traiter de neteux par de pauvres types qui comprennent ou ne savent rien du netcode de source  
 
Pour le bug de changement de side j'espère que c'est une blague, ça fait depuis au moin janvier qu'il pourrie le jeux en war ...
 
Sinon dans les settings de mon client steam, j'ai l'accès à "clickandbuy béta"  

 
Je ne peux que plusser : la limite de 81920 du rate pouvait provoquer du choke sur les serveurs avec beaucoup de joueurs... maintenant, avec les rates de 1048576, alléluia !
 
(voir mon document : http://articles.e-t172.net/srcnetcode/ si vous souhaitez comprendre pourquoi c'est une bonne nouvelle)

oui enfin bon don dossier n'est plus complet surtout au niveau de l'interpolation et alors je sais qu'en fin de dossier tu te posais la question  
 
les serveurs auraient de l'interpolation, réponse non, fait un serveur, mets toi en cl_cmdarate 10 fait une démo, et en regardant la vidéo tu vois que tu lags
 
et aussi le fps_max serveurs est très utilie pour ceux qui choke, beaucoup de serveur ayant du choke et à qui j'ai conseillé le fps_max 130 ont vu leur choke disparaitre  
 
revenons sur la Maj sa ne m'étone pas avec les CGS et Direct TV

 
Ce qui est une conclusion hâtive. Si une interpolation se produit côté serveur, elle ne fonctionne évidemment pas pareil qu'une interpolation côté client, puisque ce serait complètement inutile (car redondant). En revanche, je pensais plus à une interpolation se produisant lors du lag compensation, pour obtenir un lag compensation plus précis (et contrer les "petits malins du cmdrate" dont je parle dans mon document).
 

 
Argument post hoc ergo propter hoc donc irrecevable tant qu'il n'aura pas été prouvé (ou du moins lorsqu'il aura un raisonnement tangible derrière). Une quantité incroyable d'erreurs de compréhensions ont été faites sur le netcode de Source à cause de ce type de confusion (l'exemple le plus criant est la relation entre tickrate et choke, où certains seraient tentés de conclure un peu vite qu'augmenter le tickrate augmente le choke, donc est mauvais, alors que ce choke est en fait dû à l'accroissement de la bande passante nécéssaire du fait de l'updaterate réel plus élevé).

*popcorn*saucisse*frites*

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 :
 

 
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

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.

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 ).

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...
 

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  

[quote]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.

+1 -> halte au plugins

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 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.

cay pas bien d'utiliser des skins perso !

 
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".

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