|
|
| Line 1: |
Line 1: |
| __toc__ | | __toc__ |
|
| |
|
| == Format ==
| | Le format de fichier AFS permet de packer un ensemble de fichier dans un seul et unique fichier. Il n'y a pas de compression. Tous les éléments (fichiers, et blocks système de l'afs) sont alignés sur des blocks de 0x800 octets. En dehors des fichiers, l'afs est en little endian. |
|
| |
|
| == Nommage des fichiers ==
| | Un AFS se compose de 4 parties : |
| Fichiers compris dans afs_data.afs :
| | # Le header (4 octets avec le magic number "AFS\x00", 4 octets pour le nombre total de fichiers) |
| {| class="wikitable"
| | # La Table Of Content (TOC) : |
| |-
| | * un tableau avec pour chaque fichier - offset fichier (4 octets), taille fichier (4 octets). |
| ! Nom
| | * Ensuite, 3 cas sont alors possibles : |
| ! Description
| | ## soit tout de suite après ce tableau, on retrouver l'offset de la filename directory (4 octets) et sa taille (4 octets) |
| |-
| | ## soit on retrouve un padding (NULL bytes) avant de trouver la filename directory (4 octets) et sa taille (4 octets) |
| | pl####.pzz
| | ## soit il n'y a tout simplement pas de filename directory (pas d'offset ni de taille) |
| | Décrit chaque borg ('''Pl'''ayer Character)
| | # La partie qui contient l'ensemble des fichiers |
| |-
| | # Le Filename Directory qui se constitue, pour chaque fichier, de : |
| | mnxxxx.tpl
| | * 32 octets : Le nom du fichier paddé avec des NULL bytes |
| | Noms des borgs dans les '''M'''e'''n'''us (206)
| | * 2 octets : année |
| |-
| | * 2 octets : mois |
| | st##.pzz
| | * 2 octets : jour |
| | Comprennent en position 1,2,3 les fichiers hitsxx.bin
| | * 2 octets : heure |
| |-
| | * 2 octets : minute |
| | firstld.pzz
| | * 2 octets : seconde |
| | Utilisation liée à la carte mémoire ('''First l'''oa'''d''' - Image de la carte mémoire inclue dans le pzz)
| | * 4 octets : La taille du fichier |
| |-
| |
| | icon.bin
| |
| | Identique à firstld\003C_firstldicon.bin - Icone 3D pour l'image de la carte mémoire
| |
| |-
| |
| | facexxxx
| |
| | Décrivent les NPC du jeu et les prop utilisé lors de la touche spécial
| |
| |-
| |
| | itxxxx_mdl.arz
| |
| | (90 fichiers) - '''It'''em Data Crystal -> le numéro xxxx correspond à chaque fois à un borg qui demande plusieurs Data Crystal
| |
| |-
| |
| | setxxxx.arc
| |
| ! (61 fichiers) ?
| |
| |}
| |
| | |
| L'investigation mené par la communauté de [https://zenhax.com/viewtopic.php?t=13419 GioGio Bizarre Adventure] montre une certaine logique qui peut potentiellement être utilisée dans le nommage des fichiers interne de afs_data.afs :<br>
| |
| <br>
| |
| '''d#####.pzz''' - Character and/or prop data for 3D Cutscenes
| |
| '''pl##p.pzz''' - Character specific props
| |
| '''pl##.hit''' - Character collision data
| |
| '''st###.pzz''' - Stage model data
| |
| | |
| Fichiers absents :
| |
| files containing "'''tbl'''" in the filename seem to be animations
| |
| '''ga00p''' - Gallery room (several textures and models in here
| |
| '''ball.pzz''' - Seems to just be a sphere model with a 32x32 blank texture
| |
| '''re00.pzz''' - Results screen
| |
| '''dcomn.pzz''' - Speech bubbles, onomatopoeia, zoom lines and others
| |
| '''ld###.pzz''' - Loading screen model and textures (they're just planes)
| |
| '''demo.pzz''' - Title screen textures (can be used to decompress data)
| |
| '''se###.pzz''' - Stage props
| |
| '''lw###.pzz''' - Stage collisions
| |
| '''npc###.pzz''' - NPC files
| |
| '''ks##.pzz''' - 2D Drama cutscene data (panels are 3D models)
| |
| '''k###.pzz''' - 2D cutscene data (panels are 3D models)
| |
| | |
| === Observations ===
| |
| | |
| Pour chaque borg on a :<br>
| |
| plxxxx.pzz
| |
| plxxxxdata.bin <- position 0 du pzz (fichier pouvant être nommé data2 ou data3, parfois absent de l'afs_data)
| |
| plxxxxhit.bin <- position 2 du pzz (toujours présent dans l'afs_data et le pzz)
| |
| plxxxxmot.bin <- position 3 du pzz (souvent absent de l'afs_data)
| |
| plxxxx_mdl.arc <- position 4 du pzz (parfois absent de l'afs_data)
| |
| plxxxxb_mdl.arc <- position 5 du pzz (parfois absent de l'afs_data)
| |
| plxxxxg_mdl.arc <- position 6 du pzz (parfois absent de l'afs_data)
| |
| plxxxxs_mdl.arc <- position 7 du pzz (parfois absent de l'afs_data)
| |
| plxxxxc_mdl.arc <- position 8 du pzz (parfois absent de l'afs_data)
| |
| plxxxxk_mdl.arc <- position 9 du pzz (parfois absent de l'afs_data)
| |
| | |
| | |
| Position 000 : pour pl0604 et quelques autres borgs il s'agit de pl0604data2.bin ou plxxxxdata3.bin (seul un des trois data est présent, jamais deux, et ce fichier data2 ou data3 est identique au fichier data du pzz->000). (Version NTSC)
| |
| | |
| Position 002 : pour le borg pl0507 et pl0513, le fichier 2 et le hit diffèrent. (Version NTSC)
| |
| | |
| | |
| Position 003 : pour le borg "pl0009", le fichier 3 et le mot diffèrent. (Version NTSC) (Mot - '''Mo'''uvemen'''t''') - On peux observer que pour ces fichiers, on retrouve des références pouvant faire penser à de l'animation '''plxxxx_xx_animjoint'''. L'investigation mené par la communauté de [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] montre une structure de fichier similaire. Il s'agit d'une autre version de HSD (Les structures de bases sont les mêmes).
| |
| | |
| Position 004 à 009 : contiennent '''"scene_data"''' en fin de section data, et sont des fichiers ''''"Scène"''' (HSDLib) qui contiennent les lumières, les caméras, les vertices, les bones à la manière d'un .blend.
| |
| | |
| pl0803 - pl080b - pl0f07 :
| |
| Il reste uniquement le fichier pl0803hit.bin et pl080bhit.bin et aucun de leurs fichiers associés (notamment, pas de pzz associé), ce qui indique qu'ils sont à priori des restes de borgs non implémentés ... De même que le pzz pl0f07 n'a pas son fichier hit, ni ses 4 TPL internes (4 fichiers vides à la place) mais juste son fichier pl0f07_mdl.arc, ce qui indique que ce borg n'est pas implémenté non plus. (Version NTSC).
| |
Le format de fichier AFS permet de packer un ensemble de fichier dans un seul et unique fichier. Il n'y a pas de compression. Tous les éléments (fichiers, et blocks système de l'afs) sont alignés sur des blocks de 0x800 octets. En dehors des fichiers, l'afs est en little endian.
Un AFS se compose de 4 parties :
- Le header (4 octets avec le magic number "AFS\x00", 4 octets pour le nombre total de fichiers)
- La Table Of Content (TOC) :
- un tableau avec pour chaque fichier - offset fichier (4 octets), taille fichier (4 octets).
- Ensuite, 3 cas sont alors possibles :
- soit tout de suite après ce tableau, on retrouver l'offset de la filename directory (4 octets) et sa taille (4 octets)
- soit on retrouve un padding (NULL bytes) avant de trouver la filename directory (4 octets) et sa taille (4 octets)
- soit il n'y a tout simplement pas de filename directory (pas d'offset ni de taille)
- La partie qui contient l'ensemble des fichiers
- Le Filename Directory qui se constitue, pour chaque fichier, de :
- 32 octets : Le nom du fichier paddé avec des NULL bytes
- 2 octets : année
- 2 octets : mois
- 2 octets : jour
- 2 octets : heure
- 2 octets : minute
- 2 octets : seconde
- 4 octets : La taille du fichier
