Cartes de TA: Kingdoms — .tnt + .ota + .crt + .kmp

Les cartes de TA: Kingdoms sont une variante du TNT (avec un autre mot IDVersion) accompagnée d'un ou deux fichiers de métadonnées, plus un format d'archive de campagne HPI v2 pour les missions solo. C'est nettement plus proche du modèle de carte de TA que ne le laissaient penser les anciennes notes de recherche sur les « BTM/BMP de hauteurs » : une vraie installation GoG de TA:K ne contient aucun .btm ni aucun BMP compagnon.

Le lecteur HPI v2 existant de kbot gère les archives .kmp de façon transparente. Le lecteur TNT de kbot reconnaît le mot de version de TA:K et décode l'en-tête, la carte des hauteurs par DataUnit, la grille de placage de textures (tables des noms de terrain et des offsets U/V), la grille de placement des éléments et sa table de noms, ainsi que la minicarte intégrée : de quoi rendre une carte complète en pleine résolution en composant les JPG de terrain externes et les sprites GAF des éléments. Cette page documente ce qui est vérifiable dans l'installation livrée, ainsi que les lacunes qui restent.

Les fichiers qui composent une carte TA:K#

Décompte sur le répertoire des cartes de l'installation GoG :

Une carte multijoueur typique est livrée sous forme de trio .tnt + .ota + .txt, parfois accompagné d'un fichier compagnon .crt. Les missions de campagne sont empaquetées dans des archives .kmp qui regroupent le même ensemble avec les scripts de mission.

# The HPI v2 reader handles .kmp transparently
kbot hpi list /path/to/tak/maps/adamantine\ gate.kmp -v
kbot hpi info /path/to/tak/maps/adamantine\ gate.kmp

.tnt — terrain de TA:K (TNT v2)#

TA:K reprend la structure TNT de TA mais incrémente le mot IDVersion. Vidage hexadécimal de abnar's terrace.tnt :

00000000: 00 40 00 00 20 01 00 00 e0 00 00 00 3a 00 00 00   .@.. .......:...
00000010: 34 00 00 00 34 fc 00 00 34 f4 02 00 16 00 00 00   4...4...4.......

Le premier uint32 vaut 0x00004000, contre 0x00002000 dans le TNT de TA. Le conteneur reste un en-tête suivi de sections adressées par pointeurs, mais TA:K n'est pas du tout un format de mosaïque de tuiles. Là où TA stocke une grille d'index de tuiles et une palette de graphismes de tuiles 32×32, TA:K stocke le terrain sous forme de grille de placage de textures qui renvoie à des textures JPG externes, plus une carte des hauteurs séparée et une grille de placement des éléments. Tout ce qui suit a été vérifié sur les 55 cartes livrées :

1. Width/Height comptent des DataUnits de 16 px, pas des pixels. Une carte « 15 × 15 » comme athri cay stocke Width = Height = 480 DataUnits → 480 × 16 = 7680 px de côté. La carte des hauteurs et la grille des éléments sont échantillonnées par DataUnit ; le terrain est échantillonné sur une grille plus grossière de Graphic Units de 32 px, exactement la moitié de la grille des DataUnits sur chaque axe (guW = Width/2).
2. L'en-tête est une suite de douze uint32 d'offsets et de nombres ; les noms de champs de TA n'en décrivent plus le contenu. Le tableau ci-dessous donne leur signification dans TA:K.
3. Les pointeurs de section sont absolus : chaque section se lit donc à partir de son propre pointeur et d'une longueur calculée.

La carte des hauteurs (0x10) compte un octet par DataUnit — un champ d'altitudes en niveaux de gris, pas une image en couleurs. Le terrain est reconstruit par placage de textures : pour chaque Graphic Unit, la table des noms de terrain (0x20) donne un fichier de texture (terrain/<name>.jpg, le nom étant écrit en hexadécimal minuscule sur 8 chiffres), et les tables U/V (0x24/0x28) donnent la sous-tuile 32×32 à copier depuis ce JPG en (u×32, v×32). La grille des éléments (0x14) est la couche de placement : un tableau Width × Height de uint16, dont chaque case est soit l'index d'un élément dans la table des noms, soit une sentinelle haute (≥0xFF00) qui signifie « aucun élément ici » ; la case DataUnit (x, y) d'un placement correspond au pixel de terrain (x×16, y×16). La table des noms (0x18) utilise la même disposition d'entrée de 132 octets que la table TileAnim de TA.

Le bloc de la minicarte fait toujours 126 × 126 dans tout le corpus livré et utilise le même octet de vide 0x64 que TA pour le remplissage autour des cartes non carrées.

Palette de la minicarte — une par royaume#

TA:K ne colore pas sa minicarte avec une palette globale unique. Chaque carte a son aperçu 126 × 126 précalculé avec la palette de textures du royaume auquel elle appartient — le champ kingdom= du .ota voisin (aramon / taros / veruna / zhon / creon). Rendre les mêmes index avec la palette d'un autre royaume (ou avec le PALETTE.PAL de TA) produit un bruit moucheté ; avec la bonne palette, on obtient une eau, des plages et un terrain naturels.

kbot tnt minimap déduit automatiquement le royaume du .ota voisin. Quand le .ota est absent (par ex. un .tnt libre), passez --kingdom <name> explicitement :

kbot tnt minimap "athri cay.tnt" -t mini.png          # auto: veruna
kbot tnt minimap loose.tnt --kingdom aramon -t mini.png

.ota — métadonnées de carte (TDF, en terrain connu pour l'essentiel)#

Le .ota de TA:K a la même forme TDF que celui de TA, avec plusieurs champs propres à TAK. Fichier complet de abnar's terrace.ota :

[GlobalHeader]
{
    Copyright=Copyright 1998 Cavedog Entertainment. All rights reserved.;
    missionname=Abnar's Terrace;
    missiondescription=9 x 7  4 Player  32MB;
    kingdom=veruna;          // ← TA:K-specific: the side the map "belongs" to
    numplayers=4;
    size=9 x 7;              // ← TA:K-specific: free-text size for the lobby
    memory=32 MB;            // ← TA:K-specific: ~RAM requirement for the lobby
    hasscenario=0;
    [Map Data]
    {
        Type=Network 1;
        aiprofile=DEFAULT;
        [specials]
        {
            [special0] { specialwhat=StartPos1; XPos=37;   ZPos=190; }
            [special1] { specialwhat=StartPos2; XPos=215;  ZPos=38;  }
            …
        }
    }
}

Tout le reste (StartPos1..N, aiprofile=, etc.) fonctionne exactement comme dans TA : la visionneuse OTA de kbot mount gère les deux sans modification.

.kmp — archives HPI v2 des missions de campagne#

Un .kmp est une archive HPI v2 renommée. Début de adamantine gate.kmp en hexadécimal :

00000000: 48 41 50 49 00 00 02 00 57 32 02 00 77 00 00 00   HAPI....W2..w...
00000010: 15 32 02 00 42 00 00 00 20 00 00 00 00 00 00 00   .2..B... .......
00000020: 53 51 53 48 …                                     SQSH…

C'est exactement la forme d'en-tête v2 (marqueur HAPI → version 0x00020000 → en-tête v2 de 24 octets → chunks SQSH). kbot hpi list, info et extract fonctionnent tous directement. Un .kmp contient en général :

• Le .tnt et le .ota de la mission
• Quelques GAF de cinématiques et de briefing
• Des fichiers COB de script de mission — TA:K réutilise le format COB (VersionSignature == 6) pour les scripts de mission, au lieu d'un langage de script distinct. Les 3 885 occurrences de l'opcode MISSION_COMMAND (0x10073000) dans l'installation d'origine de TAK se trouvent ici. Voir TA: Kingdoms — écarts du COB v6 et l'annexe C de cob.md pour le format binaire et le pool de chaînes de noms de sons propre à chaque COB, dans lequel les commandes de mission puisent par index.
• Parfois, des remplacements d'unités propres à la mission

.crt — script de scénario (unités, règles, déclencheurs)#

Un .crt porte la couche scriptée d'une carte : les unités placées avant le début de la partie, le moteur de règles par joueur qui pilote l'IA d'escarmouche et les objectifs de campagne, et les zones de déclenchement rectangulaires nommées auxquelles ces règles font référence. Les cartes multijoueur livrent un squelette vide (aucune unité, neuf emplacements de joueur vides, aucun déclencheur, 56 octets) ; les cartes de campagne et les cartes spéciales remplissent chaque section, jusqu'à ~120 Ko.

Tout le fichier est en little-endian et constitue une image directe des structures en mémoire du moteur : les enregistrements d'unités contiennent donc plusieurs champs de remplissage non initialisés.

En-tête#

abnar's terrace.crt (un squelette vide) commence ainsi :

00000000: 00 00 80 3f 00 00 00 00 00 00 00 00 09 00 00 00

1.0f, Unknown1 = 0, UnitCount = 0, puis le nombre de joueurs 9.

Enregistrements d'unités (568 octets chacun)#

Joueurs, règles, conditions, actions#

Après les unités, un uint32 donnant le nombre de joueurs (toujours 9) précède autant de blocs de joueur. Chaque bloc de joueur est un nombre de règles uint32 suivi d'autant de règles. Une règle se compose de :

• un nombre de conditions uint32, puis les conditions, chacune formée d'un opcode uint32 et de cinq emplacements d'argument de 64 octets ;
• un nombre d'actions uint32, puis les actions, chacune formée d'un opcode uint32 et de cinq emplacements d'argument de 64 octets.

Déclencheurs#

Un nombre de déclencheurs uint32, en fin de fichier, précède autant d'enregistrements de déclencheur. Chacun est un nom de 256 octets terminé par NUL, suivi de quatre bornes uint32 — Left, Top, Right, Bottom — en cases de carte. Les noms sont lisibles par un humain (The Hill, Player 1).

Outils#

kbot crt describe <map.crt> affiche la répartition par type d'unité, le nombre de règles et les zones de déclenchement ; ajoutez --verbose pour la liste complète des placements. L'outil MCP crt_describe renvoie les mêmes données en JSON.

Un fichier — cairbray coast landing.crt — a un en-tête décalé, modifié à la main, qui ne correspond pas à cette disposition ; l'analyseur le rejette avec une erreur claire plutôt que de le décoder de travers.

.txt — description libre#

Une chaîne ASCII d'une ligne, utilisée dans le salon. Par ex. abnar's terrace.txt : 9 x 7 4 Player 32MB (la même chaîne que le missiondescription du .ota). Les outils de création écrivaient probablement les deux lors de l'export ; le jeu semble afficher la valeur du .ota.

Travailler avec les cartes TA:K aujourd'hui#

Options pratiques, par ordre d'effort croissant :

1. Inspecter librement — kbot hpi list/info/extract fonctionne d'emblée sur les fichiers .kmp. .ota et .txt sont du texte brut.
2. Décrire une carte — kbot tnt describe <map.tnt> affiche l'en-tête TA:K, le royaume, les dimensions de la carte des hauteurs et du terrain, et une répartition des éléments.
3. Rendre une minicarte — kbot tnt minimap <map.tnt> -t mini.png exporte l'aperçu intégré de 126 × 126 en truecolor, en choisissant automatiquement la palette du royaume d'après le .ota voisin (à forcer avec --kingdom ; voir la note sur la palette plus haut).
4. Rendre la carte texturée complète — kbot tnt preview <map.tnt> --vfs <flattened-tak-root> -t map.png plaque sur le terrain les textures terrain/*.jpg de l'installation et compose le sprite GAF de chaque élément, ce qui produit la carte telle que le jeu la rend (athri cay → 7 680 × 7 680). La palette des sprites d'éléments est lue dans palettes/<kingdom>_features.pcx.
5. Rendre la carte des hauteurs — kbot tnt image <map.tnt> -t height.png n'a besoin d'aucune ressource externe ; il produit la carte des hauteurs par DataUnit en niveaux de gris (--features superpose des marqueurs de placement colorés par catégorie).
6. Réempaqueter une archive de campagne — kbot hpi pack ne produit aujourd'hui que du v1 : un .kmp réempaqueté ne se chargerait donc pas. Pour modifier un .kmp à la main, extrayez-le, modifiez les fichiers libres et utilisez un empaqueteur tiers qui gère le v2, en attendant que kbot sache écrire le v2.

Ce que kbot sait faire, ou pas encore, avec les cartes TA:K#

Les pull requests sont les bienvenues sur chacun des points ❌. La carte des hauteurs, la grille de placage de textures, la grille des éléments et la table des éléments étant toutes décodées, le terrain et les éléments s'affichent en pleine résolution ; il reste le chemin d'écriture, pour l'aller-retour des cartes TA:K modifiées, et l'empaquetage des .kmp v2.

Voir aussi#

• HPI — le conteneur d'archive v2 (un .kmp est un HPI v2 dont l'extension a été renommée).
• TNT — le format TNT de TA ; TA:K en reprend la structure avec un IDVersion 0x4000.
• TDF — le format selon lequel .ota est analysé.
• GAF — les fichiers d'animation .taf utilisés partout dans TA:K (cinématiques dans les archives .kmp).
• Interface de TA: Kingdoms — le format des widgets des menus et de l'interface (HUD).
• Glossaire — camp, carte des hauteurs.