Traductions des jeux SCUMM 256 couleurs (ZAK INDY3 LOOM)

[H***]

Je trouve bizarre cette méthode pour le compresseur. Il peut pas faire un dictionnaire avec des stats du fichier complet comme tout le monde?
Bah, j'ai pas les 2 exe décompressés pour comparer là (j'essaierai plus tard le prog dont tu as parlé). Mais bon quand je vois du '3x' en hexa, je pense d'abord à des chiffres ascii, genre numéro de version, date, etc. Si je regarde avec Hiew il me permet de suivre les calls, mais bon avec ces reférences 16bits il faudrait un debugger pour comprendre rapidement ce que fait la fonction.
De toute façon c'est 99.99999% certain que l'encodage des scripts est resté le même. C'est techniquement le même jeu, et si des modifications étaient nécéssaires elles se feraient au niveau du script (comme dans les autres jeux scumm). De plus je verrais plus vite si ya des différences avec mon prog.

A propos des scripts ignorés dans scumm3tr, c'est dû aux opcodes non reconnus par scummvm. La lecture des paramètres semble dépendre de pas mal de choses (comparé aux autres opcodes). Demain je donnerai une version plus compatible.
Bonne soirée.

[Zorbid]

Le debugger de DOSBox pourrait vous aider...

Il faut d'abord que vous compiliez une version debug cfr http://cvs.sourceforge.net/cgi-bin/v...viewcvs-markup .

Ensuite, lancez le jeu et appuyez sur le - du pavé numérique. vous accéderez au débugger . F5 depuis la fenêtre debug pour retourner au jeu. Ne m'en demandez pas plus, je n'y connais rien en asm (enfin, si, j'ai bien une idée de comment ça marche, mais c'est tout), et je n'ai jamais utilisé le débugger.

Si vous voulez entrer dans le débugger avant l'exécution du fichier, tapez debug nom_de_fichier.exe, DOSBox charge le prog en mémoire, et entre tout de suite dans le débugger.

[H***]

Salut,

http://hibernatus34.free.fr/scumm/

Voilà une nouvelle version qui supporte Indy4, MI1 et MI2 (les versions CD). Et puis avec Indy3, Zak et Loom c'est un peu plus compatible. Normalement seules 2 "erreurs" dans Zak et Indy devraient apparaitre. Elles ne posent aucun problème pour la traduction (pas de texte utile dans ces scripts).

A coup de scripts et regexps quelqu'un pourrait mixer Indy4 talkie avec Indy4 FR. A propos, il serait très facile de faire un éditeur de monster.sou qui autorise un changement de taille des sons. L'offset du son à jouer (ou plutôt de son bloc dans monster.sou) et écrit dans les caractères spéciaux au début de chaque ligne.

Pour Indy3 allemand, il faut corriger 3 petites erreurs avant de traduire:
23.LFL[0x147FE] = 0xE1;
28.LFL[0xEAFA] = 0xE1;
28.LFL[0xECFB] = 0xE1;

Pour Zak256, il y a une version crackée qui se balade sur le net et qui rend le script invalide dans 2 blocs de 03.LFL. Ca cause la "perte" de 2 lignes. Donc une traduction pour la version crackée doit être modifiée avant d'être appliquée à la version pas crackée (et vice versa).

Voilà, si j'ai pas la flemme je rajouterai le support de Indy3 EGA et Loom EGA.

Zorbid: Excellent, je savais pas que dos box faisait debugger. Ca doit être beaucoup plus pratique sous windows etc.

Tournesol: personnellement je ne reassemble pas, je modifie la taille de l'exe et je code directement dedans avec Hiew. Je pense que dans beaucoup de cas c'est assez pratique. Le seul problème c'est quand tu dois décaler ton code (genre t'as oublié une instruction) il te faut refaire les références relatives (jumps). Alors parfois je fais une table pour les calls (call d,[424242]) et je corrige les jumps à la main (j'ai pas souvent à décaler du code). Sinon peut être qu'un autre éditeur genre Hiew est capable de corriger les références lui-même quand on bouge du code, mais alors je l'ai pas trouvé.


Au fait, ya une team de traduction française (genre ATP) qui voudra traduire Zak256?

[P*** R***]

Ca bosses ici,je comprends rien mais continuez,ca a l'air interessant .

Bonne chance.

PS :c'etai juste un mot d'encouragement a ceux qui bossent .

[Zorbid]

Si tu pouvais convertir les enter de 8 à 16 bits, ça faciliterait les choses. Seul notepad ne les convertis pas de 8 à 16 en sauvegardant, mais c'est parce qu'il ne considère pas les enter 8 bit comme des enter mais comme des caractères spéciaux. C'est donc hyper chiant à lire...

De plus, je viens d'essyer d'extraire et de réinsérer le texte d'Indy3 (sans le modifier), et ça fait planter le jeu avant l'écran de titre.

J'ai remarqué que tu ne faisais pas de copie de sauvegarde du 00.lfl, est-ce exprès?

updating 01.LFL
updating 02.LFL
updating 14.LFL
14.LFL:28508 ignored (script failure).  // idem à l'extraction
14.LFL:28542 ignored (script failure).  // idem à l'extraction
updating 15.LFL
updating 76.LFL
NULL char in object name
76.LFL:15544 failed.
updating 77.LFL
updating 86.LFL
NULL char in object name
86.LFL:64060 failed.
updating 87.LFL
updating 00.LFL

Le bug semble aléatoire, j'ai eu la même chose avec le 77.lfl une autre fois...:confused:. Lors de l'extraction du texte, il avait dit ceci à propos du 77.lfl (avec le param -V):

reading 77.LFL
77.LFL:34624 empty.
77.LFL:34645 empty.

[H***]

Oulala, ça a l'air catastrophique J'ai peut-être uploadé une mauvaise version. Je vais regarder ça, mais là il est tard donc peut être demain plutôt.
Pour 00.LFL, c'est parce qu'une erreur fatale a été rencontrée. Quand le prog dit "updating 00.LFL" c'est en mémoire qu'il le fait, et après il sauvegarde (et fait le backup) si il n'y a pas d'erreur. D'ailleurs maintenant que j'y pense il devrait aussi restaurer les autres fichiers qui ont déjà été écrits (01.LFL etc.).

Bon, je vais quand même essayer d'expliquer tes messages d'erreurs:

14.LFL:28508 ignored (script failure). // idem à l'extraction
14.LFL:28542 ignored (script failure). // idem à l'extraction

C'est normal. Pour Zak256 et Indy3 256 il y a un opcode inconnu présent dans ces 2 scripts. Ce n'est pas un problème pour traduire.

NULL char in object name

Ca ça veut dire qu'il y a le char 0 (\000) dans un nom d'objet, ce qui n'est pas normal et provoque l'annulation de la traduction. En fait c'est pas dans le nom d'objet mais dans un ligne du fichier de traduction qui correspond à un nom d'objet.
C'est cette erreur qui a rendu le jeu injouable car la traduction s'est arrêtée et 00.LFL n'a pas été mis à jour alors que quelques autres fichiers oui.

77.LFL:34624 empty.

Ca c'est pas méchant, ça indique un bloc "vide". C'est plus pour mon usage personnel

Tu n'as pas décalé les lignes? De telle manière qu'une ligne de texte avec \000 se retrouve "en face" d'un nom d'objet.

Pour le newline, c'est quand même beaucoup plus pratique avec 1 char. Je peux rajouter une option, mais quel genre de personne serait assez dingue pour traduire un jeu avec notepad?

edit: je viens d'essayer et ça fait comme tu as dit j'ai dû faire une betise en rajoutant des trucs de dernière minute. demain soir je posterai une version correcte.

[Zorbid]

Le "NULL char in object name" semble aléatoire.

J'ai fait plusieurs fois
Scummtr -3o
suivit immédiatement de
Scummtr -3i
sans modifier le text.dat, donc, et l'erreur apparait à différents endroits, sans que je ne puisse identifier de cause à celà.

Pour le enter en 16 bit, les "éditeurs" que j'ai convertissent les saut 8 bit en sauts 16 bit en enregistrant. Si je dumpe le texte, que je le charge et le sauve dans MSWord, WordPad ou même l'edit de la console, que je le réinjecte et que je le redumpe, ça ajoute un \013 à la fin de chaque ligne...

Il n'y a que notepad qui respecte les sauts 8 bit, parce qu'il ne les comprend pas. Il les considère comme un caractère spécial...

Tu vas me dire et tu auras raison que je n'ai qu'à me procurer un éditeur valable...

[H***]

Non c'est pas aléatoire, c'est juste qu'il y a un decalage d'une ligne à chaque fois, et l'alignement des lignes contenant un NULL char avec les noms d'objets donne l'illusion que c'est aléatoire.
Le problème est réglé, c'était juste un "return" qui s'est perdu
En revanche, je ne poste pas la version corrigée car j'ai déjà entamé de nouvelles modifications. De plus je pense que je devrais prendre le temps de faire quelques tests basiques avant chaque release Alors à bientôt...

[Zorbid]

J'attends la suite avec impatience.

Un truc qui me turlupine: as-tu piqué du code dans ScummVM? Si oui, je suppose que tu sais que tu dois publier le code de scummtr sous laz GPL.

Perso, je ne saurai rien en faire, je comprends à peine le C/C++, et je n'ai jamais rien codé (en C du moins). C'est juste pour avoir la conscience tranquille quand je fais de la pub pour ScummTR

[H***]

http://hibernatus34.free.fr/scumm/

Voilà, ça me reprend, j'en ai marre de tester alors voici la nouvelle version et c'est vous (toi?) qui testez. Merci

Au fait, ça extrait les textes de Loom et Indy3 EGA (enfin j'ai testé que sur les version ST, les seules que j'ai). Et puis j'ai rajouté l'option "\r\n" pour Zorbid. Et quand il y a une erreur "fatale", les .BAK sont remis en place.

Voilà.

[H***]

Zorbid: Non il n'y a pas le moindre morceau de scummvm dans mon code. J'ai simplement pompé l'interpretation des opcodes dans leur source. Mais eux-même l'ont pompée dans les exe originaux, donc légalement et moralement ça va
Precision: par "pompé" je ne veux pas dire un simple copier/coller. Tout est à ma sauce.

[Zorbid]

Je teste et je te dis quoi.

Pour les "enters", j'ai finalement trouvé un éditeur potable (même assez bon à priori): SciTE. Il gère tous les enter qu'on peut imaginer

[Zorbid]

Je viens d'essayer Indy3, a priori, ça marche.

Un petit problème pour nos amis espagnols, cependant:
le "ñ" passe assez mal (le ù aussi, mais j'ignore quelle langue utilise cette lettre). Il semble de plus que le ù et le ñ se superposent...

It's a bunch of trophies that the Archaeology\255\001Department won.éèçàôîûêïëñù

[Zorbid]

Il y a des erreurs de script lors de l'extracition de Loom16 PC. Je ne sais pas si ça a de l'importance...

reading 01.LFL
reading 02.LFL
2.LFL:SC#116:28523 ignored (script failure).
reading 03.LFL
...
reading 11.LFL
11.LFL:SC#51:18297 ignored (script failure).
reading 12.LFL
...
reading 18.LFL
18.LFL:LS#205:16128 ignored (script failure).
18.LFL:SC#55:16895 ignored (script failure).
reading 19.LFL
...
reading 70.LFL
70.LFL:LS#201:3219 ignored (script failure).
70.LFL:LS#203:4887 ignored (script failure).
70.LFL:LS#204:4908 ignored (script failure).
reading 79.LFL
...
reading 87.LFL

[Zorbid]

Je viens d'essayer un truc qui n'était probablement pas pévu... insérer le texte dI'ndy4 VF dans la version talkie...

En gros, ça foire. ScummVM plante, Sous Win et dans DOSBox, c'est l'écran noir.

updating ATLANTIS.001
1.LFL:52682 empty.

2.LFL:57589 empty.
NULL char in object name
2.LFL:58860 empty.

15.LFL:40155 empty.
NULL char in object name
17.LFL:52952 empty.

27.LFL:32171 empty.
NULL char in object name
29.LFL:60388 empty.

40.LFL:67360 empty.
NULL char in object name
NULL char in object name
40.LFL:73432 empty.
40.LFL:73440 empty.
NULL char in object name
41.LFL:43659 empty.

42.LFL:72972 empty.
NULL char in object name
NULL char in object name
NULL char in object name
NULL char in object name
44.LFL:41304 empty.

46.LFL:63229 empty.
NULL char in object name
NULL char in object name
NULL char in object name
46.LFL:64678 empty.

49.LFL:57900 empty.
NULL char in object name
49.LFL:60542 empty.

50.LFL:95148 empty.
NULL char in object name
NULL char in object name
50.LFL:98281 empty.

50.LFL:102399 empty.
NULL char in object name
51.LFL:98472 empty.

51.LFL:98668 empty.
NULL char in object name
51.LFL:98783 empty.

51.LFL:99214 empty.
NULL char in object name
51.LFL:99347 empty.
51.LFL:99355 empty.
NULL char in object name
51.LFL:99586 empty.

55.LFL:111026 empty.
56.LFL:33329 empty.
56.LFL:33393 empty.
NULL char in object name
56.LFL:33457 empty.
NULL char in object name
56.LFL:33521 empty.
NULL char in object name
56.LFL:33585 empty.
NULL char in object name
56.LFL:33649 empty.

59.LFL:58079 empty.
NULL char in object name
59.LFL:58134 empty.
NULL char in object name
59.LFL:60854 empty.
60.LFL:27582 empty.
60.LFL:27590 empty.
NULL char in object name
NULL char in object name
62.LFL:88234 empty.

62.LFL:88862 empty.
NULL char in object name
NULL char in object name
NULL char in object name
64.LFL:33803 empty.
NULL char in object name
NULL char in object name
NULL char in object name
66.LFL:97678 empty.

66.LFL:100044 empty.
NULL char in object name
NULL char in object name
68.LFL:18992 empty.
68.LFL:19000 empty.
69.LFL:54232 empty.
NULL char in object name
NULL char in object name
69.LFL:54679 empty.

72.LFL:95460 empty.
NULL char in object name
74.LFL:63124 empty.

75.LFL:89792 empty.
NULL char in object name
NULL char in object name
76.LFL:88130 empty.

96.LFL:27313 empty.
NULL char in object name
97.LFL:70278 empty.
97.LFL:70765 empty.
line missing
98.LFL:52766 empty.

98.LFL:58649 empty.
updating ATLANTIS.000