Shit Fliez

[Fremen^SF]

Speedy et moi avons continué à déchiffrer le fichier SCENE.BIN hier soir et aujourd'hui. Pour rappel, on a à peu près trouvé tout ce qu'on pouvait dans la partie spécifique aux monstres (level, HP, objets, etc...) mais il restait encore un gros morceau au début de chaque "file", et un encore plus gros morceau après la description des monstres.

J'ai mis à jour la version du programme en mode console qui générait un fichier scenestats.txt "lisible", de sorte à pouvoir mieux comprendre à quoi servent ces autres données, en utilisant ce qu'on a pu découvrir. A noter que tout n'est pas commenté, mais on détaillera tout ça quand on aura fini de faire des tests, ce qui pourrait prendre encore pas mal de temps.

Le fichier SCENESTATS.TXT mis en forme : [TXT] (5.8Mo) (mise à jour du 5/10 4:30)

Par rapport à la version précédente, ont été trouvés :

- Les "formations" de combat, c'est à dire les groupes de monstres que l'on peut rencontrer dans le jeu, ainsi que leur disposition (coordonnées, première ligne/seconde ligne). Par exemple, le combat contre le Zolom est une formation, le combat contre deux poireaux, une autruche et un chocobo en est une autre. Sachant que chaque file ne peut pas contenir les caractéristiques de plus de 3 monstres, c'est pourquoi on n'a jamais affaire à des combats contre au moins 4 monstres différents.

- Les textes de chaque attaque spéciale des monstres, par exemple "Bêta", "Morsure", "Pistolet Mako". On a pu identifier aussi dans la description des monstres la présence d'un ID (un short int) qui correspond justement aux ID de ces textes.

- La présence de scripts à la fin de chaque file. Chaque bloc de scripts semble correspondre à un monstre, et chaque sous-bloc semble correspondre à l'une de ses attaques (on y retrouve d'ailleurs l'ID de chaque texte d'attaque, merci Speedy ^^) ou à un événement (par exemple, afficher "Chocobo capturé").
_________________

[Crashsound]

Et la soupe Knorr, elle fait une attaque Ducros avec ses poireaux, son autruche et son chocobo, qui d ailleur à une ID de texte de secours: quant il est dans la casserole il crit HELP ME!
C est beau la prog, ça nous améne à dire n importe quoi! Désolé Fremen mais la premiére fois que j ai lu ton post, nottement le premier point, je me suis écroulé de rire!
_________________
Labor omnia vincit improbus.

[Fremen^SF]

Crashsound : Il n'y a pas de mal, c'est vrai que certains termes vus en dehors du contexte de la programmation peuvent faire un peu "cuisine", genre morceau

Speedy^SF : Tout à l'heure j'ai fait une mise à jour concernant le problème que tu as repéré. A priori cela devrait être bon, mais il me faudra une nuit de sommeil pour vérifier que tout fonctionne correctement. En tout cas le lien vers la version de SCENESTATS.TXT mise à jour est le même (cf. plus haut).
Autre remarque, les FF que l'on voit parfois à la fin de certains "sous-blocs" de scripts semblent servir à arrondir la taille des blocs par des multiples de 4 (comme d'habitude quoi ^^). Donc a priori c'est normal.
_________________

[Speedy^SF]

Je pense que tu as pu remarquer que dans ce "contexte là" ta balise de fin de sous-bloc n'est plus "73" mais bien "90 73"

De la même maniére les "séparations" dans les sous-blocs se caractérisent par un "90 72" ou "91 72" ou "92 72" ( et ça j'en suis persuadé ^^ )

Petite illustration tirée du file53 :
Le Block[0] devrait correspondre à Hippogriff

[ccod:1:3ab43aa931]
Block[0].SubBlock[ 0] (Ptr: 6;SubPtr: 20)
11 0 0 2 60 20 1 78 40 80
90 73
Block[0].SubBlock[ 1] (Ptr: 6;SubPtr: 2c)
2 60 20 1 80 40 80 60 0 40
70 c9 0 1 20 0 60 0 71 43
0 2 a0 20 0 6 40 80 60 0
40 70 37 0 12 70 20 2 a0 20
0 6 40 80 60 0 40 82 90 60
20 61 d2 2 92 11 20 0 60 1
90 72
c5 0 72 48 0 60 1 71 4b 0
72 50 0 60 2 71 53 0 72 58
0 60 3 71 8a 0 2 a0 20 0
6 40 80 60 0 40 70 7a 0 12
70 20 2 a0 20 0 6 40 80 60
0 40 82 90 60 20 61 e7 1 92
11 20 0 1 20 0 60 1 30 90
72
c5 0 72 8a 0 2 a0 20 0 6
40 80 60 0 40 70 bc 0 12 70
20 2 a0 20 0 6 40 80 60 0
40 82 90 0 40 0 52 70 b6 0
60 20 61 e7 1 92 72
bc 0 60 20 61 69 3 92 11 20
0 60 1 90 72
c5 0 91 72
4f 1 1 20 0 60 0 71 d4 0
72 d9 0 60 1 71 dc 0 72 e1
0 60 2 71 13 1 2 a0 20 0
6 40 80 60 0 40 70 3 1 12
70 20 2 a0 20 0 6 40 80 60
0 40 82 90 60 20 61 d3 2 92
11 20 0 1 20 0 60 1 30 90
72
4e 1 72 13 1 2 a0 20 0 6
40 80 60 0 40 70 45 1 12 70
20 2 a0 20 0 6 40 80 60 0
40 82 90 1 60 0 52 70 3f 1
60 20 61 d3 2 92 72
45 1 60 20 61 6a 3 92 11 20
0 60 1 90 72
4e 1 91 73
Block[0].SubBlock[ 4] (Ptr: 6;SubPtr: 17c)
2 60 20 1 80 40 80 60 0 40
70 6f 0 12 60 20 11 88 40 80
60 1 90 2 60 20 3 60 41 80
2 60 20 3 80 41 80 60 2 33
43 70 6c 0 0 40 0 52 70 6c
0 12 70 20 2 60 20 90 60 20
61 1f 1 92 12 60 20 11 80 40
80 60 6 90 12 60 20 11 78 40
80 2 60 20 1 78 40 80 60 1e
30 90 12 60 20 11 70 42 80 60
10 90 10 40 0 60 1 90 72
79 0 12 60 20 11 88 40 80 60
7 90 73
Block[0].SubBlock[ 5] (Ptr: 6;SubPtr: 1f6)
2 60 20 1 80 40 80 60 0 41
70 5a 0 12 60 20 11 88 40 80
60 7 90 1 60 0 52 70 4d 0
12 70 20 2 60 20 90 60 20 61
20 1 92 12 60 20 11 80 40 80
60 0 90 12 60 20 11 78 40 80
1 0 0 90 12 60 20 11 70 42
80 60 1 90 72
57 0 11 60 0 1 60 0 60 1
31 90 72
64 0 12 60 20 11 88 40 80 60
1 90 73
[/ccod:1:3ab43aa931]

J'aimerai savoir si une des mes hypothéses est probable
Pour ça j'ai besoin de l'avis des joueurs ( fremen et jop ? ^^ ) pour savoir si Hippogriff n'aurait pas tendance à faire l'attaque "Bec" 2 fois plus souvent que l'attaque "Confusion N2" ?

Ma théorie est la suivante : imaginons que les chiffres de la partie "actionID" représentent la probabilité d'attaque
Dans le cas d'Hippogriff on a :

actionID= 3 4 4 5 8 9 a

ce qui donnerait 3 chances sur 43 de faire 1e7 ( "Bec" )
ce qui donnerait 4 chances sur 43 de faire 369 ( "???" )
ce qui donnerait 4 chances sur 43 de faire 2d2 ( "Confusion N2" )
ce qui donnerait 5 chances sur 43 de faire 11f ( "" )
ce qui donnerait 8 chances sur 43 de faire 2d3 ( "Bec" )
ce qui donnerait 9 chances sur 43 de faire 36a ( "???" )
ce qui donnerait 10 chances sur 43 de faire 120 ( "" )

Voili voilou, dites moi ce que vous en pensez
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website

[Fremen^SF]

[FWS]

vec la mise à jour et les nouvelles informations, j'ai du mal à m'y retrouver

Par contre je peux repondre à la théorie des action_id de Speedy.
J'avais également songé que c'était la probabilité de faire telle attaque, mais en sachant que certaines attaques ne sont parfois pas utilisées (ex: grande garde (Bonde de plage) ) il devrait avoir la valeur 0

En fait, ma theorie, c'est que cela correspond à ce que fait le monstre lorsqu'il effectue telle attaque.
Par ex:

Adamantaimai
actionID= 3 4 4 4 ff ff ff ff ff ff ff ff ff ff ff ff
actionTextID= 26a 4f f 10 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff

Les 3 dernieres attaques sont des magies, et ce monstre s'anime de la même façon lorsque ces attaques sont utilisées. De plus Force de mort (4f) n'est jamais utilisé donc devrait être 0
Les action_id commencent par 3, peut être parce que 0,1,2 correspondent aux l'animation du monstre quand il ne fait rien, quand il est attaqué, lorqu'il meurt ?

[Speedy^SF]

FWS : effectivement ça tient debout, reste plus qu'à tester poru vérifier.

Sinon selon la théorie de l'octet 93 qui afficherait du texte, je mets en ligne ce que ça donnerait
Fremen pourra "corriger" les problémes d'accents et autres signes de ponctuation

Fichier Texte
Prog VB

Violi voilou
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website

[Fremen^SF]

C'est quand même plus agréable à voir que des nombres en hexa, c'est vrai qu'on aurait mis du temps à trouver ces textes.

Bref, je me répète mais c'est bien trouvé, et je pense que je n'ai pas besoin de faire remarquer que les phrases sont valides uniquement lorsqu'elles ne sont pas précédées d'un 7x 93 ou 6x 93. Je vais partir de ce principe pour rajouter les chaînes (en ASCII plutôt qu'en hexa ) dans scenestats.txt.

Je te rappelle la fonction de conversion des chaînes de caractères si cela peut t'être utile :

[ccod:1:e2d4eda9a2]

void text_format(unsigned char *str) {
int posit= 0;

// Conversion de la chaine, suppose se finir par FF
while (str[posit] != 0xFF) {

// Conversion de la majeur partie des caracteres
if (str[posit] < 0x60) {
str[posit]+=0x20;
} else {
str[posit]+=0x7A;
}

// Conversion des caracteres a accents connus
if (str[posit] == 0xE8)
str[posit] = 0xE9;
else if (str[posit] == 0xF3)
str[posit] = 0xF4;
else if (str[posit] == 0xE3)
str[posit] = 0xE2;
else if (str[posit] == 0xE9)
str[posit] = 0xE8;
else if (str[posit] == 0xF8)
str[posit] = 0xFB;
else if (str[posit] == 0xE2)
str[posit] = 0xE0;
i++;
}

// On s'assure de retourner une chaine ASCIIZ
if (str[posit - 1] != 0) {
str[posit]= 0;
str[posit+ 1]=0xFF;
}

return;
}



[/ccod:1:e2d4eda9a2]
_________________

[Fremen^SF]

J'ai fait la mise à jour de SCENESTATS (cf. Topic Ressources et Documentations) en suivant ton algo Speedy (en détectant les 93 signifiant des débuts de chaînes). Par contre je n'ai pas pris en compte les "chaînes" qui étaient précédées de 7x 93 ou 6x 93, ai-je seulement bien fait ?

Juste une petite remarque supplémentaire quant à ces chaînes, elles paraissent structurées comme dans certains autres jeux Square plus anciens : certains caractères spéciaux (comme #) semblent définir un changement de couleur ou autre. Cela pourraît être intéressant de trouver la syntaxe complète, à l'occasion.

Quoi qu'il en soit, je continue de réécrire le programme SCENE_RECOMPOSE.C qui récupèrera le nouveau SCENESTATS.TXT pour créer un nouveau fichier SCENE.BIN. Je ne promets rien car j'ai cours ces prochains jours et je ne suis pas là ce week-end, donc je ne sais pas si je trouverai beaucoup de temps pour faire ça.
_________________

[Speedy^SF]

Merci fremen, je n'avais pas eu le temps de me pencher sur les exceptions hier.
ET merci pour le bout de code pour la conversion ^^

Je vais essayer de voir s'il n'y a rien d'autre à tirer des chaînes.

Ne t'inquiéte pas pour SCENE_RECOMPOSE.C, on a quand même le temps de vivre
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website

[Fremen^SF]

J'ai fait un résumé en bas pour les pressés, vu que ce que je raconte n'a pas vraiment d'intérêt

En programmant la partie cgi (dont il est question dans un autre topic), j'en ai profité pour réécrire (seulement pour la troisième fois ^^) les deux programmes qui servent respectivement à extraire les fichiers "file*.gz" de scene.bin et à recréer un nouveau scene.bin avec des fichiers "file*.gz".

Bref, sans trop entrer dans les détails, scene.bin est constitué de blocs de 0x2000 octets, chacun contenant un certain nombre de fichiers "file.gz". On peut par exemple avoir 3 file dans le premier bloc, puis 5 dans le suivant, etc...
Il se trouve que mon "algo" tente de mettre autant de file que possible par bloc (apparemment c'est aussi ce qu'a fait Square à l'origine), mais mon programme faisant quelques petites bourdes, mes fichiers "file.gz" ont vu leur taille augmenter (parfois un peu trop !), si bien qu'au lieu d'avoir un scene.bin avec 3 file dans le premier bloc, puis 5 dans le suivant, je me suis retrouvé avec 2 files, suivis de 5 (par exemple).

Qu'est-ce qu'il y a d'intéressant là-dedans ?
J'ai voulu tester mon fichier "scene.bin" (qui normalement ne contenait aucun changement, en dehors de la position (pas l'ordre hein) des "file" dans le fichier scene.bin). Et lorsque j'ai voulu combattre Zolom de Midgar, je me suis retrouvé dans un combat à la Shinra contre des "Police vargide" !

En résumé :

La correspondance entre un combat quelconque et un lieu quelconque n'est pas indiquée dans les "file". Par exemple le file qui décrit le Zolom de Midgar ne contient pas les coordonnées de la carte du monde où l'on peut tomber sur lui.

Par contre, par déduction, les données informant sur les graphismes à charger (modèles de chaque monstre, décor, etc...) doivent être inclus dans les "file". Car en inversant deux "file", on retrouve toujours les même créatures avec le décor correspondant. Ca on s'en doutait déjà, mais maintenant on peut en être sûrs.
_________________

[Speedy^SF]

Et bien maintenant, au mois, ça a été testé, donc on sait à quoi s'en tenir
Il ne reste plus qu'à faire les correspondance carte/file
Merci fremen
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website

[jopfleger]

Bon travail.
Cela confirme vos suppositions.
_________________
Aimant s'instruire, partager le goût des voyages et l'acquisition de connaissances, se sentant responsable ("spectateur engagé", Raymond Aron). Ma caractéristique c'est l'émerveillement devant la diversification de toutes les formes de vie.

[FWS]

Pour la correspondance carte/file, comme je connais à peu pres où on rencontre tels monstres je pourrai y réflechir.
Pour les unknown,( je sais plus si je l'avais posté sur ce forum ou sur celui de JV.com)

Avant dernier octet de unknown1 non egal à FF <=> 2 premiers octets de unknown5 non egaux à FF FF
Dernier octet de unknown1 non egal à FF <=> 2 premiers octets de unknown5 non egaux à FF FF
Par conséquent, on peut trouver un rapport (un peu comme les 2*8 premiers octets de unknown1, mais on sait maintenant qu'il s'agit des elements et faiblesses).
Pour unknown5, on retrouve des octets (à partir du 5e) present dans les ID attaques de unknown1 donc peut être en rapport avec les attaques possibles quand on manipule un ennemi
Pour unknown3, je pense qu'il s'agit des etats que peuvent subir les ennemis. Je vais prendre les unknown3 de boss, et le mettre en binaire pour essayer de voir si je peux y voir des états
En tout cas, voilà les états des persos possibles mais il y en a qui ne doivent pas être valables sur les monstres (ex : fureur, triste...)
- Mort
- Quasi mort
- Sommeil
- Poison
- Triste
- Furie
- Confusion
- Silence
- Hate
- lent
- Stop
- Grenouille
- Mini
- Lente apathie
- Petrifier
- Regen
- Barriere
- BarrM
- Reflet
- Bouclier
- Peine de mort
- Manipuler
- Folie
- Sans pareil
- Paralysie
- Obscurité

[FWS]

J'avais déjà commencé avec mon frère, une liste des ennemis, où on les trouvent, ce qu'ils ont à voler...
Le voici si vous voulez jeter un coup d'oeil :

http://maths-informatique-jeux.chez.tiscali.fr/Jvideo/Ff7/ff7_liste_des_ennemis.xls

En tout, certains ennemis donnent des objets different en mourrant, par ex : Herbe rasoir, Foulander
Un echose qui n'est pas marqué et que je sais, c'est que le 'dealer de la mort' n'a rien à voler, ou rarement, j'arrive à lui voler un ether turbo. Or dans la liste des ennemis, il est marqué qu'on lui vole une potion-X. Peut-être que dans le jeu, ce que l'on vole dépend si on utilise Vol simultané, Voler/assaut ou gant de voleur, l'objet à voler changerait en plus de voler plus facilement.
En regardant Unknown5 dde 'dealer de la mort' on voit 4 0 qui correspond à l'objet Ether turbo (0x004)
De plus Herbe rasoir, toujours d'apres ma liste, donne une graine de fou parfois en mourrant, et dans unknown5 on trouve 1d 0 qui est loco weed (je suppose graine de fou)
Autre exemple : César donne Calmant ou potion en mourrant (d'apres ma liste) et dans la scenestat.txt, il est dit qu'il donne seulement une potion en mourrant et en regardant Unknown5 on trouve e 0 qui est tranquilizer (donc Calmant)
Mais il y a des il y a des exeptions comme Foulander, dans ma liste il donne en mourrant soit Voile de feu, rideau lunaire, ou matiere à risque, or dans scenestat.txt on ne retrouve pas de valeurs pour unknown5 le disant, de plus Foulander n'a rien à voler dans ma liste, et dans scenestat.txt il a un voile feu.
En regardant scenebinfileformat.pdf, on voit que les informations, objet obtenu en mourrant, et objet à voler se suivent donc serait entre la fin de unknown1 et unknown5. En fait ce que je pense, c'est que l'information est de la forme : 4 * quand obtenir cet element(1 octet), 4 * quel element (2 octets) dont 2 * 2 octets se trouvant dans unknwow5, les 2*2 autres dejà connus sont mis dans steal_objet, object.
Par consequent avec Foulander la fin de unknown1 est :

8 8 ff ff (fin de unknown1), 4 octets qui sont dans: object,steal_object, FF FF FF FF (4 premiers octets de unknown5)

Donc cela se lirait :

8 : objet obtenu en mourrant
8 : objet obtenu en mourrant
FF : pas d'objet obtenu
FF : pas d'objet obtenu
2d 0 (dans object) : rideau lunaire
1f 0 (dans steal_object) : Voile de feu
FF FF : pas d'objet
FF FF : pas d'objet

Ce qui expliquerait pourquoi on retrouve souvent les mêmes valeurs en fin de unknown1, car cela corresponderait à la maniere dont on obtient l'objet qui peut être en mourrant, volant...

Autre chose, dont si 8 semble indiquer que l'on a l'objet en mourrant, a0 semble être por le vol

Reprenons le dealer de la mort :

8 8 a0 ff
cela veut dire que les 2 premiers objets s'obtiennent en mourrant, puis l'autre en volant.
Et cela semble le cas : le premier objets est Baiser de la mort et l'autre Potion-X.
Quand à l'objet à voler il est dans le début de unknown5 et il s'agit bien d'un Ether turbo à voler

Si cette theorie est vraie, alors on retrouve encore les informations sous la forme : Donnees1 Donnees2 où on a Donnees2 en rapport avec un octet de Donnees1

Element Faiblesse/resistance/...
ID (de l'animation?) ID texte d'attaque
Façon d'obtenir l'objet Quel objet


Voilà, qu'en pensez-vous ?