Traductions des jeux SCUMM 256 couleurs (ZAK INDY3 LOOM)

[H***]

EventInfo: bah si tu lis ma doc c'est assez clair. C'est "pour tel numero d'evennement, déclenche le code qui est à cet offset."
Et je dis bien "offset" dans ma doc!
J'ai trouvé ca en voyant descumm3. Il affiche la liste d'events mais il ne décode qu'un seul handler. Donc en y jetant un coup d'oeil avec un editeur hexa j'ai pu écrire le format. Mais tu peux vérifier dans scummvm si ca te dis.
Deux choses à savoir au cas où:
- Deux events peuvent avoir le même handler.
- Les events ne sont pas dans un ordre particulier.

A propos des deux outils dont tu parles, et bien il n'y en a pas besoin si tu fais un programme comme celui que j'avais annoncé. Tu peux compresser le texte et basta, c'est légal et ca ne fait pas "spoiler".
Puis pour ScummEdit c'est pareil. Un bouton "Import pack" et un bouton "Export pack" (qui te laisse cocher les resources à exporter), voila tout.

Pour la version allemande, c'est pas tout simplement une réédition officielle?

Et au fait, je suis bien décidé à faire autre chose de mon week end qu'un programme qui s'avèrera inutile Non mais!

Moi je t'aiderais bien, tournesol, mais il n'y a aucun travail de recherche (tout est déjà dans scummvm), et je ne code pas en VB.
Tiens, à propos, je sens que ne te ferai jamais changer d'avis, mais C++ builder c'est comme VB mais en C++ (quoique je préfère VC++), et entre nous, l'asm et le C ca n'a strictement rien à voir avec le C++ et le Java!

L'éditeur dont je te parlais est en Java et les sources sont dispos. Je crois juste qu'il avance très lentement.
Ca y est j'ai le lien: http://www.cowlark.com/scumm.html
skimm! Ca a l'air très peu avancé!

[RyF]

err... ce qui m'intéressait c'est pas la Version allemande, mais ton programme - si tu abouti à qq chose de concret =^__^=
Mais merci quand même (je devais l'avoir déjà qq part)

Je vous aurais bien aidé, mais je ne suis pas programmeur pour un sous. on peut pas tout savoir faire dans la vie...

[Indianagilles]

Ah je commençais à me sentir bien seul ici. Il n'y a pas que pour moi que vous parlez Martien !!!

[Guybrush02]

bon je crois que ma mémoire m'a jouer des tours, la version de LOOM CD espagnol a été traduite de l'anglais

[H***]

Je n'aurai pas fini lundi, alors si tu ne comptes mettre qu'un week-end pour le faire, go !

Désolé mais je ne peux pas revenir sur ma décision car hier j'ai accepté l'invitation de mon frere pour ce week end Jeudi c'est férié je crois, mais je ne fais pas le pont, donc ca me parait limite tout ca. Et puis comme je l'ai dit, pourquoi je me fatiguerais si tu fais ce programme de toute facon?

Même si ce n'est pas le cas par la suite, les objets ont un n° qui n'a pas dû changer d'une version à l'autre.
Et si ça a changé, ScummVm s'y retrouve bien donc on doit y arriver aussi.

Rien à voir! scummvm n'est pas un clone, c'est un interpreteur, donc encore heureux que ca marche avec des numéros différents! C'est au compilateur scumm de chez lucasarts qu'on doit la cohérence des numéros!
La seule chose que tu peux faire pour associer automatiquement la traduction si les numeros ont changé c'est comparer le script. Si tu fais ca, je suggère que tu laisses une liste des textes non-trouvés pour que l'utilisateur finisse lui meme, car les jeux lucas ont souvent eu plusieurs versions (1.0, 1.1, 1.2, ...) et tu n'auras sans doute pas 100% de réussite. Mais je trouve que c'est se prendre la tete pour rien. Le nombre de traductions "officielles" à faire est très limité, donc l'automatisme complet très peu utile. Les traductions "à la main" n'en auront pas besoin, pas meme celle de ATP puisque l'ordre sera forcément le même.

Et yen a marre du VB, je retourne au C pour cette tâche.

J'espère que tu veux dire C++! :-p

Plutôt que de perdre mon temps à chercher sur les sites et dans les sources, si quelqu'un a déjà trouvé la structure des fichiers 00.LFL par exemple, qu'il me dise où ?

Bah c'est pas dur, j'ai les 00.LFL de zak256 et de Indy256 sous les yeux et voila ce que je vois:
- Block 0R: dans zak, du vide. Dans Indy des numéros ascii entre 1 et 4.
=> numéro de disquette pour chaque room (LFL). Avec une case vide si le LFL n'existe pas (#94 par exemple).
Le word au début donne le numero maxi de LFL (99).
Les 4 octets à 0 de chaque room ca doit etre soit pour les numéros de disquette à plusieurs chiffres, soit pour l'offset du block RO.
Ce block 0R n'est pas utile pour toi de toute facon.

- Block 0S: 'S' comme scripts. C'est les scripts globaux évidement, sinon ils seraient pas référencés dans 00.LFL (donc block SC). 139 scripts (word au début), puis pour les 139, tu as un numéro de room (##.LFL) et l'offset du script (il suffit de regarder la room pour voir qu'il y a un script à cet offset). Donc 5 octets * 139.
A updater après une modif.

- Block 0N: Visiblement c'est la même chose pour les sons (SO).
A updater après une modif.

- Block 0C: Costumes (CO).
A updater après une modif.

C'est facile, si tu regardes un LFL, les blocks SO, SC et CO sont ceux que tu trouves en dehors des blocks RO. C'est pour ca qu'ils ont besoin d'une TOC.

- Block 0O: Surement 'O' pour objects. C'est des flags, ca se voit aux puissances de 2. Donc je suppose que c'est des options pour chaque object (les options de la case X de la table doivent être pour l'object n° X, comme pour 0R dans Indy).

Voilà. C'est franchement pas la peine de chercher sur le net!

[H***]

Tu peux pas faire plus détaillé. Je viens de te donner le format *complet* de 00.LFL dans Indy256 et Zak256. Je dit complet parce que ce qu'il manque (interpretation des flags d'objects et ces dword valant 0 dans 0R) est inutile pour ton programme.
Voila. Donc je ne vois pas ce que tu veux de plus?
Au cas ou: je ne me suis pas répété entre 0C 0S et 0N parce que c'est la même structure:
Contenu du block:
word n
Pos[n] table

Pos:
byte numero_de_lfl
dword offset

Pour la récupération des textes officiels, j'ai toujours dit c'est ce qu'il faut faire. Je dis seulement qu'essayer d'automatiser l'ordre des textes (traduction 100% auto) c'est se prendre la tête pour rien, car soit c'est inutile (c'est déjà dans le même ordre) soit c'est pour finalement ne pas faire une automatisation à 100% (nottament dans Zak). Et il n'y a que 3 traductions officielles à faire (zak, indy3 et loom).
Mais à part ca, évidemment qu'il faut extraire et convertir les textes des jeux scumm2.

[H***]

Mauvaise nouvelle, des textes sont intégrés aux scripts, ce qui nécessite de décoder les scripts pour ajuster les adresses de branchements selon la longueur des textes.

C'est pas vrai!! Tu me fais une blague là. Tout ca je l'ai dit dans mon premier post sur ce forum, au debut de ce thread! Et c'est maintenant que tu t'en rends compte? Si les chaines étaient référencées, ca serait pas un week end qu'il faudrait mais deux petites heures!
Tu comprends peut etre l'utilité d'un programme bien modélisé (et donc en C++ ou Java) maintenant?

Exemple, lorsque Indy prend de l'eau au robinet dans le hall du collège,
le script suivant est exécuté;

[...]
[0013] (58) Override(1)
[0015] (18) goto 0021;
[0018] (11) animateCostume(1,10)
[001B] (1C) startSound(8)
[001D] (2E) Delay(180);
[0021] (3C) stopSound(8)
[...]

(L'instruction goto 21 est une erreur de script)

Je n'ai pas le script sous les yeux, mais si c'est l'original, et si à l'override il y a "58 01", c'est une erreur de descumm, pas de script. Descumm est buggé, je l'ai déjà dit, il lit mal certaines instructions, ce qui entraine des décalages qui faussent le script.
Mais de toute manière qui te dit qu'il n'y a pas de jumps inter-scripts (pour la factorisation du code)? Bon, ok c'est peu probable vu l'archie en blocks, mais possible. Je trouve que tu conclues un peu vite...
(A MOINS QUE ce bout de script ne soit pas l'original mais une modif de toi, et que tu n'aies pas la prétention trouver des bugs dans Indy256. Dans ce cas au temps pour moi )

Pas de problème.
Pour reconnaître les instructions de branchement,
comme la longueur des instructions est variable,
il faut intégrer la table des 256 codes avec certains qui ont 20 variantes, blabla...

Là encore, je pensais que tu avais lu mes posts, mais je vois que non.
Surtout je suis surpris de cette découverte tardive. On voit des textes à des endroits complètement aléatoires de chaque bloc de script! Ca parait donc évident, même sans utiliser descumm, que c'est pas référencé!
Bon, c'est pas grave, maintenant tu es au courant Tu ne devrais plus avoir de mauvaises surprises du même genre par la suite.

Tout ça pour dire que le bout du tunnel n'est pas pour demain.

C'est quand même pas la mer à boire. De la copie bête et méchante de scummvm! Si tu codes sous un bon éditeur avec regexps etc. (eg. emacs) le tunnel c'est plus qu'un bête pont

Bon si ca avance pas je peux m'y mettre mercredi soir pour finir jeudi soir peut etre (ou le week end juste après).
En attendant, bon week end, à Lundi, et bonne continuation

[RyF]

merci, je testerais ça dès que j'ai 5 min de libre =^__^=

[H***]

Voici mon programme, mais en version "beta" on va dire
http://membres.lycos.fr/realathlon/pv/
C'est "SCUMM3TR.EXE".
Et les fichiers BAT peuvent vous être utiles si vous voulez aussi.

Je n'ai testé qu'avec Zak, et ça semblait pas trop mal, malgré quelques scripts mal lus (je me pencherai dessus plus tard). Mais j'avoue ne pas avoir essayé grand chose. Alors considérez cette version comme un test.
Normalement ça marche aussi avec Indy3. Faudrait essayer.

Voilà, malheureusement je n'ai pas le temps de faire la version scumm2 pour extraire les textes de Indy et Zak EGA. Mais peut etre ce week end, qui sait... De toute façon ça prendrait pas longtemps.

Truc à savoir:
Il est interdit de faire des lignes vides, sous peine de décalage. Car le programme ignore les lignes vides quand il lit les fichiers du jeu.
Autre truc:
Le fichier écrit/lu par le programme est converti selon la police de caractères de Zak, pour être compatible "windows occidental". Et les caractères non-imprimables sont "escapés". L'escaping doit forcément être '\\' suivi de 3 chiffres (décimal), sauf pour '\\\'.
A propos, voici des infos sur les caractères spéciaux (pas 100% sures mais presque):
\255\001 : Va à la 2ème ligne.
\255\002 : Empêche le texte de disparaitre avant un prochain print.
\255\003: "Tourne la page", ie. efface les 2 lignes et revient à la 1ère.
\255\004\XXX\XXX: Affiche la variable X en décimal.
\255\005\XXX\XXX: Verbe X?
\255\006\XXX\XXX: Nom de perso X?
\255\007\XXX\XXX: Affiche la chaine de caractère X.

X c'est un word (LE je crois). Mais de toute façon, vous n'avez pas à changer ce X.
Ce qui est utile c'est les 3 1ers caractères spéciaux quand une phrase en français devient trop longue.

Voilà. Merci de me dire si il y a des bugs. Ca ne m'étonerait pas vu la façon dont j'ai codé ça

Edit: Je me rends compte que j'ai oublié d'expliquer les messages d'erreur.
Quand un bloc est ignoré à cause d'un script "illisible", le programme affiche un message avec le nom du fichier (XX.LFL) suivi de l'offset du bloc en decimal. Voilà. A priori dans Zak on perd pas grand chose.
Ces scripts doivent avoir une spécificité, ou bien une instruction rare est mal décodée dans scummvm. Je verrai ça plus tard.

Edit2: plus besoin d'edit2. merci à tournesol

[H***]

Ya au moins un bug puisque si je traduit Indy3 allemand en anglais, j'ai 1 octet différent de la vraie version anglaise (sur 01.LFL qui est identique entre les 2 versions). C'est un goto pas updaté. Aussi 23.LFL et 28.LFL en allemand semblent poser un problème, mais j'ai pas le temps de regarder d'où ça vient, je regarderai ce week end (qui commence le Samedi après midi pour moi ).

Indy3 allemand est bien un version officielle. Regardez la date des fichiers.

Enfin, j'ai changé d'avis à propos des traductions officielles. Celle de Zak est pas top. "Salut copain" dit le vendeur... Je préfère finalement une traduction non officielle à la ATP.
Pour Indy3 EGA c'est peut etre mieux?
Si seulement toutes les traductions étaient aussi bonnes que dans monkey1...

[Indianagilles]

Oui, Zack c'est pas top. C'est une traduction très "franglais"

Pour Indy, je crois que c'est bien. Mais ça fait si longtemps

[H***]

en fait j'ai débuggé en 2 minutes, c'était rien
Maintenant, de allemand à anglais j'obtiens exactement le même fichier que la vraie version anglaise.
Je vais m'attaquer à ce problème de 23.LFL et 28.LFL.
Sinon, bin je lis courament l'assembleur depuis que j'ai fait mes patchs elastomania (j'ai rajouté plein de fonctions à ce jeu dont j'ai pas les sources, dont un mode multiplayer réseau). MAIS, je ne sais pas comment marchent les programmes DOS avec adressage 16bit, expandeurs et autre trucs zarbis liés à l'adressage mémoire. Donc je serais très intéressé par des cours à ce niveau là au cas où j'aie à me plonger dans un vieil exe DOS.

[H***]

J'ai à peu près le même problème en plus simple, je suis passé de rien à windows direct Si tu connais l'adressage 16bits ou un bon site sur l'asm sous dos, je suis intéressé. Je ne connais que l'adressage 32 bits absolu de windows.

Bon bin le "bug" de 23.lfl et 28.lfl vient de lucasarts ou d'un mauvais transfert En fait il y a 2 caractères invalides, 0xFF au lieu de (beta), alors que cette lettre a son code normal dans le reste du jeu ('à' je crois). J'ai juste mis le niveau d'intolérance un peu trop haut (les warnings font des fails) c'est pour ça que ça bloquait.

Il ne me reste plus qu'à essayer de faire marcher les scripts "ignored", parce qu'il y en a un qui est plein de dialogues dans indy et qu'il faudrait faire marcher.

Après ça bin yaura plus qu'à traduire, ou éventuellement faire scumm2tr (plutot scumm2,5tr pour indy3 ega, d'après ce que j'en ai vu, ie. un mix entre scumm2 et scumm3) et scumm5tr (pour indy4 et loom).

[H***]

hmm ok. c'est vraiment pas pratique pour le reverse engineering, je crois que je vais me limiter aux programmes windows.

edit2: lol conclusions hatives. hors sujet qui plus est. => effacé

[H***]

Ah bin tiens c'est marrant parce que moi j'ai un exe de 60K justement (sauf pour l'allemande qui a un exe de 116K). Ceci dit j'ai quand même quelques textes en clair dans l'exe de 60K ("SAVEGAME" etc. donc pas du compilo). Bref, je ferais mieux de retourner à mon prog de toute façon. Je vois pas à quoi ça va nous mener de désassembler indy3, sachant qu'on a scummvm