JSD fichiers : structure et ouverture

Trois formats portent le même sigle, et pourtant ils n'ont rien en commun. Le terme JSD recouvre des réalités techniques radicalement différentes : un format binaire pour jeu vidéo, une bibliothèque embarquée développée par la NASA JPL, et un validateur JavaScript. Savoir lequel correspond à votre besoin change tout à la façon de l'ouvrir, de l'éditer ou de l'intégrer.

Structure interne des fichiers JSD pour Jagged Alliance 2

Le format JSD créé par Freedom Scientific pour Jagged Alliance 2 stocke les propriétés physiques des objets du monde de jeu. Chris Camfield, ancien développeur du titre, a confirmé que ces fichiers décrivent les données de structure, incluant la passabilité, la ligne de visée (LOS) et les valeurs de résistance. Concrètement, chaque fichier définit comment un mur, une porte ou une clôture occupe l'espace dans le moteur isométrique.

L'organisation binaire est rigoureuse. L'en-tête de 16 bytes s'ouvre avec l'identifiant magique "J2SD", suivi du nombre de structures, de la taille totale des données et d'un byte de flags déterminant le type. Les structures individuelles reposent sur deux blocs distincts :

Bloc	Taille	Contenu principal
DB_STRUCTURE	16 bytes	Armure (0-26), points de vie, densité (0-100), orientation mur (1-4)
DBSTRUCTURETILE	32 bytes	Offsets X/Y, forme 5×5, flags de collision, position véhicule
Données auxiliaires	16 bytes/image	Orientation, animations, flags AUXFULLTILE, AUXANIMATEDTILE

La forme de chaque tile repose sur un tableau 5 lignes × 5 colonnes, chaque case contenant une valeur de 0 à 15 qui code les cubes remplis. Les dimensions de rendu sont fixées à 40 pixels en largeur (WORLDTILEX) et 20 pixels en hauteur (WORLDTILEY). Les décalages z utilisent ces constantes pour calculer précisément la position des objets superposés.

Trois types de fichiers coexistent. Le Type 1 ne contient que des données auxiliaires (flag 00000001), le Type 2 uniquement des données structurelles (flag 00000010), et le Type 3 combine les deux. L'éditeur JSD disponible ne fonctionne qu'avec le Type 2, qui représente la majorité des fichiers. Pour convertir un fichier animé en Type 2 éditable, il faut supprimer les blocs 16 bytes d'animation et modifier le byte 7 de l'en-tête à la valeur 02. Les Types 1 et 3 exigent une édition manuelle en hexadécimal.

Bibliothèque JSD pour appareils EtherCAT : configuration et tests

La bibliothèque JSD développée par la NASA JPL est une couche C au-dessus de SOEM (Simple Open EtherCAT Master). Elle structure la communication avec des modules industriels et a été validée sur Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04, ainsi que sur Raspberry Pi. Franchement, si vous travaillez sur une plateforme non-POSIX, passez votre chemin : les mainteneurs ne la ciblent pas.

La construction requiert CMake version 3.11 minimum et des threads POSIX. La version recommandée est v3.1.6, à spécifier via FetchContent dans votre CMakeLists.txt plutôt que de pointer vers master. Les appareils supportés se répartissent en trois niveaux :

Tier 1 (depuis JSD 1.0.0) : EL2124, EL3208, EL3602, Elmo Gold Drives
Tier 2 (entre 1.1.0 et 1.8.0) : EL3356, EL1008, EL3162, EL3318, EL3104, EL4102, ATI Force-Torque Sensor, ILD1900
Tier 3 (depuis 3.1.5) : EL2798, EL2828, EL5042

Les Elmo Platinum Drives nécessitent au minimum la version 2.2.0. L'outil jsd_slaveinfo permet l'introspection des esclaves SOEM. Avec l'option -map, il liste les mappages PDO actifs : sur l'interface eth9, un appareil ELMO configuré expose par exemple 0x607A (position cible, INTEGER32) et 0x6040 (mot de contrôle, UNSIGNED16) sur le SM2 en sortie. Attention aux tests de périphériques de sortie comme l'EL2124 : ils génèrent des tensions potentiellement dangereuses.

L'outil jsdegdtlctty donne accès en ligne de commande aux paramètres Elmo Two-Letter Command. La syntaxe est directe : sudo jsdegdtlctty ifname egdslaveindex. Une commande comme "float CL[2] = 1.5" applique une valeur, tandis que "float CL[2]" effectue une requête. La conversion TLC utilise l'index 0x3191.

JSD comme validateur de schéma JavaScript : démarrage rapide

Troisième acception du terme : JSD (Javascript Schema Definition) est l'équivalent de XSD pour XML, mais appliqué aux objets JavaScript. Mark Homans, de Build-Software, en est le contributeur principal. La licence FreeBSD date de 2013. L'intégration se résume à une balise script incluant JSDValidator version 1.4, la création d'un schéma, et l'appel de la façon Validate(objet) qui retourne un booléen.

Un schéma typique définit un objet avec des attributs nommés, typés et contraints. Le champ "Gender" peut par exemple n'accepter que les valeurs ["M", "F"]. La différence fondamentale avec les autres usages du sigle JSD est ici la légèreté du déploiement : aucune dépendance système, aucun build complexe. Si vous cherchez comment améliorer la performance thermique d'une construction, la rigueur de validation de données structurées qu'offre cet outil illustre bien comment définir des contraintes claires dès la conception.

Pour contribuer au projet JSDValidator, Mark Homans est joignable à l'adresse mark@build-software.nl. Le dépôt est clonable via git sur le compte markhomans. Pour la bibliothèque SOEM, toute contribution doit utiliser une branche préfixée "USER-", appliquer le clang-format style Google avant tout pull request, et préfixer chaque enum, struct et fonction par "jsd_". Le versioning sémantique s'applique strictement : majeur pour les ruptures d'API, mineur pour les nouvelles fonctionnalités, patch pour les corrections.