Note: le tool a pas mal évolué depuis ce premier post. Pensez à regarder les différentes mises à jour:- [Update 1](https://cadernis.com/d/2465-parseur-de-protocole).- [Update 2](https://cadernis.com/d/2465-parseur-de-protocole).- [Update 3](https://cadernis.com/d/2465-parseur-de-protocole).- [Update 4](https://cadernis.com/d/2465-parseur-de-protocole).- [Update 5](https://cadernis.com/d/2465-parseur-de-protocole) (exécutable Windows fonctionnel).Post originel:-------------------------------------------------------------Bien le bonjour la communauté!Voici mon premier vrai post de partage ici. Je viens de finir mon parseur de protocole, un "remplacement" à l'outil [d2json](https://cadernis.com/d/1876-d2json-extraire-les-informations-du-jeu/1) de @"Lakh92"#58 .Le but de l'outil? Faire en sorte de ne pas dépendre de décompilateurs SWF lourds tels que FFDec et de systèmes d'expression régulières compliqués pour générer son protocole réseau.Concrètement? Vous lancez l'outil sur le DofusInvoker.swf, et en quelques secondes vous obtenez un JSON ayant cette forme:``` { "default": { "field": { "boolean_byte_wrapper_position": -1, "bounds": null, "constant_length": 0, "default_value": "", "name": "", "namespace": "", "null_checked": false, "prefixed_by_type_id": false, "self_serialize_method": "", "type": "", "type_namespace": "", "use_boolean_byte_wrapper": false, "write_false_if_null_method": "", "write_length_method": "", "write_method": "", "write_type_id_method": "" } }, "enumerations": [ { "entries_type": "uint", "members": { "HOOK_POINT_CATEGORY_BASE_BACKGROUND": "4", "HOOK_POINT_CATEGORY_BASE_FOREGROUND": "6", "HOOK_POINT_CATEGORY_LIFTED_ENTITY": "3", "HOOK_POINT_CATEGORY_MERCHANT_BAG": "5", "HOOK_POINT_CATEGORY_MOUNT_DRIVER": "2", "HOOK_POINT_CATEGORY_PET": "1", "HOOK_POINT_CATEGORY_PET_FOLLOWER": "7", "HOOK_POINT_CATEGORY_UNDERWATER_BUBBLES": "8", "HOOK_POINT_CATEGORY_UNUSED": "0" }, "name": "SubEntityBindingPointCategoryEnum" }, // ... ], "messages": [ { "fields": [ { "default_value": "false", "name": "quiet", "type": "Boolean", "write_method": "writeBoolean" }, { "default_value": "false", "name": "_isInitialized", "namespace": "com.ankamagames.dofus.network.messages.common.basic", "type": "Boolean" } ], "name": "BasicPingMessage", "namespace": "com.ankamagames.dofus.network.messages.common.basic", "protocolID": 182, "super": "NetworkMessage", "supernamespace": "com.ankamagames.jerakine.network", "use_hash_function": false }, // ... ], "types": [ { "fields": [ { "bounds": { "low": "-9007199254740992.000000", "up": "9007199254740992.000000" }, "default_value": "0", "name": "contextualId", "type": "Number", "write_method": "writeDouble" }, { "name": "_dispositiontree", "namespace": "com.ankamagames.dofus.network.types.game.context", "type": "FuncTree", "type_namespace": "com.ankamagames.jerakine.network.utils" }, { "name": "disposition", "prefixed_by_type_id": true, "self_serialize_method": "serialize", "type": "EntityDispositionInformations", "type_namespace": "com.ankamagames.dofus.network.types.game.context", "write_type_id_method": "writeShort" } ], "name": "GameContextActorPositionInformations", "namespace": "com.ankamagames.dofus.network.types.game.context", "protocolID": 566, "super": "", "supernamespace": "", "use_hash_function": false }, // ... ], "version": { "client": { "build": { "date": { "day": 1, "full": "2020-4-1 13:45", "hour": 13, "minute": 45, "month": 4, "year": 2020 } }, "major": 2, "minor": 55, "patch": 1 }, "parser": { "major": 0, "minor": 2 }, "protocol": { "date": { "day": 13, "full": "2020-3-13 14:43", "hour": 14, "minute": 43, "month": 3, "year": 2020 }, "version": { "current": 1966, "minimum": 1966 } } } } ```L'outil n'en est qu'à sa version préliminaire, il y a encore quelques informations facilement accessibles que j'aimerai rajouter dans le JSON. Idéalement, j'aimerai aussi implémenter de quoi filtrer les informations contenues dans le JSON avec des flags lors de l'appel à l'exécutable.J'ai pensé l'outil pour être facilement extensible. Si le JSON généré ne contient pas les informations que vous désirez, envoyez moi un petit message sur discord @"Nelimee"#1167 ou répondez à ce post, je ferais mon possible pour ajouter les informations demandées.Le plus important, les dépôts git sont bien entendu en accès libre:- [IOs](https://gitlab.com/botofu/ios), la bibliothèque qui gère les I/Os de base.- [SwfParser,](https://gitlab.com/botofu/swfparser) la bibliothèque qui s'occupe de parser le format SWF (le format du DofusInvoker.swf) et de désassembler le bytecode ABC (bytecode utilisé dans le DofusInvoker.swf pour l'implémentation de toutes les fonctions/méthodes).- [protocol_parser](https://gitlab.com/botofu/protocol_parser), qui va s'occuper d'extraire les informations qui nous intéressent du bytecode ABC désassemblé.Quelques idées d'améliorations qui seront probablement implémentées dans les jours/semaines qui arrivent (si vous avez des idées pour allonger la liste, vous savez où me joindre):- Ajouter une documentation digne de ce nom. Pour l'instant, on va dire que la documentation est plutôt parsemée et je la juge insuffisante pour rentrer dans le code facilement en partant de 0. Priorité numéro 1.- Ajouter les 2-3 fonctionalités dont j'ai déjà parlé comme- plus d'information dans le JSON généré. Il y a 2-3 informations accessibles que je n'ai pas sérialisés et ça ne sera pas très long à ajouter.- pouvoir filtrer avec des flags les informations contenues dans le JSON.- ajouter une entrée "default" quelque part dans le JSON pour éviter d'avoir à préciser dans chaque entrée les termes qui n'ont pas de sens.- avoir 2 dates sous le même format dans le champs "version".- (plus long terme) pouvoir faire des diff propres entre 2 versions du protocole.- Même si la tâche me semble non triviale à réaliser correctement, j'aimerai bien avoir un bon moyen de tester l'implémentation de façon automatique. Soit des tests unitaires, soit des tests un peu plus larges tels que la comparaison- Confirmer que la fonctionnalité de signalisation des sérialisations non-matchées par le parseur est solide. Pour l'instant le tool affiche un warning pour toute instruction qui vérifie toutes les conditions suivantes:- Le nom de la méthode appellée commence par "write" ou "serialize"- L'instruction d'appel de méthode ne fait pas partie d'un ensemble d'instruction qui a déjà été reconnu comme un "ensemble d'instruction connu".J'inclus dans ce post une [version du code compilée par mes soins pour Linux](https://mega.nz/file/PkAkhIQQ#D42m-C6YilicWxJHHOO6QSxOGYiMDRCi2WfvMDXBKbQ) (**outdated**, voir updates en fin de post). J'ai essayé de cross-compiler pour Windows, je me suis souvenu de pourquoi j'étais passé sous Linux, et du coup je n'ai pas d'exécutable Windows à vous passer. Je vous invite à le compiler vous-même, en théorie le code est portable sur n'importe quelle plateforme ayant un compilateur avec un support partiel du C++17. D'ailleurs, je n'utilises qu'assez peu les fonctionnalités du C++17 donc ça ne devrait pas être trop dur de passer en C++14 (voire même C++11) si vous n'avez pas de compilateur C++17 sous la main.Pour finir:``` ./protocol_parser --help Protocol parser for the Botofu project Usage: ./protocol_parser [OPTIONS] DofusInvokerPath ExportPath Positionals: DofusInvokerPath TEXT:FILE REQUIRED Path to the DofusInvoker.swf ExportPath TEXT REQUIRED Path to the file that will contain the output of the protocol parsing. Options: -h,--help Print this help message and exit -i,--ident INT Number of spaces used to indent resulting JSON. Default to minified (0). ```A plus!Nelimee

Merci du partage c'est vachement cool ton tool

Salut, Enfin quelque chose de nouveau ! Ca fait plaisir Si tu veux une petite idée supplémentaire, tu pourrais fournir une image Docker de ton tool, le rendant plus simple d'utilisation et par définition cross-platform. Avec un volume partagé, ou simplement en image de base et on ajoute les swf a la main dans le workdirOn pourrait ainsi s'imaginer l'utiliser simplement dans une chaine de CI avec Gitlab ou Azure PipelinesCa manque cruellement de tests comme tu l'as dit mais à toi de compléter ton code avecEncore bravo !

> @"DrBrooklyn"#p25011 Salut,Enfin quelque chose de nouveau ! Ca fait plaisirSi tu veux une petite idée supplémentaire, tu pourrais fournir une image Docker de ton tool, le rendant plus simple d'utilisation et par définition cross-platform. Avec un volume partagé, ou simplement en image de base et on ajoute les swf a la main dans le workdirOn pourrait ainsi s'imaginer l'utiliser simplement dans une chaine de CI avec Gitlab ou Azure PipelinesCa manque cruellement de tests comme tu l'as dit mais à toi de compléter ton code avecEncore bravo ! Mais c'est que c'est une excellente idée! Je fais ça demain ;)

très bel outil, c'est ce genre de truc qui m'aurait bien aidé.

Super job! Voici quelques idees que j'ai pu faire sur le mien:- un champ pour savoir si le message utilise la hashFunction ou non- en cas d'utilisation du boolean byte wrapper, dire a quel position il est (si tu la fais excuse moi j'ai pas vu)

Petite update:- J'ai rajouté 2-3 informations faciles à grapiller dans le JSON:- Usage de la HASH_FUNCTION ou non dans "use_hash_function".- La position du bit si le BooleanByteWrapper est utilisé dans "boolean_byte_wrapper_position" (c'était parsé, mais j'avais oublié de l'inclure dans le JSON -_-)- Taille du vecteur dans le cas où il a une taille constante (i.e. pas d'écriture de la taille avant d'écrire les valeurs) dans le champs "constant_length".- Nom de la méthode utilisée pour écrire le typeId quand elle est utilisée dans "write_type_id_method" (je crois que c'est constant, mais j'ai accès à l'information et l'espace disque de coûte pas cher, donc j'inclus ça même si ça n'aura probablement pas d'utilité).- Nom de la méthode utilisée pour écrire 0 ou 1 en fonction de si l'attribut est null ou pas dans "write_false_if_null_method" (pour l'instant les 2 seuls attributs comme ça sont dans "com/ankamagames/dofus/network/types/game/context/roleplay/fight/arena/ArenaRankInfos.as").- Les dates sont un peu mieux normalisées dans "version".- Apparition d'une section "default" à la racine du JSON, ce sont les valeurs par défaut utilisées pour les fields. En fonction des arguments passés à la ligne de commande, il y a 2 comportements:- Si "-a", "--all" ou "--no-default" est passé, la section "default" n'est pas présente dans le JSON et **toutes** les entrées (même les vides) de chaque field sont inclues.- Sinon (comportement par défaut donc), la section "default" est présente et chaque field est réduit en n'écrivant que les entrées qui sont différentes de la valeur par défaut encodée dans la section "default".- Si le fichier de sortie n'est pas précisé, le JSON est affiché sur stdout. Par contre, les logs d'info, mais aussi les potentiels warnings résultants d'un problème de parsing quelque part sont **aussi** affichés sur stdout, à améliorer de mon côté, peut-être en affichant les logs (même les logs d'information) sur stderr.- C'est dockerisé.~~ Je n'ai pas encore setup de build automatique avec Gitlab, donc il vous faudra build par vous même pour l'instant,~~ Tout est expliqué [ici](https://gitlab.com/botofu/protocol_parser#using-docker-recommended).- Le tout accompagné d'un petit bump version en 0.2 pour les champs dans "version.parser". Notez que tant que la version majeure est à 0, je considère que des "breaking changes" (comprennez ici un changement du format du JSON de sortie) sont possibles à tout moment. Si breaking change il y a, la version changera dans tous les cas. En attendant que je considère le format suffisamment mature, seulement la verison mineure changera.

Update en 0.3. J'utilises maintenant aussi le fichier VERSION à côté du DofusInvoker.swf, si il n'est pas présent un warning sera affiché.Juste pour résumer, si vous avez docker, l'utilisation est aussi simple que ça:``` docker pull registry.gitlab.com/botofu/protocol_parser docker run -v /path/to/Dofus/directory/:/data/ -it registry.gitlab.com/botofu/protocol_parser -i 2 /data/DofusInvoker.swf /data/protocol.json # protocol.json is now in /path/to/Dofus/directory/protocol.json ```J'ai rajouté le patch (le 37 dans la version 2.55.1.37 par exemple) et le type de build du client (pour l'instant il n'y a que "release" qui est supporté, mais à moins que vous ne travailliez pour Ankama, ça m'étonnerai que vous ayez accès à autre chose, sauf si un stagiaire se plante :p) au JSON généré, d'où le bump de version en 0.3.

salut c'est utilisable avec le c# ?

> @"ZyFox"#p25018 salut c'est utilisable avec le c# ? Ca dépends ce que tu veux faire.Le principe de l'outil est que tu l'utilises comme un exécutable pour générer un JSON, et après tu analyse ce JSON avec ce que tu veux. Donc si tu suis le principe de l'outil, c'est utilisable avec n'importe quel langage qui a la capacité de lire un fichier JSON.Si tu veux appeler les fonctions implémentées dans l'outil directement depuis le C#, ça risque d'être plus compliqué pour plusieurs raisons:- Je n'ai pas défini d'interface C. Je ne sais pas comment le C# fait pour appeler des fonctions C++, mais si il fait comme la plupart des autres langages que je connais il lui faut une interface C (très probable).- Je n'ai pas prévu d'exporter le projet sous forme de bibliothèque partagée. Mon point de vue actuel est qu'exporter le projet comme une bibliothèque partagée serait un investissement en temps très peu rentable, le tool étant déjà utilisable sous forme d'exécutable.Si tu es intéressé par ça, je t'invites à ouvrir une issue sur le dépôt Gitlab. Comme je te l'ai dis, il y a peu de chances que je prenne le temps d'implémenter ça. Par contre si tu te sens de commencer le travail je ne crache pas dessus ;)Après je n'ai qu'une connaissance très partielle (presque inexistante) du fonctionnement du C#, à toi ou aux gens plus compétents de me dire si ce que j'avance est vrai ou complètement délirant.

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Parseur de protocole

KingOfGobballs

Nelimee
C'est effectivement comme ça que c'est fait partout, mais avoir des classes dynamiquement générées permet quand même de pouvoir s'adapter au protocole sans avoir à re-compiler et même potentiellement sans avoir à arrêter le bot.
Tu pourrais par exemple patcher les bots automatiquement à chaque mise à jour du client en
- Téléchargeant le .swf.
- Générant le fichier de protocole en JSON.
- Appelant une méthode pour "recharger" les classes de protocole.
Ça pourrait servir comme une sorte d'updater assez fragile: le protocole sera toujours bien parsé, mais si les changements sont trop importants ou que tu utilises des attributs qui ne sont plus dans le protocole, ou plus sous le même nom, ton bot crashera quand même...
En attendant je rajoute le problème du BBW sur la liste des modifications à effectuer! Merci du retour :)

Si je ne m'abuse, le protocol est mis à jour par Ankama pendant leurs maintenances, pendant lesquels aucun compte n'est connecté en jeu. Donc le protocol risque pas de changer sous tes pieds ^^

Claudine

Hetarnam
Je vois pas pourquoi changer, j'ai mon fichier template pour générer les classes du protocole

Je n'ai pas dis que c'était une mauvaise solution, tu n'as pas besoin de changer, d'ailleurs c'est la solution la plus simple au niveau technique, les autres demandent de faire un arbre binaire (pour gérer l'héritage dynamiquement). Par expérience je préfère garder des données dynamiques si elles le sont déjà plutôt que de les récrire en "dures", pour une question de visibilité et ne devoir modifier qu'un seul endroit du code si besoin.

Hetarnam

Claudine
Tu vas faire un fichier quand c'est du code que tu écris toi mais la c'est quelques choses que tu récupères d'un autre modèle/format de données donc tu vas mélanger du code que tu écris toi et du code générer via ton générateur de template.
Je trouve cette solution étrange car au lieu de lire directement les données au format du protocol.json, tu as créé un tool qui converti les données en fichiers de code alors que tu aurais pu les lire directement. (C'est comme si pour la traduction d'un programme tu utilises un code, qui va générer deux versions du projet/code une en anglais, l'autre en français).
Je n'ai pas dis que c'était une mauvaise solution, tu n'as pas besoin de changer, d'ailleurs c'est la solution la plus simple au niveau technique, les autres demandent de faire un arbre binaire (pour gérer l'héritage dynamiquement). Par expérience je préfère garder des données dynamiques si elles le sont déjà plutôt que de les récrire en "dures", pour une question de visibilité et ne devoir modifier qu'un seul endroit du code si besoin.

Je vois pas vraiment si c'est possible une chose comme ça en C#, surtout dans le cas ou je dois identifier quel message est qui, je dois me fier aux ID du coup, je sais juste pas si l'id d'un message peut changer ou pas, et si c'est le cas ça pourrait être très problématique

BlueDream

Les IDs à priori ne changent pas,

En ce qui concerne ta méthode, de créer d'abord un fichier .json puis de transformer cela en .cs,

C'est exactement le même process que le ProtocolBuilder de Stump,

C'est vrai qu'on pourrait sauter cette étape mais je ne vois pas ce que cela change réellement,

j'imagine que le parsing est plus simple via la méthode du Framework .Net de parsing d'objet json.

Claudine

@Nelimee Il y-a-t-il une raison particulière de ne pas trier l'array fields dans l'ordre ? Actuellement, tu utilises la clé position à la place d'ordonner le tableau, je ne comprends pas pourquoi. :-/

~~NB :~~ protocolID n'est pas camelCase

EDIT : Je comprends pourquoi, avec le message "AbstractGameActionFightTargetedAbilityMessage"


      "fields": [
        {
          "boolean_byte_wrapper_position": 2,
          "default_value": "false",
          "name": "verboseCast",
          "position": 0,
          "type": "Boolean",
          "use_boolean_byte_wrapper": true
        },
        /* ... */
        {
          "boolean_byte_wrapper_position": 1,
          "default_value": "false",
          "name": "silentCast",
          "position": 0,
          "type": "Boolean",
          "use_boolean_byte_wrapper": true
        }
      ],

Nelimee

Petite idée du matin: pourquoi est-ce qu'on discute des idées d'amélioration ici alors que le Gitlab du projet permet d'ouvrir des issues et de tracker leur avancement?

Je vais essayer de mettre à jour petit à petit les issues sur le Gitlab avec ce qui c'est dit ici, si quelqu'un a plus de temps que moi pour le faire ça sera grandement apprécié :)

Dorénavant, ça se passe ici pour les demandes de fonctionnalités, les rapports de bug ou les remarques.

Claudine

Nelimee
Dorénavant, ça se passe ici pour les demandes de fonctionnalités, les rapports de bug ou les remarques.

Lapsus ? Ca ne va pas dans le sens de ta première phrase ou je ne comprends pas :-/

Hetarnam

Claudine
Aucune issue n'était faite sur le gitlab et la discussion a commencé ici, c'est comme tu le souhaites, je peux passer à Gitlab, je me suis fais un compte sur Gitlab spécialement pour ça.
Lapsus ? Ca ne va pas dans le sens de ta première phrase ou je ne comprends pas :-/

(Le "ici" est un lien cliquable qui redirige sur le GitLab)

Claudine

Je rate beaucoup de lien sur ce forum

Nelimee

Juste pour vous tenir au courant, une grosse modification du format du JSON en sortie est en train d'être réalisée sur le Gitlab avec Claudine. Je vous invite à aller voir les différentes issues en cours et les modifications déjà apportées sur la branche dev.

Petit spoil de ce qui arrive:

- Une documentation du JSON de sortie.

- Un meilleur format pour la partie méta-data.

- Un meilleur format pour les attributs qui utilisent le BBW.

jokoast

Désolé si je bump le sujet mais je me remets (après des années à ne pas avoir mis le nez dedans) à m'intéresser au protocole D2. A l'époque on traduisait l'.as pour reproduire le protocole. Aujourd'hui, de ce que je suis surpris de lire, le protocole peut-être généré automatiquement à partir des sources ?!

chuckame

jokoast
Désolé si je bump le sujet mais je me remets (après des années à ne pas avoir mis le nez dedans) à m'intéresser au protocole D2. A l'époque on traduisait l'.as pour reproduire le protocole. Aujourd'hui, de ce que je suis surpris de lire, le protocole peut-être généré automatiquement à partir des sources ?!

Depuis toujours on le génère à partir des sources du dofus invoker, et donc de l'as ^^

jokoast

@Nelimee aurais-tu connaissance d'un projet qui montre un semblant de l'implémentation d'un reader pour ton json qui permet d'instancier des messages facilement et de lire correctement des paquets ? En C#, Python ou C++ ? Je ne vois pas vraiment comment utiliser correctement cette ressource qui me semble magnifique.

EDIT : J'imagine qu'on doit tout de même lire le header, déterminer le messageid puis aller lire dans le json pour ce messageId les types à lire dans l'ordre via les position ?

Lukyrouge3

T'as ca par exemple: https://github.com/Grandnainconnu/Dofus2ProtocolGenerator

jokoast

Merci @Lukyrouge3 .

« Page précédente Page suivante »