[NDS] Développement d'un outil de ROM Hacking HG/SS

Ribesg - 17 juillet 2015 à 12:50

EDIT: Les sources et des releases sont disponibles sur Github : https://github.com/Ribesg/PkmnEditor

Voici mon premier post sur ce forum, si vous voulez savoir qui je suis cliquez ici, sinon ne cliquez pas ici.

J'ai récemment cherché à créer un petit hack de HG pour changer les starters, modifier tous les pokémons avec évolutions complexes pour retirer le besoin d'échanger (ou plutôt le rendre optionnel), modifier un peu la répartition des pokémons sauvages et modifier les dresseurs pour augmenter la difficulté. J'ai trouvé un certain nombre d'outils, tous plus mauvais les uns que les autres (Mention spéciale pour PPRE qui en est à sa troisième réécriture sans jamais atteindre un niveau utilisable).

J'ai donc commencé à développer mon propre outil. Comme vous le savez surement si vous avez cliqué sur le bon lien plus haut, je n'ai aucun problème au niveau programmation. Mon problème est plutôt au niveau des informations. Pour l'instant mon objectif est de faire un petit logiciel graphique pour changer les starters, la seule chose que je comprends dans son intégralité : extraire le arm9.bin de la ROM, modifier les 3 valeurs au bon endroit, recompresser le arm9.bin et reconstruire la ROM. J'en suis à l'implémentation des algorithmes de compression/décompression (LZSS, ONZ ou "LZSS 0x11", le reste devrait suivre. J'ai déjà trouvé q(http://www.pokecommunity.com/showthread.php?t=295124)[e](http://traf.romhack.org/WikiTraf/index.php/Les_bases_du_hack_NDS)[l](https://code.google.com/p/darthnemesis/source/browse/trunk/DarthNemesis/CompressionManager.cs)[q](http://www.metroid2002.com/retromodding/wiki/LZSS_Compression)(http://traf.romhack.org/index.php?p=tutos&tid=33&aff=avis)[e](http://llref.emutalk.net/projects/ctool/) références, mais je voulais savoir si vous aviez quelque tuyaux

Le projet sera très probablement libre comme beaucoup de mes projets, mais j'attends déjà d'avoir quelque chose qui fonctionne avant.

Toute aide serait la bienvenue, merci

PS: Attention je ne demande pas ici comment réaliser ces opérations avec tel ou tel outil (j'ai déjà partiellement réussi), mais plutôt comment ces outils réalisent ces opérations. Code source, documentations techniques, offsets connus, tout cela m'intéresse.

yago58 - 17 juillet 2015 à 14:05

Le log existe déjà, dsl.

En revanche, si tu étais capable de décrypter les moves tutors, ça, ça serait un vrai plus.

Ribesg - 17 juillet 2015 à 14:45

Quel "log" ?

yago58 - 17 juillet 2015 à 14:46

Editeur de starter.

Ribesg - 17 juillet 2015 à 14:55

Il s'agit là de mon premier objectif, de la première étape. Je développe de façon incrémentale. Les autres fonctionnalités viendront ensuite, quand j'aurai compris comment est organisée la ROM à ce niveau là, et ce qui doit être fait. J'ai parlé de la modification de starters car c'est pour l'instant la seule chose que je comprends intégralement.

J'ai déjà trouvé des outils basiques qui ne font qu'une seule action (comme changer les starters) et d'autres qui font beaucoup de choses. PPRE ne fait que crash aléatoirement, il est extrêmement instable. Quand à Spiky's DS Map Editor, les ROM produites sont corrompues, sauf si on utilise une version de développement (et encore, là, certaines choses ne fonctionnent tout simplement pas, de façon aléatoire).

Utiliser plusieurs petits outils à la suite peut poser des problèmes, les bugs de chacun d'eux s'accumulant. Par exemple il est déconseillé d'utiliser un outil sur une ROM avant de la "passer dans" PPRE car il pourrait mal le prendre.

Donc en pratique je n'ai pour l'instant besoin de rien (à part plus d'infos sur la compression LZSS made in Nintendo, même si j'ai l'impression d'avoir un truc qui pourra marcher) jusqu'à ce que la partie starters soit finie, ensuite je suis dans le brouillard. C'est pour ça que je demande où trouver plus d'infos ici, en avance de phase.

yago58 - 17 juillet 2015 à 15:02

Le meilleur moyen d'éviter les bugs sur ppre c'est d'extraire les narc et de les ré-insérer dans une rom clean J'ai de la pratique à ce niveau.

Pour les infos, y a pas grand chose, pokécommunity et project pokémon sont les plus "fournis"

Ribesg - 17 juillet 2015 à 15:09

Justement, c'est ce genre de choses que je veux éviter. J'ai bien vu sur ton tutoriel d'utilisation de PPRE, tu décris un paquet de workaround nécessaires à l'utilisation du logiciel. Il faut renommer la ROM car le logiciel ne sait pas lire l'Unicode, il faut supprimer un dossier temporaire que le logiciel "oublie" et semble incapable de relire correctement, la taille finale de la ROM qui n'est pas bonne (Donc la compression et la décompression de la ROM ne sont pas miroir), et le besoin d'extraire et de réintégrer les narc avec un autre logiciel pour que ça puisse fonctionner un peu mieux.

Je pense qu'il est préférable de pouvoir se concentrer sur le hack en lui-même plutôt que de se battre avec des outils faits avec les pieds !

Mickey` - 17 juillet 2015 à 15:14

L'extraction et la réinsertion des narcs ne buguent pas que je sache, si ? Je me trompe peut-être, mais si ça ne pose pas de problème, il sera plus simple de travailler directement sur les narcs décompressés.

yago58 - 17 juillet 2015 à 15:20

nop ça bug pas, à partir du moment où tu remets les narc au bon endroit. Néanmoins je reconnais que logiciel multi-fonction "peut être" utile, d'ailleurs il me semble qu'il existe un autre log dans le même style que ppre (plus stable d'ailleurs) Le soucis c'est qu'il travaille directement sur la rom, hors pour certaines manips il faut quand même sortir le narc.

Je dis ça, mais aujourd'hui hgss, c'est le cadet de mes soucis.

Mickey` - 17 juillet 2015 à 15:22

Ouais mais je préfère extraire et manipuler sans bug perso...

yago58 - 17 juillet 2015 à 15:29

C'est que ce que je fait aussi. comme ça je localise les bugs/gaffes/oublis plus facilement.

Ribesg - 17 juillet 2015 à 15:39

De ce que j'ai compris, les ROM contiennent certains fichiers spéciaux "en dur", comme le arm9 et le arm7, puis il y a un véritable système de fichier (avec une table FAT et tout). C'est à l'intérieur de ce système que se trouvent les fichiers .narc. Leur extraction est donc extrêmement simple, il suffit de le copier dans un fichier sur le système de fichiers de l'OS. Pour la réinsertion, ça n'est pas compliqué non plus, mais cela nécessite (s'il sa taille a changé après edition, et uniquement dans ce cas) de mettre à jour la table FAT pour le fichier narc et pour tous les suivants dans la table, rien de compliqué.

Ce qui est compliqué, c'est la décompression et la recompression des fichiers arm9 et arm7 s'ils sont compressés, mais aussi des fichiers de la ROM comme les fichiers narc qui peuvent aussi être compressés. Le problème vient du fait que Nintendo utilise des versions modifiées d'algorithmes connus, algorithmes qui ne sont donc documentés nulle part...

hremeraude - 18 juillet 2015 à 13:44

http://projectpokemon.org/rawdb/heartgold/

Ici tu trouveras les localisations de tous les fichiers de HG, sinon tu peux toujours demander à SCV comment il a procéder.

Ribesg - 18 juillet 2015 à 14:43

Tiens j'étais tombé là dessus mais je ne le retrouvais plus, merci

Je viens de réussir à décompresser le arm9.bin avec succès. Il semble qu'il n'y ait même pas besoin de le recompresser pour le remettre dans la ROM après modification, puisque les ROM supportent les arm9.bin non compressés. Il doit juste y avoir quelque pointeurs à éditer étant donné que la taille est différente.

yago58 - 18 juillet 2015 à 14:47

Il est pas complet celui là, hremeraude.

http://www.projectpokemon.org/wiki/HGSS_File_System, celui la, oui.

hremeraude - 18 juillet 2015 à 15:05

There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page.

yago58 - 18 juillet 2015 à 15:08

Bleh bleh bleh, corrigé, na.

Ribesg - 18 juillet 2015 à 18:41

J'ai un problème qui fait que les émulateurs et ma 3DS refusent ma rom. J'ai observé que plusieurs outils se contentent de décompresser les fichiers comme arm9.bin, ils ne les recompressent pas, vu que une ROM peut très bien contenir un arm9 non compressé.

Mais quand je remets mon arm9.bin décompressé dans la ROM, même en éditant les pointeurs qui vont bien et le CRC du header, ça plante :(

Ribesg - 22 juillet 2015 à 14:58

J'en suis toujours au même point. Le code source complet est disponible ici https://github.com/Ribesg/PkmnEditor

En debuggant avec No$GBA, j'ai pu voir pourquoi j'avais un écran blanc (sur émulateur ou hw) : à un moment, l'exécution jump en PLEIN MILIEU d'une zone de données (et non de code) et essaye d'exécuter ces données, faisant absolument n'importe quoi. L'instruction qui explose est SWI #123456 (0x563412EF), qui n'a effectivement pas de sens.

Je suis en train de chercher de l'aide au sein de la communauté anglophone, surtout sur IRC. Mais ça s'annonce compliqué.

Tout ça pour changer trois malheureux entiers (12 petits octets) dans un fichiers de plus d'1Mo.

hremeraude - 22 juillet 2015 à 16:15

le mieux est de demander aux mecs ayant faits des logs sur HGSS sur PPORG, ce sera le meilleur endroit où trouver de l'aide je suppose

Ribesg - 23 juillet 2015 à 09:20

Hey !

Donc avec l'aide de quelque anglophone, j'ai pu finir de tuer les derniers bugs. Il m'en reste un vraisemblablement, mais il n'empêche pas la rom de fonctionner parfaitement : le arm9 que je décompresse n'a pas tout à fait la même taille que ce qu'obtient un autre développeur de son côté quand il essayait de m'aider. Après avoir cherché pourquoi pendant des heures, j'ai quand même essayé la rom, et elle marche !

Donc ma Proof of Concept, ici présente https://github.com/Ribesg/PkmnEditor, fonctionne. Ce n'est pas un encore un logiciel, juste une PoC, donc pour l'instant c'est un peu compliqué à exécuter pour les non-développeurs et ça remplace les starters par des valeurs hardcodées (Goinfrex, Riolu et Keunotor). Mais ça fonctionne et il n'y a plus qu'à réorganiser tout ça pour que ça donne un truc bien.

Prochaine étape, le texte !

TheCaptainSnow - 23 juillet 2015 à 10:48

Ça à l'air prometteur si tu arrive à faire quelque chose de propre. Une question : tu compte développer uniquement pour windows ou tes logs seront multiplateforme? Et j'ai vu que tu compte éventuellement rajouter le support pour SS mais ne te presse pas pour ça, de mon point de vue c'est pas très utile et surtout ça risque plus de compliqué la tache pour les débutants ne savant pas quelle version choisir. En effet depuis les versions gba on constate que l'une des versions prend toujours le dessus sur l'autre (rf > vf, rubis > saphir, etc) d'un points de vue recherche (souvent par flemme de chercher les offsets pour la version miroir), et ce n'est pas gênant, ça simplifie même l'entraide car les offsets des uns colle avec les offsets des autres.

Ribesg - 23 juillet 2015 à 11:06

Je pense faire un système de configuration définissant les offsets. Par exemple on aurait un fichier pour HG FRA, SS FRA, HG USA, SS USA, et ainsi de suite. La rom serait reconnu selon son header et le bon fichier de configuration serait utilisé. Ainsi, vu que le projet est Open Source, tout le monde pourra trouver les offsets de sa ROM et les ajouter. Après, je ne sais pas si ce sera forcément nécessaire, à voir si des offsets diffèrent vraiment. Par exemple je ne prévois pas de faire d'éditeur de map etc (après c'est Open Source, donc ça peut se faire même si je le fais pas). Je ne sais pas ce qui nécessite de connaitre offsets, vu que pour l'instant je n'ai que modifié les starters... qui nécessite des offsets (en fait, un seul), mais bon. Un fichier par version pour stocker un seul petit entier, bof.

Au départ je voulais faire un outil en pur Java, donc multi-plateforme, malheureusement certaines des tâches sont trop complexes pour que je les réimplémente, comme l'unpack de la ROM ou (surtout en fait) le repack de la ROM, qui sont fait avec ndstool.

Je prévois de wrap ndstool dans le jar du logiciel, et de l'extraire dans un dossier temporaire avant de l'utiliser. Donc s'il est possible d'avoir des version de ndstool pour Linux (et Mac pourquoi pas), je peux les ajouter et les utiliser. C'est la seule chose qui empêche le tout d'être multi-plateforme.

Ah et sinon pour la modification de starter, là mon prochain objectif c'est de pouvoir modifier les textes en général et aussi en particulier au changement de starter : ça dit toujours "Voulez-vous choisir Germignon, le Pokémon Plante ?" par exemple. Donc ça ce sera assez facile d'après ce que j'ai vu, la difficulté ça va être pour le cri. Quand on fait tourner les pokéball pour choisir le starter, on entend le cri du pokémon. Sauf que c'est les cri des starters d'origine, donc il doit y avoir un autre offset où sont stockés les références des cris. Il faut que je trouve ça. Ca ferait déjà 2 offsets pour ces fichiers de config.

EDIT : Je souhaite de toutes façons faire un outil propre, "pour noob", donc d'un point de vue utilisateur, HG et SS ça doit être pareil. Certes le support de SS complexifie le truc, mais trouver les offsets dans d'autres ROMs quand tu les as dans une, c'est assez facile en général. Par exemple là, j'ai l'offset des starters dans HG. Je regarde ce qu'il y a comme valeurs à cet offset et après, puis je cherche ces valeurs dans mon ROM SS, et paf j'ai ma offset SS. Comparé à trouver un offset "from scratch", c'est extrêmement simple.

Mickey` - 23 juillet 2015 à 13:02

Bien, c'est cool tout ça ! Tu développes en quoi du coup ?

Après, concernant ton problème de version, pourquoi tu crées pas tout simplement un seul fichier ini ou tu mets tous tes offsets nécessaires dedans ?

hremeraude - 23 juillet 2015 à 14:19

Les textes après ils sont localisés dans les narc du jeu, mais si ton truc permet de les éditer directement, ça peut être pas mal du tout, ou alors tu parles de modifier uniquement le texte du starter et ce de manière automatique?

Ribesg - 23 juillet 2015 à 14:24

Bien, c'est cool tout ça ! Tu développes en quoi du coup ?

En Java.

Après, concernant ton problème de version, pourquoi tu crées pas tout simplement un seul fichier ini ou tu mets tous tes offsets nécessaires dedans ?

Parce que c'est plus compliqué à gérer. Imagine plutôt pouvoir faire quelque chose comme

new Offsets(rom.headerString())

Où la méthode headerString() renverrai l'identifiant de la ROM qu'on constituerait du nom ("POKEMON HG" dans ma ROM) et du code ("IPKF" dans ma ROM). Il faudra peut-être ajouter la version de la ROM, je ne sais pas encore. Ensuite tout le reste du code du logiciel est identique, et on utilise cet objet Offsets un peu partout. Bien sûr, cet objet Offsets pourrait alors chercher le bon endroit dans l'unique fichier, mais c'est beaucoup plus simple d'avoir directement un fichier genre "POKEMON HG IPKF.properties" qui match le header. Chacun de ces fichiers sera aussi plus facile à maintenir qu'un seul fichier contenant tous les offsets de 10 roms.

Les textes après ils sont localisés dans les narc du jeu, mais si ton truc permet de les éditer directement, ça peut être pas mal du tout, ou alors tu parles de modifier uniquement le texte du starter et ce de manière automatique?

Je parle de faire les deux Que tu puisses éditer les textes si tu le veux, et que ça change le texte des starters si tu changes les starters. Il faut aussi que je vois comment faire pour traiter les fichiers compressés, car pour l'instant je ne peux que décompresser un arm9 compressé. Les autres fichiers utilisent d'autres algorithmes, donc à voir. Je sais qu'il y a beaucoup d'implémentation disponibles sur le net pour ces algorithmes là (l'algo de l'arm9 étant le plus exotique).

TheCaptainSnow - 23 juillet 2015 à 19:11

Pour extraire les fichiers de la roms NDS (et donc ne plus dépendre de NDSTool) tu peut peut-être t'inspirer des https://github.com/pleonex/tinke/tree/master/Tinke/Dialog. Et pour la decompression de l'arm9 je suis tombé la dessus :https://github.com/magical/nlzss mais je ne sais pas ce que ça vaut mais ça te permet de comparer avec ce que tu à fait.

Ribesg - 23 juillet 2015 à 20:11

Je ne suis pas sûr de vouloir remplacer ndstool pour le moment, il fait beaucoup de choses que j'aurais a gérer moi-même si je le faisais. Après je crois que toutes les sources intéressantes sont ici à peu près https://github.com/pleonex/tinke/tree/master/Tinke/Nitro je verrai si je m'en sers un jour.

Quand à la décompression de l'arm9, mon algo fonctionne bien et m'a déjà été fourni par un anglophone qui l'avait implémenté il y a longtemps. Sur ton lien on n'a que les algos communs, LZ "0x10" et LZ "0x11", l'arm9 est compressé avec un autre algo, plus exotique, que certains appellent BLZ (Bottom LZ) car c'est un LZ un peu spécial et inversé.

J'ai commencé à réorganiser le code en vu du travail à faire ensuite. Donc pour ndstool il me faudra surement des versions linux et mac ( https://github.com/devkitPro/ndstool/issues/1 ) mais j'en suis pas encore là de toutes façons.

Ribesg - 25 juillet 2015 à 16:24

Hey !

Voici la toute première release ! https://github.com/Ribesg/PkmnEditor/releases/tag/v0.0.1 Il doit y avoir des bugs, je ne l'ai pas beaucoup testée, seulement avec la version HG française.

Maintenant le prochain objectif c'est d'éditer les textes donc. Et éventuellement corriger quelque bugs.

hremeraude - 25 juillet 2015 à 16:59

Bien, mais du coup là c'est juste un starter editor pour le moment ?

momo81 - 25 juillet 2015 à 17:14

tout vient à point à qui sait attendre

Ribesg - 25 juillet 2015 à 18:34

Bien, mais du coup là c'est juste un starter editor pour le moment ?

Pour le moment, oui

Je suis en train d'implémenter un unpacker NARC. En fait, j'ai fini. C'est pas très long avec une bonne documentation Maintenant il faut que je vois un peu le format des fichiers de message en eux-même. Ils sont peut-être compressés, ou pas. Il faut aussi que je fasse le repacker NARC.

hremeraude - 25 juillet 2015 à 19:30

D'ailleurs, là quand tu changes le starter, le texte du prof est bien changé ?

Mickey` - 25 juillet 2015 à 19:34

:fail:

hremeraude - 25 juillet 2015 à 19:35

:fail:

Pourquoi être si désobligeant en sachant pertinemment qu'il avait dit qu'il voulait faire ça ? :hum: Ces smiley en disent plus que les mots, c'est fort :o

Ribesg - 25 juillet 2015 à 19:48

D'ailleurs, là quand tu changes le starter, le texte du prof est bien changé ?

Non, c'est ce que je suis en train d'implémenter. Et au passage ça permet d'éditer n'importe quel texte, vu que pour passer de "Texte du prof édité automatiquement" à "Possibilité d'éditer tout texte", il suffit d'ajouter une combobox et un bouton à l'interface...

hremeraude - 25 juillet 2015 à 20:12

ah d'accord, ça aboutira courant août donc ^^

Ribesg - 26 juillet 2015 à 13:28

Je suis retombé sur UPR et j'ai ré-étudié le code. https://github.com/Dabomstew/universal-pokemon-randomizer

En fait, il y a vraiment beaucoup de choses là dedans (y compris plein de choses dont je n'ai pas besoin), mais il y a aussi beaucoup de choses déjà implémentées qui me feront gagner beaucoup de temps. J'ai donc décider de remplacer mon début d'implémentation par le code de ce projet. La licence de mon projet est alors automatique : vu que l'autre projet est GPLv3, le miens aussi ! (la GPL est une licence qui se comporte comme un virus). Ca tombe bien je n'arrivais pas à me décider.

J'ai presque fini de réimplémenter la v0.0.1 en utilisant UPR. Je dois aussi apporter quelque corrections au code d'UPR, par exemple il change les textes de la sélection de starters, mais systématiquement en anglais. Pour pouvoir faire cette partie je dois trouver un moyen de récupérer les noms des types dans la ROM, s'ils existent. J'ai déjà les noms de pokémons dans la langue de la ROM.

Ribesg - 26 juillet 2015 à 20:38

Et hop, version 0.0.2 https://github.com/Ribesg/PkmnEditor/releases/tag/v0.0.2

Permet de changer de starter, ce qui change automatiquement les bons textes, tout en conservant la langue. A noter que lesdits textes contiennent maintenant les 2 types du pokémon... s'il en a 2. La version 0.0.2 permet aussi de modifier n'importe quel texte.

Et cette version est compatible avec tout OS Enfin tout OS qui fait tourner Java... Au moins Windows Mac OSX et Linux. Attention il faut Java 8 ! Si vous n'avez pas Java 8, vous avez déjà un problème de toutes façons x)

hremeraude - 27 juillet 2015 à 16:49

cool, je vais essayer de me faire un p'tit truc sympa avant de partir en vacances

momo81 - 27 juillet 2015 à 20:06

java, c'est pas ce qu'on apelle en général un gouffre à faille de sécurité ? ou javascript je crois

Mourad1081 - 27 juillet 2015 à 20:31

Ni l'un, ni l'autre, c'est Flash qui est réputé pour être un gouffre à faille de sécurité. Java est réputé pour sa lenteur (relatives aux autres langage haut niveau) due au fait qu'il y a un interpréteur qui s'intercale à l'exécution. Après, Ribesg peut me corriger.

momo81 - 27 juillet 2015 à 20:40

autant pour moi

gh7778 - 27 juillet 2015 à 21:03

euuu java est bourré de failles aussi hein, même si en java 8 on en entend moins parler (ça s'est ptetre calmé remarque)

Ribesg - 27 juillet 2015 à 21:16

Haha, du dénigrement gratuit de Java. Classique.

Sachez que le JRE (la chose qui éxécute du bytecode Java (code Java compilé) sur votre PC) n'a pas plus de bugs qu'une autre machine virtuelle. Si vous utilisez un langage genre C ou C++, donc sans machine virtuelle, c'est vous qui faites les bugs, bien souvent beaucoup plus.

Le mythe du Java "lent", ça date des premières versions de Java. Aujourd'hui, une application développée en Java sera bien souvent (beaucoup) plus rapide qu'une application développée en C++, principalement grâce au fait qu'il est très compliqué de faire du code C++ parfait, alors que Java gère beaucoup de choses compliquées tout seul (genre la mémoire !). On peut comparer le vieux Java lent au nouveau Java (7/8) de la même façon que l'on peut comparer le JavaScript d'avant V8 (BEAUCOUP plus lent que Flash) au JavaScript d'après V8 (OMG comme c'est rapide).

Enfin bref même si quand on parle de code 100% parfait Java est légèrement plus lent que C++ au début (ensuite le compilateur JIT* entre en action et là on a des performances rigoureusement identiques), quand on se rend compte que le code parfait n'existe pas, Java > All.

On entend beaucoup parler des failles de sécurités de Java pour la même raison qu'on entend beaucoup parler des failles de sécurité de Windows (alors que PommeOS c'est la grosse bugfest, cf. l'incroyable faille "goto fail" : ça tourne sur la majeure partie des machines du monde.

En gros, le JRE (enfin, la JVM quoi) va détecter qu'un bout de code est exécuté plutôt souvent, et va décider de le compiler en assembleur pour pouvoir l'exécuter plus vite par la suite. JIT = "Just In Time", on compile juste avant / pendant l'exécution, contrairement au C++ qui est compilé de façon statique... Ce qui fait que son compilateur est bien moins efficace :D

PS : Oui j'aime Java, principalement parce que j'ai la chance d'avoir l'expérience requise permettant de se rendre compte que, ben, en fait, c'est bien Java.

yago58 - 27 juillet 2015 à 21:33

Bien, la discution anti-Java et pro-Java va stopper maintenant. Risbesg, tu programmes comme tu veux à partir du moment où ça fonctionne correctement.

Je connais assez le forum pour savoir que ce genre de discussion dérape rapidement.

gh7778 - 27 juillet 2015 à 21:37

uhm, disons que pour un truc autant utilisé que java, se rendre compte qu'il y'a un max de failles (192 dont 25 critiques corrigés pour la dernière version) ça fait regarder d'un mauvais oeil, surtout quand tu sais que les applis en C, si y'a des failles, c'est juste parce que le dev a mal codé son truc.

Perso pour la vitesse d'exécution je suis prêt à te croire les yeux fermés, je code pas en java et php se traîne une réputation de lenteur similaire qui n'a plus lieu d'être, j'imagine facilement que c'est pareil pour java.

Par contre java n'est pas le best déso, et ce ne serait-ce que parce que tu est obligé d'installer un programme tiers :3

édit : raaah yago pas drole :(

Ribesg - 27 juillet 2015 à 21:48

Java n'a pas plus de failles, il est seulement plus observé. Donc parmi toutes les failles, on en trouve + que pour d'autres systèmes moins étudiés.

Sinon pour revenir au sujet, quelqu'un l'a essayé ce programme ? Pas de bugs à signaler ? Je suis très habitué aux noms français des pokémons, donc si quelqu'un habitué aux noms anglais veut faire une partie pour tester...

Sinon là je ne sais pas ce que sera la prochaine étape, mais très probablement l'édition de dresseurs. Viendra ensuite l'édition de pokémons sauvages. Il semble y avoir ce qu'il faut dans les sources que j'ai récupérées, j'aurai peut-être des choses à modifier pour l'une ou l'autre de ces tâches, comme j'ai dû le faire pour le changement de texte du choix des starters.

Je ne sais pas encore. A suivre donc.

PS : Désolé Yago, je suis tombé dans le piège des trolls !

momo81 - 27 juillet 2015 à 22:21

Ouais bon yago faut pas abuser non plus. Le delete de post + cette remarque sur une simple question même pas "trolleuse"... ca fait beaucoup la

yago58 - 27 juillet 2015 à 22:35

Où vois-tu de l'abus sur ce topic ? tu te trompe de topic, il me semble.

Quant au posts delete, tu sors des conneries.

gh7778 - 27 juillet 2015 à 22:36

@ribesg : j'avais pas pour intention de troller, juste que yago tue le débat dans l'oeuf qui est pas drole bon courage pour la suite en tout cas

momo81 - 27 juillet 2015 à 22:36

Bien, la discution anti-Java et pro-Java va stopper maintenant. Risbesg, tu programmes comme tu veux à partir du moment où ça fonctionne correctement.

Je connais assez le forum pour savoir que ce genre de discussion dérape rapidement.

yago58 - 27 juillet 2015 à 22:42

@ribesg : j'avais pas pour intention de troller, juste que yago tue le débat dans l'oeuf qui est pas drole bon courage pour la suite en tout cas

Je sais bien que l'intention première c'est pas de troller, mais c'est pas l'endroit, merci pour l'oeuf dur, manque la mayo.

Bien, la discution anti-Java et pro-Java va stopper maintenant. Risbesg, tu programmes comme tu veux à partir du moment où ça fonctionne correctement.

Je connais assez le forum pour savoir que ce genre de discussion dérape rapidement.

C'est pourtant la vérité.

@Ribesg, pour les dresseurs il faudra prendre en compte le fait du pokématos, si tu veux je peux te fournir une liste complète des dresseurs.

Ribesg - 28 juillet 2015 à 20:23

Hmm, je viens de regarder et pour les trainers je peux avoir leurs noms, classes et pokemons. Par contre je n'ai pas leur emplacement. Il faudrait que je vois comment trouver leurs emplacements, il doit y avoir un id ou quelque chose comme ça, et une liste de map quelque part.

EDIT : Donc il semblerait que le format des données soit identique en D/P/Pt/HG/SS, ça devrait faciliter mes recherches de ce coté EDIT2 : Très bien, donc le trainer ne porte pas l'information de son emplacement. Ca doit plutôt être les maps qui références les trainers. Hm.

yago58 - 28 juillet 2015 à 20:50

J'ai les emplacements, et les ID

Ribesg - 28 juillet 2015 à 20:54

Ah bien ! Tu sais où je peux trouver la liste des emplacements aussi ? Je voudrais afficher les noms des emplacements dans la langue de la ROM, avec le texte de la ROM.

Quoique si je recherche les noms des emplacements dans tous les textes, je peux trouver où ils sont en fait, de la même façon que j'ai trouvé les types.

EDIT: Hop, j'ai trouvé les noms des emplacements Fichier de messages 279

yago58 - 28 juillet 2015 à 21:02

Les ID+ nom du dresseur, et lieu de rencontre, mais je peux pas te fournir les pokémon.

Ribesg - 28 juillet 2015 à 21:10

En fait il me faut un mapping N°Dresseur => N°Location Le reste j'ai !

yago58 - 28 juillet 2015 à 21:12

552 Gamin Luc route 3 ?

Ribesg - 28 juillet 2015 à 21:34

Ça correspond à ce que je vois pour le numéro et le nom. La route ben je sais pas

yago58 - 28 juillet 2015 à 21:41

si si c'est ça, c'est bon pour toi ? dans ce cas check tes mp, y a une tartine.

Ribesg - 28 juillet 2015 à 21:57

J'ai pas reçu de MP, c'est censé prendre du temps ?

yago58 - 28 juillet 2015 à 22:14

Ben en même temps, tu m'as pas dit si ça te convenais

Ribesg - 28 juillet 2015 à 22:17

Ha ok. Ben oui ça me va x)

yago58 - 28 juillet 2015 à 22:27

Envoyé

Ribesg - 31 juillet 2015 à 17:03

J'ai redéveloppé entièrement l'interface en utilisant JavaFX. J'avais peur de l'utiliser alors j'avais commencé avec Swing que je connais bien, et finalement j'ai voulu essayer. JavaFX > Swing, y'a pas photo.

Je suis donc revenu au niveau de features de la version 0.0.2 et j'ai commencé à travailler sur l'édition de dresseur. Ce sera l'édition de pokémon de dresseur qui prendra le plus de temps je pense.

Voilà à quoi ressemble l'interface : http://i.imgur.com/YyqUgN9.png](http://i.imgur.com/YyqUgN9.png)

yago58 - 31 juillet 2015 à 17:07

Ho un vrai éditeur de texte .

Le fichier, que je t'ai passé, ça donne quoi ?

Ribesg - 31 juillet 2015 à 18:04

Je suis en train de le convertir à la main en quelque chose d'utilisable là, ça devrait pas prendre trop de temps.

Pour le texte il faut encore que je détermine ce que signifient certains caractères, par exemple la différence entre \n, \r et plusieurs autres utilisés par le jeu pour séparer des lignes. Je connais évidemment ces caractères, mais je ne sais pas exactement comment le jeu les interprète, ni pourquoi il n'y a pas que des \n.

gh7778 - 31 juillet 2015 à 18:14

compilation sous windows, cherche pas plus loin. Le jeu doit avoir besoin des 2, comme pour windows (hypothèse cette fois)

Ribesg - 31 juillet 2015 à 18:20

Absolument pas. Ils ne sont jamais utilisés en même temps dans les textes. De plus le caractère \n est le caractère de saut de ligne, le caractère \r est le caractère de retour en début de ligne, ils ont chacun leur sens précis aujourd'hui. Windows utilise la combinaison \r\n par soucis de compatibilité avec MS-DOS, qui l'utilisait lui par soucis de compatibilité avec un autre système. C'est historique mais ça n'a rien à voir avec mon soucis. Mon soucis c'est de comprendre pour quelle raison précise chaque caractère est utilisé à tel ou tel endroit. Des fois c'est \n, des fois \r, et j'en ai vu d'autres plus étranges.

Aura Azure - 31 juillet 2015 à 18:27

\n = retour à la ligne complet, le jeu saute deux lignes à la fois \r = le jeu ne saute qu'une ligne

Ribesg - 31 juillet 2015 à 18:38

Erf en fait ton fichier Yago il est plus difficile à utiliser que je le pensais. Je vais mettre ce que j'ai dans un fichier sur le repo pour l'instant.

yago58 - 31 juillet 2015 à 19:10

Y a plusieurs semaines de boulot dans ce fichier.

Ribesg - 31 juillet 2015 à 19:33

Oui, mais il faut que je trouve un moyen d'utiliser toutes les données justement

Pour l'instant j'ai pu générer ça avec les 4 premiers feuilles (Johto): https://gist.github.com/Ribesg/ff0881620b6997a83cdd

En gros l'ID de "location" est un pointeur vers une chaine de caractère dans les messages du jeu qui correspond au lieu. La plupart des lieux sont naturellement dans la liste des lieux du jeu, fichier 279, donc il est omis. Parfois il faut faire des choses plus compliquées, comme 604-8-0. Ca signifie la première (0) ligne du texte 8 du fichier 604. En effet ce texte est ainsi dans la rom fr : "Phare d'Oliville\rAussi connu sous le nom de\nphare étincelant" et je veux récupérer la chaine "Phare d'Oliville".

J'ai aussi ajouté la possibilité de mettre un micro-commentaire avec / comme pour "15/1" qui donne "Ligue Pokémon (1)" (pour dire que c'est le premier passage).

Il faut que je continue avec les feuilles sur Kanto et que je vois quoi faire des feuilles du pokematos aussi.

gh7778 - 31 juillet 2015 à 19:41

weby, le \n est un saut de ligne, ou un changement d'écran du coup ? Vu que dans pokemon de mémoire y'a que 2 ligne de texte par écran

Ribesg - 31 juillet 2015 à 19:47

@Guitoh c'est ce que je comprends oui.

Aura Azure - 31 juillet 2015 à 19:52

De ce que je me rappelle du texte GBA, y'a un saut de ligne rapide et un saut de ligne lent.

Par exemple :


1
2\n
3
4

apparaîtrait comme tel :

1
2

et en appuyant sur A

3
4

Tandis que


1
2\r
3
4

ferait apparaître

1
2

puis, quand la ligne 2 est complèẗement finie d'afficher, ça continuerait, sans avoir besoin d'appuyer sur A, à afficher la suite du texte, en l'occurence, la ligne 3, en supprimant la ligne 1.

Je ne sais pas si c'est \n, \r, ou n'importe quelle autre combinaison, mais y'avait une combine du genre.

Ribesg - 31 juillet 2015 à 20:20

Voici ma map Location -> Trainer. Il reste un paquet de dresseurs sans Location en bas du fichier, une bonne partie de rematchs.

https://github.com/Ribesg/PkmnEditor/blob/master/src/main/resources/locationToTrainerMap.yml

EDIT: J'ai traité la plupart des rematch, ils reste du bordel. C'est quoi tous ces Danny là ?

yago58 - 31 juillet 2015 à 21:12

Pour combler les trous, t'en occupe pas. J'ai rien trouver en correspondance.

Mourad1081 - 2 août 2015 à 12:29

MP Risberg