http://jcmick.free.fr/
Soigner sa configuration Source ( SRCDS )
Ici, nous allons voir comment organiser la configuration d'un serveur Source ( SRCDS ).
On parlera ici de la configuration d'un serveur Counter-Strike Source
mais les principes sont facilement applicables à nimporte quel autre mod.
Première étape indispensable : Installer son serveur
Pour cela, je ne m'étale pas, MAX vous a concocté des tutoriaux
on ne peut plus clairs et précis, pour installer un serveur Steam Source .
Deuxième étape : Préparation des fichiers nécessaires
On va lister ici tous les fichiers configurables de SRCDS.
Tous les fichiers ci-dessous sont des fichiers "texte"
et sont donc facilement éditables à l'aide du bloc-notes
ou à l'aide de vi ( sous linux ).
Ici on a une particularité, certains fichiers ne sont pas à la racine mais dans un repertoire nommé cfg.
Fichiers de configuration du mod
cfg / valve.rc
gameinfo.txt
Fichiers de configuration des cvars
cfg / autoexec.cfg
cfg / server.cfg
cfg / game.cfg
Fichiers de configuration "autres"
motd.txt
mapcycle.txt
Fichiers autres
cfg / banned_ip.cfg
cfg / banned_user.cfg
Si un de ces fichiers n'existe pas, ne pas hésiter à le créer.
Mais là, curieux comme vous êtes, vous allez sûrement demander :
| Citation : Mais à quoi ça sert tout ça et qu'est ce qu'on y met, ou qu'est ce que l'on peut modifier ? |
Description: L'intêret et l'utilisation de chaque fichier
Je ne me vante pas ici de décrire exhaustivement chaque fichier
mais je vais plutôt tenter de transmettre tout ce que je connais
à propos de ces fichiers et que j'ai appris par l'experience.
cfg / valve.rc :
Petit fichier souvent oublié qui a son importance.
En réalité ce fichier n'est rien d'autre que l'équivalent d'un fichier cfg.
( cfg = config pour ceux qui ne le sauraient pas )
Cependant, il a une particularité trés forte : Il est executé à l'origine du lancement du serveur.
Son contenu est souvent :
| Citation : // load the base configuration //exec default.cfg r_decal_cullsize 1 // run a user script file if present exec autoexec.cfg // // stuff command line statements // stuffcmds |
En fait le contenu de ce fichier est executé comme habituellement pour SRCDS
mais la différence réside dans le fait que tout ce qui est configuré ici
est actif dés les premiers instants de vie du serveur.
C'est pour cela que l'on peut y modifier l'ip, le port et d'autres cvars.
Vous noterez tous le exec autoexec.cfg que tous les admins connaissent bien.
Et bien voila pourquoi il est lancé automatiquement.
Cela permet de rendre une certaine souplesse de configuration, sachant que certaines
variables sont difficilement modifiables une fois le serveur lancé.
Changer l'ip ou le port de connection en cours de fonctionnement peut poser quelques problèmes.
Ce fichier doit toujours se terminer par stuffcmds. Cette commande indique au moteur Source de continuer son chemin habituel sans se préoccuper du reste.
Une fois le "stuffcmds" passé certaines variables ne sont plus accessibles (ip, port ... ).
En fait ce fichier réalise l'équivalent de passer les configurations dans la ligne
de commande de démarrage du serveur ( +ip +port ... ).
Ce fichier n'est à mon avis plus utilisé par personne mais peut permettre certaines options.
gameinfo.txt
Ce fichier est spécifique au mod. Pour CS:Source on a :
| Citation : "GameInfo" { game "Counter-Strike Source" title "COUNTER-STRIKE'" title2 "source" type multiplayer_only nomodels 1 nohimodel 1 nocrosshair 0 hidden_maps { "test_speakers" 1 "test_hardware" 1 } FileSystem { SteamAppId 240 ToolsAppId 211 SearchPaths { Game |gameinfo_path|. Game cstrike Game hl2 } } } |
Contrairement à HL1, ici trés peu de champs sont modifiables.
A l'heure actuelle, le seul qui est éventuellement modifiable est la liste des "SearchPaths", en particulier cela permet d'activer le Metamod Source.
Le reste des champs parlent d'eux mêmes, le nom est explicite ... ( en anglais )
Allons maintenant examiner les fichiers de configuration des cvars ...
cfg / autoexec.cfg
Comme on l'a vu précédemment ce fichier est particulier et permet aussi d'initialiser certaines variables.
Il est executé une et une seule fois à chaque lancement du serveur.
On peut y placer tout ce qui peut être mis dans la ligne de commande ( options avec + ).
Par exemple : map, maxplayers, ip, port, ...
Cependant tout ce qui a été mis dans la ligne utilisée pour le lancement n'est pas modifié.
En résumé : mettre dans ce fichier toutes les configurations auxquelles on est sûr de ne jamais toucher par la suite.
Il y a aussi deux cvars qui sont à placer dans ce fichier : le servercfgfile et le mapchangecfgfile
Le servercfgfile définit le fichier qui sera lancé derrière le autoexec.cfg.
Par défaut ce fichier est server.cfg, mais libre à vous de mettre un autre fichier.
Le mapchangecfgfile définit le fichier qui sera executé à chaque rotation de map
automatique ou forcée par un admin.
Par défaut le mapchangecfgfile est non défini mais le fichier game.cfg réalise déja cette fonction.
Exemple de contenu de ce fichier :
| Citation : map cs_assault maxplayers 12 port 27025 servercfgfile "server.cfg" mapchangecfgfile "server.cfg" exec plugins.cfg echo --->autoexec.cfg done |
On notera ici l'execution d'un fichier ( plugins.cfg ).
Le fichier plugins.cfg ne doit pas être à la racine du serveur ( cstrike ) mais bien dans cstrike/cfg, c'est une particularité du moteur Source, le exec cherche "par défaut" les fichiers "à executer" dans le repertoire cfg ( cstrike/cfg ).
Pour info avec cet exemple pour lancer le serveur, pas la peine de préciser quoi que ce soit.
Sous windows : srcds.exe -game cstrike -console suffit
Sous linux : srcds_run -game cstrike suffit
cfg / server.cfg
Tout le monde connaît ce fichier. C'est le fichier de référence pour la configuration d'un serveur Source.
Par défaut ce fichier est executé une, et une seule fois au démarrage du serveur juste aprés le autoexec.cfg.
Ici on peut y placer tout ce qu'on veut et même executer d'autres fichiers.
En particulier il ne faut pas oublier ici les cvars les plus importantes :
hostname,
sv_downloadurl,
motdfile,
rcon_password,
sv_password,
...
On détaillera leur utilité dans la suite.
N'oubliez jamais que ce fichier n'est executé ( par défaut ) qu'une seule fois.
Aussi toute modification d'une cvar de ce fichier par rcon en cours de jeu
sera définitive ...
Gare aux modifications de rcon_password, dont on oublie la valeur ...
Obligé de faire un reboot et de casser l'ambiance du serveur.
ouhhhh le mauvais admin
Mais pour éviter ce genre de problème penser à configurer le mapchangecfgfile
et d'y mettre un rcon_password par défaut par exemple.
Impossible de l'oublier, c'est toujours le même quoi qu'il arrive.
Au pire il suffira de changer de map pour récupérer le bon rcon_password.
cfg / game.cfg
Ce fichier absent par défaut, est executé à chaque rotation de map.
En fait ce fichier est utile pour assurer le gameplay comme son nom l'indique.
On y placera toutes les cvars dites de "gameplay" comme :
mp_friendlyfire
mp_freezetime
mp_c4timer
mp_hostagepenalty
mp_limitteams
mp_roundtime
...
Ne paniquez pas, on les détaillera par la suite ...
On assure ainsi qu'à chaque map on retrouve une configuration optimale
et on oublie les délires de l'admin à la map précédente.
Cependant certaines cvars reviennent d'elle même à des valeurs par défaut
lors du changement de map comme sv_gravity par exemple, mais il doit y en avoir d'autres dans ce cas.
motd.txt
Ce fichier est la petite page qui s'affiche à la connection du serveur : Le MOTD.
Ici, ce fichier doit être considéré comme une page HTML, on peut y glisser du code HTML
et il fonctionnera de façon proche de votre browser préféré
( moyennant quelques limitations ... vidéo, streaming, javascripts )
Ce fichier n'est valide que s'il a une taille inférieure à une certaine valeur
que je ne connais pas ( Only Steam knows ... )
Du coup la ruse souvent utilisée est de le faire pointer vers une page internet.
Cela donne à peu prés ça :
| Citation : <html> <meta http-equiv="Refresh" content="1; URL=notre-motd.htm"> <body BGCOLOR="#FFFFFF"> <hr> <br> <br> <center>Chargement en cours...</center> <br> <br> <hr> </body> </html> |
Avec Source on a encore une nouvelle possibilité, l'utilisation d'un autre fichier ( que motd.txt ) par une cvar : motdfile.
Un exemple : motdfile "indexCSS1.html"
Ici le motd utilisé sera le fichier cstrike / indexCSS1.html.
Si vous connaissez bien le HTML, il est possible de faire un tas de choses trés jolies
pour avoir un motd trés original, et avec cette redirection, aucune limitation.
Mais gare aux images et autres fichiers à télécharger, les connectés ne vont pas attendre
20 secondes que la page se charge
Un motd permet de connaître les propriétés du serveur.
En le créant, essayez de donner envie aux visiteurs de le lire.
Décrivez y précisément votre serveur, donnez tous les mods installés ( SH, War3 ... )
et donnez toutes les infos qui vous paraissent importantes :
Site du clan, Nom de l'admin ( + mail ), règles de courtoisies, nom des admins ...
Lachez vous ... ou pas ...
Pour les serveurs en LAN, soit vous disposez d'un serveur web, pas de soucis, une url
suffira, mais sans serveur web, faites des pages simples directement dans le motd.txt
( ou le motdfile ) en essayant de ne pas trop charger ce fichier.
Si il ne marche pas c'est souvent qu'il est trop gros ...
mapcycle.txt
Ce fichier permet de définir la rotation des maps.
Listez ici toutes les maps que vous voulez activer sur votre serveur.
Il n'est pas obligatoire de lister toutes les maps disponibles.
Il ne faut mettre qu'une map par ligne du fichier.
Exemple :
| Citation : cs_italy de_dust de_aztec de_cbble cs_office de_chateau de_dust2 de_piranesi cs_havana de_prodigy cs_compound de_train de_tides de_port de_inferno cs_assault |
cfg / banned_ip.cfg
cfg / banned_user.cfg
Ces deux fichiers définissent les joueurs bannis qui seront chargés au démarrage et sont executés automatiquement au lancement du serveur.
Le banned_ip définit les ip bannies, le banned_user définit les STEAM_ID bannis.
Ces fichiers sont mis à jour lorsque l'on fait la commande de ban suivi du write associé.
Pour bannir une ip : banip 5.0 81.35.152.86 ; writeip
Pour bannir une STEAM_ID : banid 5.0 STEAM_0:0:123456 ; writeid
Le 5.0 précise un ban pour 5 minutes et les deux writeXX inscrivent les données dans les fichiers.
On retrouvera en fait dans ces fichiers les commandes de ban réécrites, tout simplement.
Troisième étape : Configuration des cvars
Je ne parlerais ici que de certaines cvars de CS:Source.
Pour obtenir la liste exhaustive c'est ICI
Pour simplifier je vais lister ici quelques cvars avec pour chacune le fichier approprié où la mettre à jour ainsi que sa valeur par défaut entre parenthèses et un exemple de valeur conseillée.
Et dans l'ordre pour une config optimale
Configuration TECHNIQUE du serveur ( autoexec.cfg )
servercfgfile ( "server.cfg" )
Définit le fichier de configuration executé une et une seule fois au démarrage du serveur.
Exemple : servercfgfile "server.cfg"
mapchangecfgfile ( 0 )
Définit le fichier de configuration executé à chaque rotation de map et au démarrage du serveur aprés le servercfgfile.
Exemple : mapchangecfgfile "server.cfg"
sv_lan ( 0 )
Définit l'accessibilité réseau du serveur.
sv_lan 0 = LAN et extra LAN ( internet )
sv_lan 1 = LAN uniquement
Exemple : sv_lan 0
sv_downloadurl ( "" )
Définit l'url http de remplacement pour les téléchargements clients.
Exemple : sv_downloadurl "http://perso.wanadoo.fr/dan.web/cstrike/"
motdfile ( "" )
Définit le nom du fichier motd ( pour utiliser un autre que motd.txt ).
Exemple : motdfile "indexCSS1.html"
Remarque : A priori le type de fichier peut être .txt ou .html ( plus explicite ) et ce fichier doit se trouver à la racine du serveur ( cstrike ) sinon préciser le chemin ( motdfile "cfg/motd.cfg" par exemple ... ).
fps_max ( 300 )
Paramètre de définition du rate serveur à atteindre en fps ( "frame par secondes" ).
Un fps_max trop grand peut utiliser plus de CPU que la normal, mais cette valeur joue sur le ping des joueurs, plus il est haut plus le ping est bas.
On détaillera un peu plus la gestion du fps_max / ticrate par la suite. Cette valeur est sensible en fonction de l'OS et demande un peu de pratique pour l'optimiser.
Exemple : fps_max 1000
Configuration de la JOUABILITE du serveur ( server.cfg )
hostname ( "Counter-Strike Server" )
Définit le nom du serveur qui apparait dans la liste Steam.
Exemple : hostname "Mon serveur qu'il est beau"
sv_password ( 0 )
Définit le mot de passe de connection ( Aucun par défaut ).
Exemple : sv_password toto
rcon_password ( 0 )
Définit le mot de passe pour utiliser la fonction rcon ( Aucun par défaut ).
Exemple : rcon_password toto
pausable ( 0 )
Active (1) ou désactive (0) la pause du serveur.
Exemple : pausable 0
sv_aim ( 0 )
Active (1) ou désactive (0) la visée automatique ( Non accessible en multi-joueur )
Exemple : sv_aim 0
sv_cheats ( 0 )
Active (1) ou désactive (0) les commandes/cvars de cheats.
Exemple : sv_cheats 0
allow_spectators ( 0 )
Autorise (1) ou non (0) les spectateurs.
Exemple : allow_spectators 1
log ( 0 )
Active (1/on) ou désactive (0/off) les logs HLDS
Exemple : log on
mp_logdetail ( 0 )
Définit le niveau de détail des logs (0, 1, 2 ou 3)
Exemple : mp_logdetail 3
sv_contact ( 0 )
Permet de préciser un "contact" pour le serveur. On peut y mettre la châine que l'on veut comme le mail de l'admin suprême ou tout simplement l'url de la team.
Exemple : sv_contact "http://www.cs-amx.com"
sv_region ( -1 )
Définit la zone d'influence du serveur. 3 = Europe.
Toutes les valeurs de sv_region :
0: USA Cote Est
1: USA Cote Ouest
2: Amerique du sud
3: Europe
4: Asie
5: Australie
6: Moyen Orient
7: Afrique
A ne pas oublier si on veut apparaitre correctement dans la liste Steam filtrée sur Europe.
Exemple : sv_region 3
sv_alltalk ( 0 )
Définit si tout le monde parle à tout le monde au micro (1) ou uniquement dans l'équipe (0).
Exemple : sv_alltalk 0
Configuration du GAMEPLAY du serveur ( game.cfg )
mp_timelimit ( 20 )
Définit le temps de rotation des maps en minutes.
Exemple : mp_timelimit 35
mp_roundtime ( 5.0 )
Définit le temps d'un round en minutes ( Maximum = 10.0 minutes ).
Exemple : mp_roundtime 3.5
mp_startmoney ( 800 )
Définit la somme d'argent ( en $ ) disponible dés la connection et en début de map.
Exemple : mp_startmoney 2000
mp_friendlyfire ( 0 )
Active (1) ou désactive (0) le friendlyfire ( tir ami ).
Exemple : mp_friendlyfire 1
mp_fadetoblack ( 0 )
Lorsqu'il est activé (1) on obtient un écran noir lorsqu'on meurt ( ou en spectateur ) avec un joli effet de fondu. Le mettre à 0 pour le désactiver.
Exemple : mp_fadetoblack 0
mp_forcecamera ( 0 )
Définit le type de caméra en mode spectateur, lorsqu'on meurt.
0 : On peut tout voir.
1 : On ne peut voir que les joueurs de sa propre équipe.
2 : La caméra reste là ou l'on est mort.
Exemple : mp_forcecamera 1
mp_flashlight ( 0 )
Active (1) ou désactive (0) la lampe torche.
Exemple : mp_flashlight 1
mp_freezetime ( 6.0 )
Définit le temps en secondes de "freeze" en début de round.
Exemple : mp_freezetime 3.0
mp_c4timer ( 45 )
Définit le temps en secondes avant explosion de la bombe une fois posée.
Exemple : mp_c4timer 35
mp_chattime ( 10 )
Définit le temps disponible ( en secondes ) pour chatter en fin de map avant la rotation.
Exemple : mp_chattime 10
mp_buytime ( 1.5 )
Définit le temps d'achat en minutes de début de round.
Exemple : mp_buytime 0.25
mp_hostagepenalty ( 5.0 )
Définit les pénalités otages avant kick pour avoir tué trop d'otages.
Exemple : mp_hostagepenalty 0
mp_limitteams ( 2 )
Définit la différence de joueurs autorisée entre les deux équipes.
Exemple : mp_limitteams 1
mp_autoteambalance ( 1 )
Actives (1) ou non (0) l'équilibrage automatique des équipes.
Exemple : mp_autoteambalance 1
mp_tkpunish ( 1 )
Active (1) ou désactive (0) le TK punish ( mort au round suivant ).
Exemple : mp_tkpunish 1
mp_autokick ( 0 )
Active (1) ou désactive (0) le kick automatique des afk ( joueurs immobiles )
Exemple : mp_autokick 1
Configuration de la BANDE PASSANTE du serveur ( server.cfg )
sv_minrate ( 0 )
Définit la bande passante minimum ( en octets/secondes ) distribuée à chaque joueur avec kick pour ceux qui ne pourrait pas gérer au moins cette valeur. Pour éviter les "High Ping Killers" mettre une valeur non nulle pour être sûr que le joueur ne triche pas avec ses rates.
Exemple : sv_minrate 3000
pour un serveur sur le net ( limite pour autoriser aussi les 56 K qui ont un rate max aux alentours de 4000 ( 4 Ko/sec. ) )
Exemple : sv_minrate 8000
pour un serveur en LAN ( limite pour éviter les petits malins qui trichent avec les rates, sachant qu'en LAN on n'a aucune raison valable de limiter son maxupdaterate client ( cl_updaterate ) )
et aussi pour ne pas autoriser ls 56k sur le net par exemple.
sv_maxrate ( 0 )
Définit la bande passante maximum ( en octets/secondes ) distribuée à chaque joueur. A configurer en fonction de la bande passante disponible. La baisser pour une configuration de jeux entre amis sur internet avec son propre PC sauf si votre upload est conséquent.
Exemple : sv_maxrate 20000
pour un serveur en LAN ou Internet large bande.
Exemple : sv_maxrate 10000
pour un serveur sur Internet avec bande passante limitée par exemple.
Pour le maxrate faire en fonction de l'upload disponible du serveur.
Un joueur utilise environ 4Ko/sec soit 4000 octets/sec.
Pour un ulpoad à 256 Kbits/sec ( = 256/8 = 32 Ko/sec. ) , on ne pourra gérer que 8 slots en théorie car 32 Ko/sec = 8 * 4 Ko/sec.
sv_minupdaterate ( 10 )
Définit le taux de rafraichissement minimum alloué à chaque joueur avec kick pour ceux qui ne pourrait pas gérer au moins cette valeur. Pour éviter les "High Ping Killers" mettre une valeur non nulle pour être sûr que le joueur ne triche pas avec ses rates.
Exemple : sv_minupdaterate 10
c'est le minimum pour pouvoir jouer normalement.
sv_maxupdaterate ( 30 )
Définit le taux de rafraichissement maximum alloué à chaque joueur. A configurer en fonction de la bande passante disponible et surtout du sv_maxrate. Pour un sv_maxrate à 7000 redescendre le sv_maxupdaterate à 60 par exemple. Cela vous évitera des lags intempestifs.
Exemple : sv_maxupdaterate 101
il n'y a pas toutes les cvars, mais les essentielles sont là.
Juste en passant : Quelques astuces pratiques
L'art du echo :
Cette fonction est pratique pour savoir ou l'on est et ce que l'on fait. La commande echo affiche dans la console ce qu'on lui passe en paramètre.
Par exemple à la fin de server.cfg je place echo server.cfg - OK du coup on verra ce petit message server.cfg - OK dans la console au démarrage du serveur et à chaque fois qu'il sera executé. Cela permet de vérifier qu'il s'execute bien.
Mais cela permet d'afficher aussi des rappels de configs : echo sv_lan 1 pour ne pas oublier certaines configurations "critiques".
Grâce au echo on peut traquer tout ce qui se passe au niveau des .cfg executés, et cela permet d'être sur que les .cfg sont bien executés comme on le pense.
Indispensable
Par exemple, cela permet de voir que pour un serveur non paramétré ( par défaut ) le server.cfg n'est executé qu'une et une seule fois si on n'a pas spécifié le mapchangecfgfile et aussi que game.cfg est executé sans rien faire à chaque rotation de map.
Le exec c'est bien pratique :
Cette commande permet d'executer des fichiers cfg dans un cfg justement. Elle permet de déplacer certaines configurations dans un autre cfg pour rendre ce fichier plus pertinent. Par exemple mettre toutes vos configurations de bots dans bots.cfg et placer dans game.cfg : exec bots.cfg, vous récupérerez des bots tous beaux tous neufs à chaque rotation de map.
Pour Source le exec cherche les fichiers à executer dans cstrike/cfg, si le fichier est ailleurs, préciser le chemin ( Exemple : exec ../config/addons.cfg, pour executer : cstrike/config/addons.cfg )
A vos exec, caybon mangezen
Le ticrate, comment procéder ?
Par ou commencer ? ... Déja se demander si la machine va supporter des ticrates élevés.
Lorsqu'on joue avec le ticrate on peut avoir de drôles de surprises comme des lags/freezes extrêmement désagréables.
L'inconvénient c'est que pour trouver des valeurs optimales il faut aller chercher les limites et donc parfois pourrir le serveur.
Le ticrate est le nombre de "situations" calcuées par secondes par le serveur. Plus il en génère un maximum, plus il peut en envoyer aux joueurs et plus la qualité du jeu s'en ressent.
L'inconvénient, le CPU travaille forcément plus et votre bande passante peut être beaucoup plus sollicitée.
Comment connaître les FPS actuels d'un serveur ?
Pour ça une commande : ( rcon possible ) : stats.
Elle donne toutes les informations nécessaires pour surveiller sa machine serveur : la charge CPU, les "rates", le "uptime", les joueurs connectés et enfin les FPS.
Comment connaître la valeur courante du fps_max d'un serveur ? Pour ça taper dans la console ou en rcon : fps_max. Vous obtiendrez : "fps_max" = "XXXX"
Les FPS représentent le résultat du ticrate. Par défaut fps_max est configuré à 300 mais vous n'aurez guère plus de 130 fps. La valeur résultante est toujours inférieure à celle paramétrée et il n'y a rien à faire.
Pour un ticrate à 1000 on n'obtient pas plus de 512 fps et c'est déja beaucoup ...
Du coup viens la question : quelle valeur de FPS est optimale ?
Je répondrais celle qui fait que le serveur à le plus faible et stable ping
Ce qui rentre en compte ici c'est le sv_maxupdaterate du serveur, il représente le nombre de mise à jour par secondes maximum qu'un joueur peut obtenir. Plus vous mettez un sv_maxupdaterate élevé et plus il devient indispensable d'améliorer les fps. Les fps représente un peu la puissance ou le débit potentiel du serveur. Plus il génère de fps et plus il les distribue rapidement en respectant le sv_maxupdaterate, ce qui bénéfice au ping des joueurs.
Pour manipuler le ticrate préférer un serveur plein, même si ça va géner un peu les joueurs. Mettre une valeur énorme comme fps_max 1000 et voir l'impact sur le serveur.
Si tout fonctionne correctement laisser un petit moment et surveiller le serveur à l'aide de la commande stats. Si la CPU dépasses les 80 % ce n'est pas bon, il faut le réduire ...
Le fait que tous les joueurs soient groupés dans une zone peut faire que la CPU grimpe en flèche. 150 FPS est une valeur raisonnable. Ne pas avoir les yeux plus gros que le ventre.
Le plus fiable est de d'abord stabiliser les FPS à 150, et augmenter fps_max progressivement pour tenter de l'améliorer, mais dés que des lags/freezes ou autres parasites arrivent, revenir au fps_max précedents. On peut obtenir ainsi un fps_max optimal.
Un fort fps_max sollicite beaucoup le système et sur certains OS les réactions peuvent être trés variées.
Les noyaux linux sont par exemple prévus avec des fréquences précises et un mauvais paramétrage de ticrate peut engendrer des problèmes de noyaux et ne favorisera pas la qualité du serveur.
Sous windows les FPS bloquent à 60 tant que l'on n'a pas lancé un Mediaplayer. Toujours penser à en lancer un même sans vidéo avant de lancer un serveur Source sous windows si on veut jouer avec le ticrate/fps_max.
Voila il ne vous reste plus qu'à tester votre fps_max.
Mais dans la plupart des cas les valeurs par défaut sont les plus stables, donc toute modification de fps_max se fait à vos risques et périls, et votre hébergeur peut ne pas apprécier ce genre de configuration surtout pour des serveurs mutualisés ...
Les fps caybon may en abusay ssa crein
Bon c'est bien tout ça mais comment je le lance mon serveur moi ?
Finir en beauté : Lancer son serveur avec Staïle
La ligne de commande :
Aussi bien pour Linux que Windows les paramètres minimaux à passer sont : le mod, la map, le nombre de joueurs et le port.
On peut passer d'autres paramètres (sv_lan, servercfgfile ... ) mais vu que l'on peut aussi les mettre dans autoexec.cfg, je ne détaillerais pas toutes les possibilités.
Petit ajout de dernière minute : La mise à jour du serveur
Soit vous la faites seul ( serveur pas toujours OnLine ) à l'aide de HLDSUpdateTool, soit vous activez l'auto-update dans la ligne de commande en ajoutant : -autoupdate.
Linux = srcds_run -game cstrike +map de_dust2 +maxplayers 16 +port 27030 -autoupdate
Windows = srcds.exe -game cstrike +map de_dust2 +maxplayers 16 +port 27030 -autoupdate
En passant, pour désactiver le VAC rajouter : -insecure
Mais vous allez me demander comment rendre tout ça un peu plus automatique ?
Et bien c'est ce que l'on va voir dans la suite.
Windows : To Batch or not To Batch ... That is the question ...
Windows dispose d'une fonction appelée "batch". Le principe est de réaliser des commandes/scripts en un clic. Cela passe par la description des commandes dans un fichier "batch". Ce fichier n'est rien d'autre qu'un fichier texte dans le quel on écrit les commandes à réaliser, et dont l'extension est .bat. Ce fichier devient alors executable par un simple double clic.
Il suffit donc de créer ce fichier .bat à coté de srcds.exe et d'y inscrire la commande à executer. Pour modifier un .bat faire simplement un clic droit dessus, vous aurez l'option "modifier".
Exemple, on va créer un fichier startCSS.bat vide que l'on place prés de srcds.exe. Pour le créer faites un clic droit dans le dossier de srcds.exe et faites "Nouveau - Fichier texte". Nommez le startCSS.bat. Vérifiez bien que vous affichez les extensions des fichiers.
Faites "Modifier" le fichier, et placez y votre commande :
srcds.exe -game cstrike +map de_dust2 +maxplayers 16 +port 27030 -console
Enregistrez le fichier et essayez de double cliquer dessus. Le serveur devrait se lancer.
Je conseille trés fortement sous Windows, de rajouter -console pour lancer le serveur en mode console pure, bien plus léger en ressources.
Vous pouvez maintenant placer un raccourci sur votre bureau ou là où bon vous semble pour lancer votre serveur.
Sous Windows, l'idéal pour un serveur, est de le lancer en "priorité haute", il utilisera ainsi un peu mieux les ressources du PC. On peut le réaliser automatiquement dans le .bat. Il suffit de rajouter : start /high devant la ligne de commande. Ainsi votre serveur démarrera automatiquement en mode "prioritaire".
On peut remplacer le /high par /realtime qui élève encore un peu plus la priorité du serveur. Il est alors au même niveau que le noyau Windows lui même. Sur les bonnes machines récentes cela ne pose auccun problème.
La ligne de commande devient alors :
start /high srcds.exe -game cstrike +map de_dust2 +maxplayers 16 +port 27030 -console -autoupdate
Petites astuces :
- Placer juste avant : @echo off , cela masquera les affichages inutiles ( Plus de prompt ).
- Rajouter /min , cela minimisera la console dés le démarrage. Le placer juste aprés le /high.
- Utiliser le GOTO pour obtenir un "restart" auto :
| Citation : :BEGIN echo Demarrage Serveur start /wait ... echo ------------------- Redemarrage ... GOTO BEGIN |
Vous devez donc avoir dans votre fichier startCSS.bat :
| Citation : @echo off :BEGIN echo Demarrage Serveur start /high /min /wait srcds.exe -game cstrike +map de_dust2 +maxplayers 16 +port 27020 -console -autoupdate echo ------------------ Redemarrage ... date /T time /T GOTO BEGIN |
La date /T affiche la date, time /T l'heure, cela permet de garder une trace des relances
Vous disposez donc d'un batch de lancement de votre serveur avec auto redémarrage. Vous pouvez le modifier/adapter selon vos besoins car il est bien plus souple q'un raccourci banal Windows. Pour arrêter le tout tuer la fenetre principale ( ou arrêter le porcessus cmd.exe associé ).
Par exemple, si vous voulez démarrer le serveur au démarrage de votre session, glisser un raccourci vers ce batch dans "Démarrer/Programmes/Démarrage". Hop le tour est joué.
Pour les spécialistes l'idéal est d'utiliser un "Service Windows", mais là il vous faudra des outils spécialisés de gestion de service, comme FireDaemon, mais la commande contenue dans le batch peut être conservée et reste adaptée à un Service Windows.