ievr-terminologie

name

ievr-terminologie

description

Vérifie tout terme technique d'Inazuma Eleven Victory Road avant de l'affirmer — noms de formats (G4TX, G4MD, cfg.bin, RDBN, T2B, CPK), extensions, codes internes de personnages et techniques (c01000010, waza), symboles reversés, adresses virtuelles, chemins VFS et noms de tables. À charger dès qu'une réponse doit nommer un format, un symbole, un chemin du jeu ou un identifiant IEVR, et avant d'écrire un tel nom dans du code, un commit ou une doc.

Terminologie IEVR — ne jamais deviner un nom

Les identifiants d'Inazuma Eleven: Victory Road sont opaques et se ressemblent : G4MD et G4MG désignent deux choses différentes, .g4nv porte le magic NAVM, un code personnage comme c01000010 n'a aucune structure devinable. Un nom inventé traverse ensuite le code, les commits et la base de connaissance sans que rien ne le signale.

Règle : aucun identifiant IEVR ne s'écrit de mémoire. Chacun se vérifie contre une source du dépôt, et la vérification est bon marché.

Ce qui doit être vérifié

Extensions et magics · noms de formats · codes de personnage et de technique · symboles reversés et adresses virtuelles · chemins VFS · noms de tables .cfg.bin · noms de crates et de familles nie-data.

Où vérifier, par nature de terme

Terme	Source de vérité	Comment
Format, magic, extension	crates/engine/nie-formats/src/lib.rs (enum FileFormat) et un module par format	Grep sur l'enum ; le module <fmt>.rs porte le parseur réel
Chemin VFS, existence d'un fichier	Le VFS lui-même (255 308 fichiers)	outil MCP vfs_search / vfs_stat, ou niers vfs find <sous-chaîne> -j
Personnage, technique	Miroir wiki	niers vfs chara <nom|id|code> · niers vfs waza <nom|id|code>
Symbole reversé, adresse	var/niers.sqlite	outil MCP re_function (par nom ou vaddr) ou re_query
Table / clé d'un .cfg.bin	Le fichier décodé	outil MCP asset_get avec decode: "cfg", ou probe_rdbn / probe_t2b
Famille de données portée	crates/engine/nie-data/src/	grep -rl "<MARKER_LIST>" crates/engine/nie-data/src/ — les modules portent des noms de concept, pas de format
Crate, chemin du dépôt	cargo metadata --no-deps	ne jamais déduire un chemin de crate de son nom

Tables de var/niers.sqlite (lecture seule, SELECT uniquement) : function, coverage, rtti_class, rtti_base, xref, str, pdata_func, hash_name, symbol, section, format, format_field, anchor, glob, hypothesis, binary, meta, func_const, func_str_ref, et la famille cam_* (caméra).

Comment répondre quand la vérification est impossible

Si la source est indisponible (VFS non monté, KB absente), le dire et donner la commande qui trancherait — jamais une réponse plausible non vérifiée. « Je n'ai pas pu vérifier X, la commande est … » est une bonne réponse ; un nom inventé n'en est pas une.

Quand une vérification contredit une hypothèse de départ, c'est la vérification qui gagne, y compris contre CLAUDE.md, une mémoire ou un commentaire du code : ces textes ont été écrits à une date, le VFS et la KB sont l'état présent.

Pièges avérés

• .g4nv a le magic NAVM : l'extension ne prédit pas le magic. Vérifier les deux.
• G4MD (métadonnées de modèle) ≠ G4MG (mesh) : deux modules distincts.
• Deux formats derrière .cfg.bin : RDBN à listes (cfgbin::is_rdbn → parse + read_values) et T2B en arbre (cfgbin::cfgbin_parse, CfgEntry). Tout common/property/** est T2B. Se tromper de branche donne un parseur qui « marche » et rend des valeurs fausses.
• Convention /tex : la route model-serve remplace .png par .g4tx — écrire …/x.g4tx.png est l'erreur classique. En voie FFI le chemin garde son .g4tx.
• Vfs::init() prend <racine>/data, pas la racine — sinon « impossible d'ouvrir cpk_list.cfg.bin », un message qui n'indique pas la vraie cause.
• niers vfs extract -o attend un fichier, pas un dossier : sinon « Accès refusé (os error 5) », qui n'a rien à voir avec des permissions.
• nie.exe est à la racine du dépôt, pas dans data/. Base image 0x140000000.
• Un retour conditionnel n'est pas une constante : porter un sete al / found ? 1 : 0 comme return 1 est une source classique de faux portages.

Précision numérique

Adresses virtuelles en hexadécimal avec le préfixe 0x et la base image réelle. Les colonnes d'adresse de la KB (vaddr, from_addr, to_addr) sont déjà rendues en hexadécimal par les outils MCP. Ne jamais arrondir ni « corriger » une adresse, un offset ou une taille : les reproduire tels quels, ou ne pas les citer.