Ce tutoriel est principalement dédié aux joueurs débutants et intermédiaires, même s’il recèle des astuces qui pourront être utiles à tous.

En effet, nous allons tenter d’exposer ici les principes de base dans la gestion de ses fichiers de configuration (ou “fichiers .cfg”). Si vous avez commencé à explorer un petit peu Urban Terror, vous avez sûrement eu l’occasion de vous lancer dans le merveilleux monde des CFG, donc vous savez peut-être déjà de quoi il retourne. Sinon, lisez bien ce qui suit attentivement !

I. Présentation et intérêt des fichiers de configuration 

À quoi servent les fichiers de configuration et où se trouvent-ils ?

Ceci sera peut-être un scoop pour vous, mais dans Urban Terror, absolument tout est paramétrable depuis les fichiers de configuration. Ces fichiers sont des fichiers de texte à l’extension en .cfg. Ils contiennent des suites d’instructions que le jeu va lire à chaque lancement et qui peuvent soit définir la valeur des variables, soit définir des “binds” voire des scripts complets très avancés. Inutile de le préciser : ces fichiers sont d’une importance capitale si vous voulez optimiser votre jeu à votre guise, et définir vos propres binds et scripts.

À l’installation, le jeu contient déjà un certain nombre de fichiers de configuration : server.cfg (qui ne sert que si vous lancez un serveur depuis votre propre machine), autoexec.cfg (qui sera détaillé ci-après) et q3config.cfg (idem). Attention, ne confondez pas avec des fichiers comme cyclemap.txt, qui comme son nom l’indique n’est pas un fichier .cfg mais un tout bête fichier texte, lui aussi utile uniquement dans le cas de la mise en place d’un serveur (il définit l’ordre des maps qui doivent être jouées). 

Voici où se trouvent ces fichiers, directement dans votre dossier q3ut4, c'est-à-dire :

• Windows XP : dans le dossier q3ut4 du répertoire d'installation (exemple : C:/Programs Files/Urban terror/q3ut4)
• Vista : dans le dossier ...Users/nom_compte_utilisateur/AppData/Local/VirtualStore/Program Files/UrbanTerror/q3ut4 [quand vous n'êtes pas en mode administrateur]
• Windows 7 : dans le dossier ...Utilisateurs/nom_compte_utilisateur/Local/VirtualStore/UrbanTerror/q3ut4 ou dans le dossier...Utilisateurs/nom_compte_utilisateur/AppData/Local/VirtualStore/Program Files (x86)/UrbanTerror/q3ut4 [pensez à afficher vos fichiers cachés]
• Mac OSX : dans le dossier .../Users/nom_compte_utilisateur/Library/Applications Support/Quake3/q3ut4/
• Linux : dans le dossier ~/UrbanTerror/q3ut4 [à supposer que ~/UrbanTerror est le dossier où vous avez décompressé le jeu].

Le dossier q3ut4 est le dossier où se trouvent donc tous vos fichiers .cfg, et c’est là que vous devrez placer tous les nouveaux fichiers que vous pourriez être amené à créer.

Pourquoi dois-je me passer de l’interface graphique du jeu ou de la console ?

Pour plusieurs raisons : tout d’abord, l’interface du jeu ne permet que de modifier les options de base du jeu. Il existe des dizaines et des dizaines d’autres variables très utiles qui ne peuvent être modifiées que par l’édition en brut de leur valeur. Ensuite, la console n’est pas non plus une bonne alternative (malgré l’avantage indéniable de l’auto-complétion) car vous ne pouvez travailler que sur une ligne à la fois. En bref, travailler ses .cfg avec un véritable éditeur de texte est beaucoup plus pratique, comme nous l’allons voir.

II. Concepts de base

Création d’un fichier .cfg

Je ne vais pas détailler la procédure pour chaque système d’exploitation, car cela reste très simple et que vous devriez être capable de l’adapter. Toutefois, n’hésitez pas à poser une question sur le forum si vous êtes en difficulté.

Pour créer un fichier de configuration, rien de plus simple, il vous suffit de créer un fichier texte, et de le renommer en quelquechose.cfg. Vous pourrez être amené à insérer des guillemets (comme ceci : “quelquechose.cfg”) afin de forcer le système à assigner l’extension .cfg.

N’oubliez pas non plus qu’il ne vous est pas possible de mettre des espaces ou des caractères spéciaux ou accentués dans vos noms de fichiers.

Contenu d’un fichier .cfg

Voici un exemple de fichier de configuration :

Vous remarquerez la structure : 

nom de la variable <espace> "valeur"

Ou :

instruction <espace> paramètre <espace> “action”

Les guillemets sont importants.

Exemple : bind & "ut_weaptoggle knife" 

(Où : “bind” est l’instruction [créer un bind], “&” est la touche à assigner et “ut_weaptoggle knife” constitue l’action à effectuer : ici, prendre le couteau).

C’est le schéma central. Vous pouvez en apprendre plus sur le scripting grâce à ce tutoriel.

Ne vous attardez pas sur la disposition particulière que voyez sur l’image, nous verrons cela par la suite.

Vous pouvez consulter la documentation du jeu et les divers tutoriels existants pour créer vos propres binds et régler vos cvars, car ce n’est pas l'objet de ce tutoriel.

Le cas particulier du q3config.cfg

Je me devais de faire une partie pour ce fichier. C’est le fichier de configuration qui contient TOUTE votre configuration. C’est un fichier généré automatiquement par le jeu, ce qui signifie que même s’il n’existe pas (parce que vous l’avez supprimé par exemple), il sera recréé automatiquement. Si vous changez quelque chose dans votre configuration, que ce soit par l’interface, la console, ou les fichiers .cfg, ces changements seront répercutés dans le q3config.cfg. En effet, c’est le seul fichier qui est "consulté" par le jeu pendant que vous jouez. Tous les autres fichiers ne sont lus ou exécutés qu’à son lancement, comme nous allons l’expliquer ci-dessus.

L’intérêt du q3config.cfg est sa génération automatique. Imaginons que vous avez fait une bêtise dans votre configuration et que vous ne savez plus quoi changer pour revenir à la situation initiale (le problème classique d’un problème OpenGL si vous avez testé une configuration qui empêche le jeu de se lancer graphiquement). Si vous supprimez le q3config.cfg, cela forcera le jeu à recréer le fichier avec tous les paramètres par défaut (comme lorsque vous avez installé le jeu la première fois). Bien sûr, veillez à ce qu’aucun fichier problématique ne se lance par le biais de l’autoexec.cfg. Déplacez momenténament ces fichiers hors du q3ut4 si besoin, ou modifiez l’autoexec.cfg en conséquence.

Attention !
Ne modifiez pas le fichier q3config.cfg directement. Comme il est d'ailleurs toujours indiqué en haut de ce fichier, ce fichier est généré automatiquement par le moteur du jeu. Vous ne devez pas y toucher et le laisser se générer automatiquement. L'exception à cette règle est l'astuce vue dans le paragraphe ci-dessus, à condition de bien savoir ce que vous faites.

Autoexec et unbindall

Ici réside un grand intérêt de la gestion de sa configuration par les fichiers. Tout d’abord, vous devez savoir qu’il y a un seul fichier qui est toujours exécuté par le jeu à son lancement : c’est le fichier autoexec.cfg (pour “automatic execute”). A chaque fois que vous lancez le jeu, toutes les instructions contenues dans ce fichier seront relues et exécutées. Et c’est là l’intérêt : si la variable contenue dans le q3config.cfg (qui est le fichier global de toute votre configuration comme vu plus haut) contient une valeur différente de celle indiquée par l’autoexec.cfg, le jeu va alors écraser la variable du q3config.cfg et la remplacer par la nouvelle, contenue dans l’autoexec.cfg.

L’unbindall prend ici un intérêt conséquent. C’est une commande native du jeu qui lui indique de supprimer tous les binds et scripts. En clair, si vous tapez /unbindall dans votre console en jeu, vous serez totalement bloqué et vous ne pourrez plus rien faire (bouger, tirer...).

Cela peut paraître absurde, sauf si on a l’idée de placer cette commande dans son autoexec.cfg, tout au début du fichier. Cela a pour conséquence qu’à chaque fois que vous lancez votre jeu, le moteur supprime tous les binds et scripts, et si l’autoexec.cfg en contient d’autres, il les recréera. En d’autres termes, à chaque fois, vous repartez avec une configuration “neuve”.

Maintenant, imaginez que votre autoexec.cfg contienne également toutes les variables du jeu telles que vous les avez définies... A chaque fois que vous lancez le jeu, tous vos binds sont réaffectés et vos variables sont réécrites, tels qu’indiqués par votre autoexec.cfg. Cela signifie que vous pouvez bidouiller ce que vous voulez dans le jeu, à chaque fois que vous quitterez et relancerez le programme, vous récupérez votre configuration telle quelle. Et ça, c’est vraiment pratique.

Toutefois, cela suppose d’avoir absolument TOUT écrit dans ses fichiers de configuration : les binds de contrôle de votre personnage, les messages radios, les scripts, et même les binds pour enregistrer une démo ou prendre un screenshot. Tout, tout.

Fort heureusement, toutes ces commandes sont indiquées dans la documentation du jeu (traduite en français). 

Si vous décidez d’adopter ce système, cela vous demandera simplement un certain temps pour réécrire votre configuration, mais une fois fait, vous ne la perdrez jamais ! Et si vous la sauvegardez sur une clé USB ou un serveur distant, alors là vous êtes sauvé à vie.

Gestion avancée : l’imbrication de plusieurs .cfg

Voyons maintenant comment optimiser encore ce système d’organisation de votre configuration.

Nous savons que l’autoexec est lu et exécuté à chaque lancemente du jeu. Utilisons ceci à notre avantage en nous servant de la commande exec.

Exec est une commande native également (à l'instar de “bind” ou “unbind” ou “unbindall”) qui indique au jeu d’exécuter un autre fichier de configuration. Ce fichier sera alors lu et exécuté.

Il suffit de l’utiliser comme suit :

exec nom_du_fichier.cfg

C’est tout bête. Si vous entrez cette commande dans la console par exemple, le fichier en question sera lu et exécuté par le jeu. Bien sûr, le fichier en question doit être contenu dans le dossier q3ut4.

L’idée est alors ici d’organiser toute sa configuration en la répartissant entre différents fichiers, ce qui facilite considérablement la gestion globale de votre config. Par exemple, moi j’ai :

• config.cfg, qui contient mes binds de déplacement, de gestion de mes armes, de mes items, les binds de screenshot et de prise de démo, etc.
• radio.cfg, qui contient respectivement un exec sur “ts.cfg”, ou “ctf.cfg”, ce qui modifie mes binds radios selon le mode auquel je joue ;
• souris.cfg qui contient les différentes variables relatives à la souris (sensibilité, accel, etc) ;
• reseau.cfg qui contient les différentes variables relatives au réseau ;
• cvars.cfg qui contient absolument toutes les variables du jeu que j’ai modifiées selon mes préférences ;
•  ... (et même un snake.cfg pour jouer un petit peu en attendant les respawns).

(NB : C’est aussi comme ça qu’on peut exécuter un script de lecture de démos comme un player.cfg).

Ainsi, mon autoexec.cfg ressemble à ça :

unbindall
exec config.cfg
exec radio.cfg [qui lui-même exécute ctf.cfg par défaut]
exec souris.cfg
exec reseau.cfg
exec cvars.cfg
...

Avec ceci, à chaque lancement du jeu, le moteur supprime toute ma configuration (qui avait pu être modifiée lors de ma dernière session de jeu par exemple) et la réécrit de A à Z, en exécutant un à un tous les fichiers.

Avec ça, vous êtes sûr d’avoir toujours tous vos binds et votre configuration préférée sous la main à chaque fois que vous jouez, vous pouvez travailler sur vos fichiers et les avoir prêts à l’emploi pour la prochaine fois, etc. 

III. Organisation optimale 

Logiciels utiles

Si vous utilisez Notepad par exemple sous Windows pour éditer vos fichiers, vous verrez que cela est fastidieux. En effet, il peut être utile d’avoir des fichiers qui ressemblent à ça :

Sur cette image, vous avez un de mes fichiers de config (cvars.cfg). Comme vous le constatez, toutes les lignes sont indentées, le logiciel colorie les différents éléments, etc. L’indentation consiste à rajouter des espaces afin d’aligner les éléments selon leur catégorie, ligne par ligne. Ainsi, comme vous pouvez le voir, toutes les valeurs de variables sont alignées quelle que soit la taille du nom de la variable en question. Pour cela, il faut que le programme gère l’indentation par tabulation (la touche tab qui crée un alinéa) par rapport aux simples espaces (par la touche espace). D’autre part, les commentaires (voir ci-dessous) sont colorés différemment, ainsi que les instructions par rapport aux paramètres, etc.

Tout ceci simplifie considérablement l’édition de vos fichiers.

Voici les logiciels qui vous permettent d’obtenir ce résultat :

• Sous Windows : je n’en conseillerai qu’un : Notepad++. C’est un logiciel gratuit, qui se veut une amélioration substantielle du Notepad de base. Il sert pour de nombreux langages de programmation.
• Sous MacOS : il existe des logiciels simples comme Fraise ou TextWrangler qui sont un peu basiques, et des logiciels comme Coda, BBedit, ou Espresso qui sont plus développés. Cela dépend de vos préférences.
• Sous Linux : plus difficile de faire un choix, il en existe à profusion. Sachez simplement que Gedit (pour l’environnement Gnome) ou Kate (sous l’environnement KDE) sont de très bons logiciels. (Et NON, nano n’est pas adapté ici !). 

Comment bien rédiger ses .cfg 

C’est très simple. On a vu comment les créer, alors ouvrez-en un avec votre logiciel favori. Vous pouvez vous inspirer du screenshot plus haut. L’idée principale est qu’un fichier bien organisé est un fichier facile à modifier. 

Essayez de répartir vos lignes selon un point commun (si ce sont des binds radios, si ce sont les binds de déplacement, ou les instructions relatives à la prise de démo, etc.). Si vous faites ainsi, et que vous réouvrez votre fichier deux semaines plus tard, vous saurez parfaitement vous diriger au sein de votre fichier.

 Les commentaires

Si vous avez déjà fait de la programmation, vous savez sûrement à quoi ça sert et à quel point cela est utile. Sinon, les commentaires servent à rajouter des phrases qui ne sont pas lues par le jeu (elles sont totalement ignorées). Elles servent en fait à la personne qui va lire le fichier en question (l’être humain, quoi). Ceci est particulièrement utile pour expliquer la fonction d’une variable un peu obscure ou le fonctionnement d’un script particulièrement complexe. Vous vous y retrouverez ainsi vous-même dans votre propre code, et si vous passez vos fichiers de configuration à vos amis, ils ne seront pas perdus.

Sous Quake (et donc Urban Terror), vous pouvez rédiger un commentaire en le précédant un double slash : //.

Exemple :

// Ceci est un commentaire. J’aime le bind qui va suivre. 
bind SPACE “+moveup ; say Je suis ici : $location”  // Ceci est aussi un commentaire. Ce bind est vraiment très utile d’ailleurs. 

Vous pouvez rajouter ce commentaire soit en début de ligne, soit après une ligne de commande. Attention, n’oubliez pas que tout ce que vous mettez à droite d’un double slash ne sera pas pris en compte ! Il est donc impossible d’écrire une instruction, puis un commentaire, puis à nouveau une instruction sur la même ligne. Toute commande à droite d’un commentaire ne sera pas prise en compte, car elle sera considérée comme un commentaire en elle-même.

Vous pouvez également rajouter un double-slash au début d’une commande si vous voulez qu’elle ne soit pas exécutée par le jeu temporairement (si vous faites des tests par exemple).

Astuce : le CTRL + F

Une petite astuce : si vous cherchez une ligne en particulier (par exemple dans toutes vos cvars), utilisez le raccourci CTRL + F. Cette combinaison existe sur tous les systèmes d’exploitation et sur tous les logiciels d’édition (ou tous ceux que j’ai testés, ce qui en fait un certain nombre) et elle vous ouvre un petit champ de recherche où vous pouvez taper les premiers caractères de la ligne recherchée. Selon le logiciel, cela peut être plus ou moins poussé (coloration de toutes les lignes répondant à la recherche...).

Voilà, avez ça, vous devriez être en mesure d’organiser vos fichiers de configuration de façon à pouvoir travailler et les modifier facilement.