Qu’est-ce qu’un fichier BSP ? En-tête, lumps et pakfile expliqués
Un fichier BSP est le format de map compilée du Source Engine. Voici sa structure : en-tête, lumps, lump d’entités et pakfile, et les outils pour l’ouvrir.
Un fichier BSP est la version compilée et prête à jouer d’une map pour le Source Engine, et donc pour Garry’s Mod. Il est produit lorsque les compilateurs prennent le fichier VMF éditable de l’éditeur Hammer et calculent la géométrie, la visibilité et l’éclairage. Le fichier contient presque tout ce dont un serveur et ses joueurs ont besoin pour charger la map : géométrie, entités, lightmaps et souvent des textures, des modèles et des sons embarqués.
Ce que signifie BSP et comment le fichier est créé
BSP signifie Binary Space Partitioning. C’est une technique qui découpe l’espace d’une map en un arbre de régions plus petites. Le moteur utilise cet arbre pour déterminer rapidement ce qui est visible et avec quoi un joueur entre en collision.
Tu construis une map dans Hammer sous forme de fichier VMF. C’est un fichier texte que tu peux continuer à modifier à tout moment. La compilation lance trois programmes à la suite : VBSP crée la géométrie et les entités, VVIS calcule la visibilité, VRAD calcule la lumière. L’article VBSP, VVIS et VRAD expliqués détaille les trois étapes. Le résultat est un unique fichier binaire en .bsp, optimisé pour le chargement, pas pour l’édition.
La structure : en-tête et lumps
Chaque BSP commence par un en-tête. Il contient :
- l’identifiant
VBSP, qui indique aux outils qu’il s’agit d’une map Source - le numéro de version du format (généralement 20 pour Garry’s Mod)
- un répertoire de 64 entrées, la table des lumps
- la révision de la map, c’est-à-dire le nombre de fois où le VMF a été enregistré avant la compilation
Un lump est un bloc de données qui a un rôle précis. Pour chaque bloc, la table des lumps indique où il commence dans le fichier et quelle est sa longueur. Les 64 emplacements ne sont pas tous utilisés. Les groupes les plus importants :
| Lump | Contenu |
|---|---|
| Entities | Liste texte de toutes les entités et de leurs propriétés |
| Planes, nodes, leafs | L’arbre BSP qui organise la map dans l’espace |
| Vertices, edges, faces | Les surfaces visibles |
| Brushes, brush sides | Les brushes, utilisés entre autres pour les collisions |
| Texinfo, texdata | Quelle surface porte quel matériau |
| Visibility | Les données de visibilité calculées par VVIS |
| Lighting | Les lightmaps calculées par VRAD |
| Données de displacement | Les surfaces de terrain déformées |
| Game lump | Tous les prop_static, entre autres |
| Pakfile | Une archive de fichiers embarquée |
Si une entrée de la table est fausse, par exemple parce qu’un bloc dépasse la fin du fichier, le fichier est endommagé. Cela arrive par exemple après un upload interrompu.
Le lump d’entités : du texte brut dans un fichier binaire
Le lump d’entités est du texte ordinaire. Chaque entité est un bloc entre accolades, composé de paires clé-valeur :
{
"classname" "info_player_start"
"origin" "0 0 64"
"angles" "0 90 0"
}
La première entité est toujours worldspawn, qui contient les réglages de base de la map, comme le nom de la skybox. Viennent ensuite les entités ponctuelles comme les spawns, les lumières et la logique, et les entités brush comme les portes et les triggers. Les connexions entre entités (inputs et outputs) y sont elles aussi stockées sous forme de texte.
Certaines entités ne figurent pas dans le lump d’entités, parce que le compilateur les absorbe : les prop_static atterrissent par exemple dans le game lump, et les func_detail deviennent une partie de la géométrie de monde.
Comme le lump est du texte brut, n’importe qui peut le lire avec des outils simples. Ça concerne les noms et la logique de ta map, et ça concerne la sécurité : une entité lua_run exécute du code Lua sur le serveur, alors que point_servercommand, qui envoie des commandes console dans d’autres jeux Source, est désactivée dans Garry’s Mod. Avant de mettre la map de quelqu’un d’autre sur ton serveur, ça vaut la peine de regarder cette section.
Le pakfile : du contenu custom dans la map
Le lump pakfile est une archive ZIP à l’intérieur du BSP. Il contient les fichiers que la map apporte avec elle : matériaux, textures, modèles, sons. Au chargement, le moteur les traite comme s’ils se trouvaient dans le dossier du jeu. Le moteur y écrit aussi, par exemple les textures de cubemap créées par buildcubemaps.
Le pakfile se remplit avec l’outil BSPZIP de Valve ou avec des utilitaires comme Pakrat, VIDE ou CompilePal. L’article Packer du contenu custom dans un BSP montre comment faire.
Tout ce qui se trouve dans le pakfile est livré à chaque joueur. Ça joue sur la taille du fichier, et ça veut dire que les fichiers packés par erreur deviennent publics.
Comment ouvrir un fichier BSP
- Hammer n’ouvre pas les fichiers BSP, seulement les VMF. Pour revenir en arrière, il te faut un décompilateur comme BSPSource. La décompilation BSP expliquée décrit ce que tu en obtiens.
- Voir le pakfile : VIDE, Pakrat ou GCFScape affichent les fichiers embarqués.
- Lire les entités : un éditeur d’entités comme Entspy, ou à défaut un éditeur de texte ou hexadécimal, affiche le lump d’entités.
- Contrôles automatisés : le Map Scanner de bspmarket.de vérifie la cohérence de l’en-tête, de la table des lumps et des offsets, repère les entités à risque et liste les fichiers du pakfile.
Pourquoi la structure compte pour le dépannage et la protection
Beaucoup de problèmes typiques se ramènent à une partie du fichier. Si un matériau n’est ni dans le dossier du jeu ni dans le pakfile, tu vois le fameux motif en damier. Si un lump dépasse une limite du moteur, la compilation échoue ou la map ne se charge pas. Si tu sais quelle section est responsable de quoi, tu trouves la cause plus vite.
Une propriété est décisive pour la protection d’une map : le moteur doit pouvoir lire le fichier, et chaque joueur qui rejoint ton serveur le reçoit. Un BSP ne contient donc rien qui reste secret longtemps. Les mesures de protection agissent sur la structure. Un fingerprint rend une copie traçable, l’obfuscation réduit les informations qui ne servent qu’à un éditeur. Protéger une map GMod des leaks en donne la vue d’ensemble.
Questions fréquentes
Puis-je ouvrir un fichier BSP directement dans Hammer ?
Non. Hammer travaille avec des fichiers VMF. Un BSP doit d’abord être décompilé, et le résultat est une reconstruction, pas le fichier de travail original.
Un fichier BSP est-il chiffré ?
Non. Le format est bien connu et lu par de nombreux outils. Le lump d’entités est du texte brut et le pakfile est une archive ZIP. D’après le wiki de Valve, GMod charge aussi des maps dont les lumps et le contenu du pakfile sont compressés en LZMA ; c’est de la compression, pas du chiffrement.
Pourquoi mon fichier BSP est-il si gros ?
Le plus souvent à cause des lightmaps, qu’une compilation en LDR et HDR stocke deux fois, et à cause du pakfile avec ses textures, modèles, sons et cubemaps embarqués. La table des lumps montre quel bloc domine, et la liste du contenu du pakfile quels fichiers prennent de la place.
Quelle version de BSP Garry’s Mod utilise-t-il ?
Les maps créées avec les outils de compilation habituels pour Garry’s Mod portent la version 20. Le numéro se trouve dans l’en-tête, juste après l’identifiant. D’après le wiki de Valve, le moteur de GMod lit aussi la version 21. D’autres jeux Source utilisent parfois d’autres versions, et même des maps portant le même numéro ne sont pas librement interchangeables entre les jeux.