 |
Shit Fliez
Bienvenue sur le forum officiel des Shit Fliez !
|
| Voir le sujet précédent :: Voir le sujet suivant |
| Auteur |
Message |
Fremen^SF
GDB des Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 860
Localisation: Versailles
|
 Posté le: 06 Nov 2003 10:01 Sujet du message: [Problème] Chargement des combats depuis le moteur de FF7 |
 |
|
Je crée un nouveau topic pour exposer un problème relativement important qui concerne indirectement les éditeurs (VB et l'éditeur en PHP/CGI). Je n'attends pas de réponse et je n'oblige personne à lire ce post, l'objet est seulement d'expliquer de la façon la plus simple possible le problème qu'il faudra résoudre avant d'avoir une chance d'obtenir des éditeurs fonctionnels.
En soi, cela ne change rien au développement, que ce soit pour Jopfleger ou pour Speedy. Le problème touche mon programme, qui extrait/recrée un fichier scene.bin : dans certains cas assez fréquents (que l'on ne peut hélas pas prévoir à l'avance), mon programme ne pourra pas générer un fichier SCENE.BIN valide.
Je fais quand même une explication détaillée ici, ne serait-ce que pour avoir un pense-bête sous la main.  Et ainsi en comprenant mieux le problème, si vous souhaitez en savoir plus, vous pourrez peut-être proposer des solutions.
------------------------------------------------------------
Je commence l'explication depuis le début.
Chaque fichier SCENE.BIN est constitué de blocs de taille fixe (0x2000 octets). Chaque bloc contient un nombre variable de "file" compressées. On a 34 blocs dans le SCENE.BIN français, et 33 blocs dans le SCENE.BIN américain.
Voici maintenant l'origine du problème : prenons le premier file (file0).
1) Lorsque je l'extrais d'un SCENE.BIN original (de la version française), file0.gz fait 710 octets.
2) Je le décompresse, je le modifie, je rajoute plein d'informations (par exemple je mets des noms de monstre plus long, des valeurs là où il n'y en avait pas, je rajoute différents scripts)
3) Je recompresse mon fichier file0. Oh surprise, il fait 4272 octets (c'est ce que j'ai obtenu dans le test que j'ai fait, en exagérant volontairement)
Jusque là rien d'anormal. Un fichier plus complexe se compresse forcément moins bien.
Maintenant regardons notre fichier SCENE.BIN original. Le premier bloc de 0x2000 octets contient 11 "file" (file0, file1, file2, file3, file4, file5, file6, file7, file8, file9, file10).
Donc, mon programme, lorsqu'on va l'appeler pour recréer un nouveau SCENE.BIN en utilisant notre nouveau "file0", verra qu'il n'a pas la place de mettre les 11 premiers "file" dans le même bloc : il ne va écrire que file0, file1, file2, file3, file4, file5 dans le premier bloc de 0x2000 octets, et il va écrire les suivants dans les blocs suivants.
Voici une schématisation de ce test. Chaque numéro en début de ligne correspond au numéro de bloc, et les numéros qui suivent correspondent à un file.
| Code: |
// SCENE.BIN original
01 1 2 3 4 5 6 7 8 9 10 11 // file0 - file10
02 1 2 3 4 5 6 7 // file11 - file17
03 1 2 3 4 5 6 7 // etc...
04 1 2 3 4 5 6 7 8
05 1 2 3 4 5 6
06 1 2 3 4 5 6
07 1 2 3 4 5 6 7 8
08 1 2 3 4 5 6 7 8
09 1 2 3 4 5 6 7 8 9 10 11 12
10 1 2 3 4 5 6 7 8
11 1 2 3 4 5 6 7 8 9
12 1 2 3 4 5 6 7 8
13 1 2 3 4 5 6 7
14 1 2 3 4 5 6 7 8
15 1 2 3 4 [5] 6 7 8 // entre crochets : file117
16 1 2 3 4 5 6 7 8 9
17 1 2 3 4 5 6 7 8
18 1 2 3 4 5 6 7 8
19 1 2 3 4 5 6 7 8
20 1 2 3 4 5 6 7 8
21 1 2 3 4 5 6 7
22 1 2 3 4 5 6
23 1 2 3 4 5 6 7 8
24 1 2 3 4 5 6 7
25 1 2 3 4 5 6 7 8
26 1 2 3 4 5 6 7 8
27 1 2 3 4 5 6 7 8
28 1 2 3 4 5 6
29 1 2 3 4 5
30 1 2 3 4
31 1 2 3 4
32 1 2 3 4 5 6
33 1 2 3 4 5 6
34 1 2 3 4 5 6 7 8 9 10 11
// SCENE.BIN modifié
// (Avec un file0.gz plus gros)
01 1 2 3 4 5 6 // file0 - file5
02 1 2 3 4 5 6 7 8 9 // file6 - file14
03 1 2 3 4 5 6 // etc...
04 1 2 3 4 5 6 7 8
05 1 2 3 4 5 6 7
06 1 2 3 4 5
07 1 2 3 4 5 6 7 8
08 1 2 3 4 5 6
09 1 2 3 4 5 6 7 8 9 10 11
10 1 2 3 4 5 6 7 8 9 10
11 1 2 3 4 5 6 7 8
12 1 2 3 4 5 6 7 8 9
13 1 2 3 4 5 6 7
14 1 2 3 4 5 6 7
15 1 2 3 4 <5> 6 7 8 // entre <> : file111
16 1 2 [3] 4 5 6 7 8 // entre crochets : file117
17 1 2 3 4 5 6 7 8
18 1 2 3 4 5 6 7 8
19 1 2 3 4 5 6 7 8 9
20 1 2 3 4 5 6 7 8
21 1 2 3 4 5 6 7 8
22 1 2 3 4 5 6
23 1 2 3 4 5 6 7
24 1 2 3 4 5 6 7
25 1 2 3 4 5 6 7
26 1 2 3 4 5 6 7 8
27 1 2 3 4 5 6 7 8
28 1 2 3 4 5 6 7 8
29 1 2 3 4 5 6
30 1 2 3 4 5
31 1 2 3 4
32 1 2 3 4
33 1 2 3 4 5 6 7
34 1 2 3 4 5 6 7
35 1 2 3 4 5 6 7 8
|
Voici (enfin) le problème : j'ai pris l'exemple du file117. C'est le seul file qui contient le Zolom de Midgar, ce qui me permet de faciliter mes tests.
Dans le SCENE.BIN d'origine, file117 est situé dans le 15ème bloc, et c'est le 5ème fichier de ce bloc.
Dans le SCENE.BIN modifié, file117 est situé dans le 16ème bloc, et c'est le 3ème fichier de ce bloc.
Lorsque je lance une partie de FF7 avec mon SCENE.BIN modifié, à la place du Zolom de Midgar, je tombe sur Cosse de cerveau. En regardant de plus près, oh surprise, je me rends compte que le combat contre ce monstre correspond précisemment au file111, qui est le 5ème fichier du 15ème bloc.
Autrement dit, pour charger les données d'un combat, le moteur de FF7 ne se repère pas par rapport au numéro du file, mais à la "position" du file dans un bloc déterminé à l'avance. 
Cela signifie que, pour peu qu'un file soit trop gros, les suivants seront décalés et donc que les combats du jeu seront complètement faussés. Je n'ai hélas pas pu m'en rendre compte avant, étant donné que dans mes tests je n'avais jamais eu à modifier un nombre conséquent de valeurs.
Concernant les éditeurs, il y a donc pour le moment deux solutions :
1) Modifier une quantité limitée de valeurs dans chaque file et prier pour que ça ne modifie pas trop la taille du file compressé. Par exemple s'en arrêter aux caractéristiques des monstres.
2) Trouver où, parmi les fichiers de FF7, sont stockées les "coordonnées" des file (par exemple bloc 15 file 5 dans le cas du Zolom de Midgar). Je suppose lourdement qu'elles sont incluses dans FF7.EXE dans le cas de la version PC, mais c'est loin d'être gagné.
_________________
 |
|
| Revenir en haut de page |
|
 |
jopfleger
Inscrit le: 07 Oct 2003
Messages: 48
Localisation: Strasbourg
|
| Posté le: 06 Nov 2003 10:39 Sujet du message: |
|
|
Cela ne me surprend pas, car je pensais que les rangs devaient être la clé d'indexation du moteur de combat, et c'est pourquoi j'ai toujours considéré qu'il fallait changer un minimum de choses et en tous cas, ne pas "empaqueter" différemment les descripteurs de monstres. En d'autre termes, il faut retrouver dans le nouveau scene.bin le meme nombre de blocs, cela va de soi, mais aussi le même nombre de files par bloc.
Les développeurs de Square n'avaient en fait pas d'autre choix, puisqu'on n'a pas d'autre clé qui rende les files, subfiles uniques, sauf à parfaire.
Mais découvrir où sont stockées les relations entre les moments du scénario et les invocations des scenes de combat peut s'avérer impossible, à moins de trouver une séquence qui doit forcément être croissante (les pas du scenario) et une info en correspondance (cette info pouvant être une table puisque certaines scenes de combat sont aléatoires, au même point du scénario on peut avoir des ennemis à rencontrer qui sont randomisés et ce seront donc des files différents qui seront chargés.
Mais est-il utile de "pousser" les investigations aussi loin? Sauf à faire plaisir à FWS et à Fremen qui aimeraient renconter Ruby et Emerald sur un même plateau. Mais là on risque effectivement de rencontrer des difficultés et à l'heure qu'il est, on est incapable de dire si elles seront surmontables.
Pour ma part, je continue en modifiant des carac simples, cela permet de garder exactement les mêmes files dans chaque bloc, et il y a déjà de quoi se faire plaisir.
Au fait, Fremen, avais-tu essayé un nomatéria?
_________________
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. |
|
| Revenir en haut de page |
|
|
Fremen^SF
GDB des Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 860
Localisation: Versailles
|
| Posté le: 06 Nov 2003 13:31 Sujet du message: |
|
|
| Jopfleger a écrit: | | Mais découvrir où sont stockées les relations entre les moments du scénario et les invocations des scenes de combat peut s'avérer impossible, à moins de trouver une séquence qui doit forcément être croissante (les pas du scenario) et une info en correspondance (cette info pouvant être une table puisque certaines scenes de combat sont aléatoires, au même point du scénario on peut avoir des ennemis à rencontrer qui sont randomisés et ce seront donc des files différents qui seront chargés. |
Bien vu, ce seraient effectivement des tables qui seraient chargées de la correspondance. Tu m'as donné l'idée de faire un petit programme qui cherche cette table, où chaque élément serait séparé par un écart de taille fixe (0 octet, 1 octet, ...), dans des fichiers que je suspecte de contenir cette information. Il fallait déjà imaginer ce que pouvait contenir cette table.
Parmi les 5 tables que j'ai testées, j'ai testé la table suivante :
unsigned char bloc[34] = {0,11,18,25,33,39,45,53,61,73,81,90,98,105,113,121,130,138,146,154,162,169,175,183,190,198,206,214,220,225,229,233,239,245};
où l'on pourrait retrouver le numéro de bloc à partir du numéro de "file" recherché en utilisant la formule :
bloc[n]<=numero_file<bloc[n+1]
Et bien après avoir décompressé et scanné kernel.bin (un autre fichier de FF7) avec ce programme, je suis précisemment tombé sur ces valeurs. Maintenant il reste à voir si elles jouent bien le rôle qu'on pourrait supposer, mais en tout cas merci pour cette idée, cela permettra peut-être d'économiser des dizaines d'heures de recherche.
Bref, le temps de trouver un moyen de modifier proprement kernel.bin et de tester ça, et je reposte pour dire si ça fonctionne.
Mais découvrir où sont stockées les relations entre les moments du scénario et les invocations des scenes de combat peut s'avérer impossible,
Justement, ce matin en faisant une recherche sur le forum de Qhimm pour voir si je pouvais y trouver des indices, j'ai trouvé un post de The Saint qui explique en détail comment les combats et les "fields" (autrement dit tout ce qui se passe dans le jeu en dehors de la world map, par exemple à Kalm, à Corel ou dans le cratère Nord). Ces informations sont stockées dans le fichier flevel.lgp (un gros fichier de 130Mo qui contient entre autre tous les "fonds d'écran"), et elles contiennent entre autre la fréquence des combats, le numéro de la "scene" (ce qu'il appelle Enemy Type dans son post) et la probabilité de rencontrer tel ou tel autre "Enemy". Note au passage qu'il y a 4 "scenes" dans chaque "file", je l'ai vérifié récemment, donc on retrouve facilement le numéro de "file" à partir du numéro de "scène", si on se comprend
A titre d'information, j'ai pensé que ça pouvait t'intéresser même si ce n'est pas vraiment utile pour nos projets. Donc voici le lien vers post en question.
Mais est-il utile de "pousser" les investigations aussi loin?
Pour te répondre, je vais quand même essayer, surtout qu'il y a une bonne piste qui se trace, mais en effet ce n'est pas primordial, donc si je vois que ça prend trop de temps je laisserai tomber.
Au fait, Fremen, avais-tu essayé un nomatéria?
Et non 
Je trouve que c'est un bon défi à se faire, demandant beaucoup de tactique, le problème est que je ne prends pas vraiment plaisir à jouer à un jeu si je dois m'imposer des règles. Ca peut paraître bizarre, et vrai dire je ne comprends pas pourquoi moi non plus ^^
C'est d'ailleurs pour ça que je me suis intéressé à l'édition de FF7, car ça permettrait de rendre le jeu plus dur sans soucis de contraintes.
_________________
|
|
| Revenir en haut de page |
|
|
jopfleger
Inscrit le: 07 Oct 2003
Messages: 48
Localisation: Strasbourg
|
| Posté le: 06 Nov 2003 14:45 Sujet du message: |
|
|
Bravo pour ton mess, Fremen.
J'ai l'impression que rien n'est insurmontable en ce qui te concerne (hormis les contraintes que tu as du mal à accepter ?!)
J'ai été très intéressé mais aussi très surpris de voir que le fichier flevel.lgp avait déjà été analysé.
Trouver des infos pertinentes dans 130 Mo de binaire, c'est ahurissant.
A ce compte-là, on pourrait peut-être songer à soudoyer un développeur de Square?
Mais je pense que même si tu as trouvé des séquences et les tables en rapport, c'est le début d'une piste.
Mais j'ai vu aussi un petit post de Speedy qui te rappelle que tu as d'autres obligations au niveau études.
S'il se permet de dire cela c'est qu'il te connaît bien et c'est certainement en bonne camaraderie, alors ne néglige pas les conseils de tes amis.
_________________
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. |
|
| Revenir en haut de page |
|
|
Fremen^SF
GDB des Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 860
Localisation: Versailles
|
| Posté le: 07 Nov 2003 1:06 Sujet du message: |
|
|
Mais j'ai vu aussi un petit post de Speedy qui te rappelle que tu as d'autres obligations au niveau études.
S'il se permet de dire cela c'est qu'il te connaît bien et c'est certainement en bonne camaraderie, alors ne néglige pas les conseils de tes amis.
Oui, il a 100 fois raison, mais je ne suis pas encore en situation d'échec. Je souhaitais seulement atteindre certains objectifs pour ce projet avant de me relancer au maximum sur mes cours. Car à vrai dire, je suis incapable de faire deux choses à la fois, et laisser ce projet (pour ma part) en stand-by, sans avoir fournit un script cgi correct et un serveur MySQL opérationnel à Speedy, sans que tu aies un programme fonctionnel sous la main pour modifier les données de monstres pour ton éditeur et sans avoir filé le moindre coup de main à FWS pour le décryptage de SCENE.BIN, ça m'aurait franchement gêné. Ce projet j'en rêve presque depuis que j'ai rejoué à FF7 en 98 et que j'ai trouvé ce jeu trop facile et trop identique à ma première partie. Maintenant j'ai la conscience tranquille, même si tout est loin d'être fini, je sais maintenant que rien ne pourra nous empêcher de faire des éditeurs fonctionnels.
Donc pour ma part, je crois que je vais en rester là pour le moment sur ce projet. Je dois faire mes preuves (à la fac) en Janvier, et je sais que deux mois ça passe très vite et que la fac ne me laissera pas une quatrième chance (oui oui je triple ma deuxième année actuellement  ). Quoi qu'il en soit, même si ce n'était peut-être pas dit dans ce but, je vais suivre vos conseils. Je vais profiter de la semaine de vacances scolaires à venir (notre fac est en retard ^^) pour me sevrer et me remettre de bon pied pour la rentrée, et je me limiterai dorénavant à jeter un oeil à l'avancement des trois travaux en cours (éditeur en VB, éditeur en php/cgi, et décryptage de SCENE.BIN). J'espère seulement que tout le monde comprendra bien que ce n'est pas par mauvaise volonté (d'ailleurs ce n'est pas l'envie qui me manque de continuer jusqu'au bout), mais simplement à cause du fait que lorsque j'écris une ligne de programme, je ne peux pas m'empêcher d'écrire la suivante, et ainsi de suite  Un jour je crois qu'un bon psy ne me ferait pas de mal d'ailleurs 
Je pars donc en "vacances" Samedi et je serai par conséquent beaucoup moins présent à partir de ce moment. Néanmoins si tout va bien, je pourrai de nouveau contribuer dès Février, si mes résultats le permettent. Je m'excuse d'avance de tous vous laisser sur un projet en cours, mais vu le nombre de personnes de mon entourage qui me poussent à reprendre des activités plus utiles pour mon avenir direct, je crois que je vais suivre le conseil pour de bon.
Trouver des infos pertinentes dans 130 Mo de binaire, c'est ahurissant.
En réalité, ce fichier n'est pas si complexe que ça : tu as un index au début, qui pointe sur tous les "fields" du jeu.
- Chaque field représente un lieu ("intérieur de l'auberge de Kalm, rez-de-chaussée", "intérieur de l'auberge de Kalm, étage", "Maison d'Elmyra", etc...).
- Ces fields sont en fait des fichiers compressés. Une fois décompressés, on se rend compte qu'ils sont eux-même constitués de sections (les pointeurs se trouvent au début de chaque fichier field). Ces sections se trouvent donc facilement.
La grosse difficulté était donc de trouver le rôle de chaque section (il doit y en avoir une dizaine), mais une fois que c''est trouvé pour un field, cela s'applique à tous les autres field. Après c'est sûr, rien que comprendre le sens de la section 7 (celle que The Saint décrit) c'est un boulot important. Je ne comprends d'ailleurs toujours pas l'utilité de ces "root values" qu'il décrit, pourquoi Square se sont-ils sentis obligés d'additionner des valeurs constantes à chaque numéro de scène ?
Mais je pense que même si tu as trouvé des séquences et les tables en rapport, c'est le début d'une piste.
Sur ce point, j'ai pu vérifier, les valeurs incluses dans kernel.bin correspondent effectivement à ces valeurs de bloc. Dans un tableau unsigned char bloc[64] sont stockées les numéros de file situés au début de chaque bloc, i.e. :
Bloc01 : bloc[0] = 0x00
Bloc02 : bloc[1] = 0x0B
Bloc03 : bloc[2] = 0x12
etc...
Donc par la suite, si l'on souhaite permettre des choses assez couteuses en espace, par exemple rajouter des sorts (et leurs noms) à un monstre, complexifier les scenes de combat, ce sera possible. Evidemment nous n'en sommes pas là
Petite parenthèse, concernant la version PSX, on peut patcher l'image CD avec KERNEL.BIN de la même façon que pour SCENE.BIN. J'ai pu vérifier ça tout à l'heure. Si quelqu'un en a utilité, je pourrais l'adapter et le mettre en ligne demain.
_________________
|
|
| Revenir en haut de page |
|
|
Speedy^SF
Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 758
Localisation: Troyes
|
| Posté le: 10 Nov 2003 0:14 Sujet du message: |
|
|
TRES TRES joli travail de recherche fremen
Là je trouve que tu ( je ne dis pas "on" car moi je ne fais plus rien ces derniers temps :] ) as fait un sacré travail de recherche
Je trouve que ta décision concernant tes études est la bonne
Donc, bon courage pour la suite
Voili voilou
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website |
|
| Revenir en haut de page |
|
|
|
|
Vous ne pouvez pas poster de nouveaux sujets dans ce forum
Vous ne pouvez pas répondre aux sujets dans ce forum
Vous ne pouvez pas éditer vos messages dans ce forum
Vous ne pouvez pas supprimer vos messages dans ce forum
Vous ne pouvez pas voter dans les sondages de ce forum
|
|
Accueil
FAQ
Rechercher
Liste des Membres
Groupes d'utilisateurs
S'enregistrer
Profil
Se connecter pour vérifier ses messages privés
Connexion
