Noms et versions des maps GMod : préfixe, nom de fichier, mises à jour
Nommer une map GMod : préfixe, nom de fichier, versions et pourquoi une mise à jour ne doit jamais garder l’ancien nom. Avec la liste des fichiers associés.
Une map GMod reçoit un nom de fichier composé de minuscules, de chiffres et de tirets bas, avec le préfixe du mode de jeu au début et un marqueur de version à la fin, par exemple rp_harbourtown_v2. Chaque modification publiée reçoit un nouveau nom. La raison : le client et le serveur identifient une map par son nom de fichier, et celui qui possède déjà un fichier sous ce nom n’en télécharge pas de nouveau. Si les deux fichiers diffèrent, la tentative de connexion se termine par un message d’erreur.
Préfixes : ce que GMod en fait réellement
Le préfixe est une convention, pas un interrupteur. Dans le code Lua livré avec le jeu, il est évalué à un endroit : le menu principal s’en sert pour ranger les maps dans des catégories, et il masque les maps qui commencent par sdk_, test_ ou vst_. La correspondance se trouve dans garrysmod/lua/menu/getmaps.lua. Là, le préfixe désigne tout ce qui précède le premier tiret bas, celui-ci inclus, et le nom est d’abord converti en minuscules. En plus, chaque mode de jeu peut déclarer ses propres motifs via la clé maps de son fichier texte. Sandbox déclare ^gm_|^gmod_|^phys_, TTT déclare ^ttt_.
| Préfixe | Catégorie dans le menu |
|---|---|
gm_, gmod_, phys_ | Sandbox |
ttt_ | Trouble in Terrorist Town |
rp_ | Roleplay |
zs_, zm_, zombiesurvival_ | Zombie Survival |
ph_ | Prop Hunt |
surf_ | Surf |
bhop_ | Bunny Hop |
de_, cs_ | Counter-Strike |
Tout ce qui ne correspond à aucun motif se retrouve sous « Other ». Tant que le mode de jeu Murder n’est pas installé, c’est aussi le cas de mu_ : le préfixe ne figure pas dans la liste livrée avec le jeu. Murder déclare lui-même ^md_|^mu_|^murder_ via sa clé maps. Le mode de jeu qui tourne sur un serveur est fixé par le paramètre de lancement +gamemode, pas par la map. Choisis le préfixe du mode pour lequel la map est construite.
Règles pour le nom de fichier
- Uniquement des minuscules. Linux est sensible à la casse, Windows non. Un
RP_Town.bspqui se charge sur ta machine n’est pas trouvé par un serveur Linux ou un serveur web FastDL sousrp_town.bsp. Lors de la création d’un addon Workshop,gmad.exesignale les majuscules par[Filename contains captial letters]. - Pas d’espaces, d’accents ni de caractères spéciaux. Le nom de la map est un argument de commandes console comme
changelevelet fait partie de l’adresse FastDL. Dans la console, un espace sépare les arguments, dans une adresse web il doit être encodé. Avecaàz,0à9et_, tu évites les deux. - Court et unique. Cet article ne donne pas de limite de longueur fixe, car aucune source fiable n’a pu être trouvée pour GMod. Si ta map porte le même nom qu’une map répandue de quelqu’un d’autre, tu obtiens le même conflit qu’avec deux versions sous un même nom.
- À décider avant de générer les cubemaps. Les cubemaps sont stockées dans le pakfile sous
materials/maps/<mapname>/. Voir corriger les cubemaps et les reflets.
Un schéma de versions qui tient dans la durée
Le moteur n’impose aucun marqueur de version. Les suffixes suivants relèvent de la pratique de la communauté :
| Suffixe | Signification | Usage |
|---|---|---|
_a1, _a2 | Alpha | tests de layout, pas encore de détails |
_b1, _b2 | Bêta | jouable, change encore |
_rc1 | Release candidate | considérée comme terminée, sauf si un autre bug apparaît |
_v1, _v2 | Release | versions publiées, numérotées à la suite |
_final | « final » | à éviter de préférence |
_final est un piège, car un autre bug apparaît souvent après la version finale. Le fichier suivant s’appelle alors _final2 ou _final_fix, et personne ne peut dire d’après le nom lequel est le plus récent. Pour la plupart des projets, _b1, _b2 pendant les tests puis _v1, _v2, _v3 suffisent.
Incrémente aussi le numéro pour les petites corrections, car chaque modification produit un fichier différent.
Ce qui se passe quand deux fichiers portent le même nom
À la connexion, le client vérifie s’il possède déjà maps/<mapname>.bsp. Si le fichier manque, il le télécharge et le stocke sous garrysmod/download/maps. S’il est présent, le client ne télécharge rien, et le moteur compare seulement la somme de contrôle avec celle du serveur. Si les deux diffèrent, la tentative de connexion se termine par un message de cette forme :
Your map [maps/rp_harbourtown_v2.bsp] differs from the server's.
Le joueur doit alors supprimer l’ancien fichier à la main, et très peu le savent. La même confusion se produit par d’autres voies :
- FastDL : L’espace web contient encore l’ancien
.bsp.bz2, alors que le serveur de jeu a déjà le nouveau BSP. Chaque nouveau joueur télécharge le mauvais fichier. - Workshop : Steam met automatiquement à jour les abonnés. D’après le wiki GMod, un serveur vérifie ses addons à chaque redémarrage. S’il tourne encore avec l’ancienne version, ou si
host_workshop_autoupdateest réglé sur0, le client et le serveur ont des fichiers différents portant le même nom. - Workshop et FastDL mélangés : Certains joueurs ont la map depuis le Workshop, d’autres depuis
download/maps. Avec un seul nom, personne ne peut dire qui a quelle version. - Données enregistrées sur le serveur : DarkRP enregistre les réglages des portes, les positions de jail et les spawns des jobs par nom de map, et les portes en plus par l’ID de l’entité de la map. Si une mise à jour sous le même nom modifie les entités, d’anciennes entrées peuvent pointer vers les mauvaises portes.
Un nouveau nom de fichier supprime tout cela : l’ancien fichier reste sur le disque du joueur mais ne gêne plus. La configuration du serveur, de FastDL et du Workshop est expliquée dans installer une map GMod sur un serveur.
Ce qui porte le nom de la map et doit être renommé avec elle
Renommer un BSP dans l’explorateur de fichiers ne suffit pas. D’après la Valve Developer Community, les modèles et les props perdent alors leurs reflets de cubemaps, car le moteur cherche les cubemaps dans le pakfile sous le nom de fichier du BSP. La méthode propre : renommer le VMF et recompiler. Ensuite, ces fichiers suivent le mouvement :
| Fichier | Contenu |
|---|---|
maps/<mapname>.nav | Navmesh pour les Nextbots |
maps/graphs/<mapname>.ain | Graphe de nodes pour les NPC classiques |
scripts/soundscapes_<mapname>.txt | Soundscapes de la map |
maps/<mapname>_level_sounds.txt | Soundscripts de la map |
maps/<mapname>_particles.txt | Manifeste de particules de la map |
maps/thumb/<mapname>.png | Miniature dans la sélection de maps |
maps/<mapname>_ttt.txt | Script d’armes et de spawns pour TTT |
S’y ajoute tout ce qui contient le nom sous forme de texte : la map de départ dans la configuration du serveur, les listes de vote de maps et le code Lua qui compare game.GetMap() à un nom fixe. Ne recopie pas le .ain, laisse le nouveau BSP le générer de zéro, comme décrit dans navmesh et AI nodes. L’ordre entre compilation, cubemaps, packing et test est présenté dans la checklist avant publication.
Changelog : ce que les acheteurs et les propriétaires de serveur y gagnent
Un nouveau nom de fichier donne du travail aux propriétaires de serveur : changer la map de départ, mettre à jour FastDL, redéfinir les positions. Un changelog leur dit si cela en vaut la peine. Les entrées utiles répondent à quatre questions :
- Qu’est-ce qui a été corrigé, qu’est-ce qui est nouveau ?
- Des portes, des spawns ou d’autres entités ont-ils changé, de sorte que les données enregistrées sur le serveur doivent être redéfinies ?
- Un contenu nouveau ou différent est-il requis ?
- Le navmesh et le graphe de nodes ont-ils été régénérés ?
Pour les acheteurs, l’historique des versions est aussi un signe que la map est entretenue. Sur bspmarket.de, tu soumets une nouvelle version dans l’espace Creator avec un numéro de version et un changelog optionnel. Elle est vérifiée avant publication et apparaît ensuite sur la page produit sous « Versions & changelog ». Les mises à jour sont gratuites pour les acheteurs. Ce qui fait par ailleurs une bonne page produit est expliqué dans vendre des maps GMod.
Questions fréquentes
Dois-je créer un nouvel élément Workshop pour chaque version ?
Non. Les règles du Workshop pour GMod recommandent de publier les nouvelles versions comme mise à jour de l’élément existant. Donne quand même au BSP qu’il contient le nouveau nom de version : ainsi, personne ne peut confondre deux versions, et les serveurs n’ont qu’à adapter leur map de départ. Dans tous les cas, un serveur ne récupère la mise à jour qu’à son redémarrage. D’après le wiki GMod, un serveur qui fait encore tourner une version plus ancienne de la map peut empêcher les joueurs de le rejoindre. La procédure est décrite dans publier une map GMod sur le Workshop.
Quel préfixe choisir si la map convient à plusieurs modes de jeu ?
Celui du mode pour lequel elle est construite en priorité. Le préfixe détermine la catégorie dans le menu et ce que les joueurs attendent. Une map rp_ peut tout de même être lancée en Sandbox.
Que faire des anciennes versions sur le serveur et sur FastDL ?
Supprime-les dès que le serveur est passé à la nouvelle version, y compris le .bsp.bz2 et les anciens fichiers .nav et .ain. Les anciennes copies sur les machines des joueurs ne posent pas de problème, car elles portent un autre nom.