Résolu Bot chasse : gestion des phorreurs (sniffer?)

Inscrit
1 Octobre 2019
Messages
30
Reactions
6
#1
Hello !

Il y a environ 1 an, j'ai fait un bot chasse dans le but de les faciliter (en nodejs).
Il ne gérait pas les combats ni les phorreurs mais ça me convenait, c'était semi-automatisé.
Il utilise Tesseract pour lire les directions, indices, et positions de départ. Il trouve les indices à l'aide de Dofus Map, la dragodinde fait le reste. Lorsque c'est un phorreur il me demande la position de celui-ci et reprend la chasse.
Aujourd'hui je travaille dessus à nouveau et je suis ici pour faire appel à votre imagination et à vos conseils.

Pour les combats, ça ne devrait pas poser trop de problèmes l'ayant déjà fait sur Retro.
Pour les phorreurs, je suis à court d'idées. Impossible de faire une recherche d'image à cause des décors qui peuvent passer sur le phorreur, et la recherche par pixel me paraît trop peu précise pour ce genre de recherche (il trouverait sur certaines maps des pixels de même couleur).

La seule idée qui me vient à l'esprit c'est de sniffer les paquets, mais je ne sais même pas si lors de l'arrivée sur une map je pourrais voir dans le paquet qu'un phorreur s'y trouve. (Je pense que si? logiquement il me semble que c'est impossible autrement mais je ne suis pas sûr)
Quoi qu'il en soit j'ai commencé à essayer de lire les paquets en python, notamment à l'aide du tutoriel de Labo. (Je ne m'y connais pas en réseau)
Lorsque je lance le sniffer live, j'arrive à récupérer un ou deux paquets au lancement du programme, puis plus rien. J'ai essayé avec scapy et kamene le résultat est le même. J'ai l'impression qu'il freeze ou ne détecte pas les paquets (même sans le filtre TCP 5555). Ce blocage m'empêche d'approfondir dans la lecture des paquets reçus.


Auriez-vous quelques pistes pour le sniffer en python ? (ou autre langage why not)
Ou quelques idées pour détecter les phorreurs ?

Merci !


EDIT: Je viens de tomber sur ce sujet : https://cadernis.com/index.php?threads/bot-chasses-au-trésor-et-maps-bloquantes.2528/
J'essaye d'utiliser le sniffer de Labot mais lorsque je lance sudo python -m labot.sniffer.main j'obtiens : No module named labot.sniffer.main
(Le problème doit sûrement être idiot, je ne m'y connais pas vraiment en python)
 
Dernière édition:
Inscrit
10 Mai 2015
Messages
357
Reactions
55
#2
Hello,

Etant donné que mon bot est full socket la question pour moi ne se pose pas, c'est très facile de savoir si le phorreur se trouve ou non sur la map avec les packets.

Ce packet : TreasureHuntStepFollowDirectionToHinteger permet de savoir si le prochain indice est un phorreur à trouver ou un indice classique.

Dans le cas où c'est un phorreur, tu peux obtenir son identifiant dans le packet en question, et lorsque tu parcours chaque map tu dois vérifier avec ce packet : MapComplementaryInformationsDataMessage si l'identifiant du phorreur se trouve sur la map.

Dans ton cas c'est un peu relou de faire un sniffer juste pour récupérer le phorreur, il me semble tu pourrais activer un raccourcis sur chaque map afin de rendre visible le texte pour chaque actor sur la map. Et avec ça, tu utilises Tesseract pour lire si un phorreur se trouve sur la map ou non. Ce n'est évidemment qu'une suggestion, je ne l'ai pas testé moi même sorry :(

Sinon tu pourrais faire un hook de la fonction qui charge le phorreur de la map ou encore scanner le processus du client et pourquoi pas modifier la mémoire.

Enfin voilà j'ai pas d'autres idées, je ne t'ai pas parlé du fait de modifier le client de jeu pour des raisons de sécurité. Si tu as eu une autre idée que les miennes, hésite pas à la poster sur ce fil, ça m'intéresse de voir les différentes approches.
 
Inscrit
1 Octobre 2019
Messages
30
Reactions
6
#4
Bonjour bonjour, me revoilà un mois plus tard !
J'avais peu de temps et je voulais vraiment avoir bossé dessus avant de vous répondre sur le sujet.
J'ai assez bien avancé alors je viens aux nouvelles.

Hello,

Etant donné que mon bot est full socket la question pour moi ne se pose pas, c'est très facile de savoir si le phorreur se trouve ou non sur la map avec les packets.

Ce packet : TreasureHuntStepFollowDirectionToHinteger permet de savoir si le prochain indice est un phorreur à trouver ou un indice classique.

Dans le cas où c'est un phorreur, tu peux obtenir son identifiant dans le packet en question, et lorsque tu parcours chaque map tu dois vérifier avec ce packet : MapComplementaryInformationsDataMessage si l'identifiant du phorreur se trouve sur la map.

Dans ton cas c'est un peu relou de faire un sniffer juste pour récupérer le phorreur, il me semble tu pourrais activer un raccourcis sur chaque map afin de rendre visible le texte pour chaque actor sur la map. Et avec ça, tu utilises Tesseract pour lire si un phorreur se trouve sur la map ou non. Ce n'est évidemment qu'une suggestion, je ne l'ai pas testé moi même sorry :(

Sinon tu pourrais faire un hook de la fonction qui charge le phorreur de la map ou encore scanner le processus du client et pourquoi pas modifier la mémoire.

Enfin voilà j'ai pas d'autres idées, je ne t'ai pas parlé du fait de modifier le client de jeu pour des raisons de sécurité. Si tu as eu une autre idée que les miennes, hésite pas à la poster sur ce fil, ça m'intéresse de voir les différentes approches.
Merci Brizze pour ta réponse qui m'a mis la puce à l'oreille. Je n'avais pas la possibilité ou plutôt la motivation de détecter les phorreurs visuellement et non les raccourcis "y" et "z" ne fonctionnent pas sur les phorreurs. J'ai donc suite à ton message pleinement décidé de le faire en sniffant, même si j'ai mis du temps à m'y mettre et que j'ai rencontré pas mal de difficultés haha.
Et un grand merci pour les noms de paquets qui vont très certainement me servir dans un avenir proche. (Je ne me rend pas encore compte si ça aurait été simple à trouver)

Merci je connaissais pas. Cependant je crois que c'est fait uniquement pour windows, donc je l'ai mis sur ma machine windows et je n'ai finalement pas réussi à le faire marcher. Dommage parce que l'outil a l'air vraiment intéressant, mais tant mieux parce que si j'avais réussi je n'aurai peut-être pas poussé plus sur mon propre sniffer en nodejs.

-----------------------------------------------------------------------

Donc oui, comme vous avez pu le lire ci-dessus, j'ai commencé un sniffer en nodejs. Je poste aujourd'hui car j'ai enfin réussi à déchiffrer le paquet ChatServerMessage dont l'ID est 5855. Après maintes difficultés j'arrive à obtenir toutes les informations.
Étant donné que je comprend maintenant comment à partir des sources je peux déchiffrer les bytes de données pour récupérer les informations, je me dis que je suis sur la bonne voie pour réussir mon objectif final à savoir : ajouter un sniffer à mon bot clic pour faire des chasses plus efficacement.

Je tiens à remercier particulièrement certaines personnes du forum qui se reconnaîtront, qui font de ce forum une véritable mine d'or.
Il y a les habitués/expérimentés, mais aussi ceux qui postent pour essayer d'apprendre, à qui les habitués répondent et donnent de la matière à éviter de devoir poster toutes les 5 minutes pour apprendre quelque chose. Bravo.

Je vous tiendrais au courant de l'avancement de mon projet, parce qu'en effet pour l'instant je n'arrive à sniffer que le chat, et ça ne m'est pas du tout utile.

See you soon !
 
Inscrit
12 Aout 2021
Messages
35
Reactions
6
#5
Bonjour bonjour, me revoilà un mois plus tard !
J'avais peu de temps et je voulais vraiment avoir bossé dessus avant de vous répondre sur le sujet.
J'ai assez bien avancé alors je viens aux nouvelles.



Merci Brizze pour ta réponse qui m'a mis la puce à l'oreille. Je n'avais pas la possibilité ou plutôt la motivation de détecter les phorreurs visuellement et non les raccourcis "y" et "z" ne fonctionnent pas sur les phorreurs. J'ai donc suite à ton message pleinement décidé de le faire en sniffant, même si j'ai mis du temps à m'y mettre et que j'ai rencontré pas mal de difficultés haha.
Et un grand merci pour les noms de paquets qui vont très certainement me servir dans un avenir proche. (Je ne me rend pas encore compte si ça aurait été simple à trouver)



Merci je connaissais pas. Cependant je crois que c'est fait uniquement pour windows, donc je l'ai mis sur ma machine windows et je n'ai finalement pas réussi à le faire marcher. Dommage parce que l'outil a l'air vraiment intéressant, mais tant mieux parce que si j'avais réussi je n'aurai peut-être pas poussé plus sur mon propre sniffer en nodejs.

-----------------------------------------------------------------------

Donc oui, comme vous avez pu le lire ci-dessus, j'ai commencé un sniffer en nodejs. Je poste aujourd'hui car j'ai enfin réussi à déchiffrer le paquet ChatServerMessage dont l'ID est 5855. Après maintes difficultés j'arrive à obtenir toutes les informations.
Étant donné que je comprend maintenant comment à partir des sources je peux déchiffrer les bytes de données pour récupérer les informations, je me dis que je suis sur la bonne voie pour réussir mon objectif final à savoir : ajouter un sniffer à mon bot clic pour faire des chasses plus efficacement.

Je tiens à remercier particulièrement certaines personnes du forum qui se reconnaîtront, qui font de ce forum une véritable mine d'or.
Il y a les habitués/expérimentés, mais aussi ceux qui postent pour essayer d'apprendre, à qui les habitués répondent et donnent de la matière à éviter de devoir poster toutes les 5 minutes pour apprendre quelque chose. Bravo.

Je vous tiendrais au courant de l'avancement de mon projet, parce qu'en effet pour l'instant je n'arrive à sniffer que le chat, et ça ne m'est pas du tout utile.

See you soon !
Yop, déjà GG c'est un petit pas pour l'homme mais un grand pas pour toi, étant moi même entrain de développer mon bot chasse, je viens te faire part de quelques informations sur le sniffage des phorreurs.
Déjà le Message qui t'ai envoyé est "MapComplementaryInformationsDataMessage" dans le package "messages.context.roleplay" il est envoyé au moment ou tu load une nouvelle map, le truc c'est qu'il y'a tout un tas de "Types" à développer avant de pouvoir accèder aux phorreur, comme les NPCS de la map, les maisons, les groupes de monstres, les joueurs, les modes marchant etc etc, le truc c'est que toutes ces informations ne sont pas forcément envoyé sur un seul paquet, puis-ce qu'il y'a quand même beaucoup d'informations, donc la plupart du temps, pas toujours mais très très souvent tu vas te retrouver avec 2 paquets pour le même message (Ici "MapComplementaryInformationsDataMessage") donc j'espère pour toi que tu as prévu le cas où lors de ta lecture tu peux attendre la suite du message où non, j'ai compris qu'il était envoyé en 2 parties y'a quelques minutes seulement donc j'pourrais malheureusement pas t'éclairer sur la façons de faire, puis ce que je suis moi même dans la mouise de ce côté là, si jamais tu as une idée de comment faire pour attendre la suite d'un message n'hésite pas à poster, je te serais reconnaissant, en attendant j'vais aller chercher de mon côté, bon courage en tout cas :)
 
Inscrit
1 Octobre 2019
Messages
30
Reactions
6
#6
Yop, déjà GG c'est un petit pas pour l'homme mais un grand pas pour toi, étant moi même entrain de développer mon bot chasse, je viens te faire part de quelques informations sur le sniffage des phorreurs.
Déjà le Message qui t'ai envoyé est "MapComplementaryInformationsDataMessage" dans le package "messages.context.roleplay" il est envoyé au moment ou tu load une nouvelle map, le truc c'est qu'il y'a tout un tas de "Types" à développer avant de pouvoir accèder aux phorreur, comme les NPCS de la map, les maisons, les groupes de monstres, les joueurs, les modes marchant etc etc, le truc c'est que toutes ces informations ne sont pas forcément envoyé sur un seul paquet, puis-ce qu'il y'a quand même beaucoup d'informations, donc la plupart du temps, pas toujours mais très très souvent tu vas te retrouver avec 2 paquets pour le même message (Ici "MapComplementaryInformationsDataMessage") donc j'espère pour toi que tu as prévu le cas où lors de ta lecture tu peux attendre la suite du message où non, j'ai compris qu'il était envoyé en 2 parties y'a quelques minutes seulement donc j'pourrais malheureusement pas t'éclairer sur la façons de faire, puis ce que je suis moi même dans la mouise de ce côté là, si jamais tu as une idée de comment faire pour attendre la suite d'un message n'hésite pas à poster, je te serais reconnaissant, en attendant j'vais aller chercher de mon côté, bon courage en tout cas :)
Salut, merci pour ta réponse. J'ai commencé à sniffer le paquet MapComplementaryInformationsDataMessage, j'ai en effet remarqué qu'il y a beaucoup d'informations. Je n'ai pas encore été confronté à la réception de 2 paquets pour le même message, mais je bloque pour l'instant à partir de la réception des VarShort, je ne connaissais pas ces types de variables et de ce que j'ai compris c'est des variables à taille variable avec pour chaque bit un bit de poids fort qui définit s'il y a un prochain octet pour cette variable. Je n'arrive pas encore à lire parfaitement ce type de variables, ce qui me donne des données erronées à partir de "Scales len". Je n'ai pas beaucoup de temps pour l'instant mais pour avancer j'aurai besoin de comprendre si par exemple une VarShort sur 3 bytes contenant 1001 1100 1010 1011 0100 0000 vaut en décimal 464320, c'est à dire qu'on enlève les bits de poids fort et on prend la suite 0011100 0101011 1000000.
Je me trompe ? Si c'est bien ça ce n'est plus qu'une histoire de code et j'arriverais à me débloquer là dessus.

J'ai un deuxième problème de compréhension pour avancer. Dans le code de EntityLook il y a dans la boucle des "subentities" un nouvel appel à EntityLook. Je me dis tout simplement que pour chaque sous-entités (familiers, dragodindes...) on chope ses informations et que ça ne devrait pas poser de problème puisqu'à l'appel sur la sous-entité subentitiesLen sera à 0. Je crois avoir saisit mais j'aimerai juste être sûr que c'est la bonne voie.

J'ai failli oublier : 3ème petit problème de compréhension qui ne devrait pas me gêner mais je suis curieux, pour la lecture de la mapid, j'ai étonnamment découvert qu'il faut effectuer une conversion de binaire à double, ce qui m'est totalement étranger. Quand je met mon binaire dans un convertisseur binaire -> double (comme par exemple celui-ci), j'obtiens le bon mapid, mais pour convertir le binaire en double dans mon code, c'est pas gagné, je n'y comprend rien malgré la schématisation qu'il y a sur le site. Si quelqu'un a une piste je suis preneur.

Pour ton souci de message en 2 paquets, je dirais qu'il faut regarder si le message est tronqué. C'est possible de le voir dans le header du paquet puisque le module que j'utilise en nodejs me dit si oui ou non il l'est. Ensuite, si tu détectes que le message est tronqué, tu lis le prochain paquet du même protocole comme la suite du premier paquet.
Je te donnerais des news à ce sujet quand je m'y pencherais.

Bon courage !
 
Dernière édition:
Inscrit
12 Aout 2021
Messages
35
Reactions
6
#7
Salut, merci pour ta réponse. J'ai commencé à sniffer le paquet MapComplementaryInformationsDataMessage, j'ai en effet remarqué qu'il y a beaucoup d'informations. Je n'ai pas encore été confronté à la réception de 2 paquets pour le même message, mais je bloque pour l'instant à partir de la réception des VarShort, je ne connaissais pas ces types de variables et de ce que j'ai compris c'est des variables à taille variable avec pour chaque bit un bit de poids fort qui définit s'il y a un prochain octet pour cette variable. Je n'arrive pas encore à lire parfaitement ce type de variables, ce qui me donne des données erronées à partir de "Scales len". Je n'ai pas beaucoup de temps pour l'instant mais pour avancer j'aurai besoin de comprendre si par exemple une VarShort sur 3 bytes contenant 1001 1100 1010 1011 0100 0000 vaut en décimal 464320, c'est à dire qu'on enlève les bits de poids fort et on prend la suite 0011100 0101011 1000000.
Je me trompe ? Si c'est bien ça ce n'est plus qu'une histoire de code et j'arriverais à me débloquer là dessus.

J'ai un deuxième problème de compréhension pour avancer. Dans le code de EntityLook il y a dans la boucle des "subentities" un nouvel appel à EntityLook. Je me dis tout simplement que pour chaque sous-entités (familiers, dragodindes...) on chope ses informations et que ça ne devrait pas poser de problème puisqu'à l'appel sur la sous-entité subentitiesLen sera à 0. Je crois avoir saisit mais j'aimerai juste être sûr que c'est la bonne voie.

J'ai failli oublier : 3ème petit problème de compréhension qui ne devrait pas me gêner mais je suis curieux, pour la lecture de la mapid, j'ai étonnamment découvert qu'il faut effectuer une conversion de binaire à double, ce qui m'est totalement étranger. Quand je met mon binaire dans un convertisseur binaire -> double (comme par exemple celui-ci), j'obtiens le bon mapid, mais pour convertir le binaire en double dans mon code, c'est pas gagné, je n'y comprend rien malgré la schématisation qu'il y a sur le site. Si quelqu'un a une piste je suis preneur.

Pour ton souci de message en 2 paquets, je dirais qu'il faut regarder si le message est tronqué. C'est possible de le voir dans le header du paquet puisque le module que j'utilise en nodejs me dit si oui ou non il l'est. Ensuite, si tu détectes que le message est tronqué, tu lis le prochain paquet du même protocole comme la suite du premier paquet.
Je te donnerais des news à ce sujet quand je m'y pencherais.

Bon courage !
Ok, je regarderais du côté du header de mon paquet,

Alors pour ton premier problème j'avoue que je ne peux pas trop t'éclairer ^^ J'ai juste choppé un Reader donc j'me contente de copier bêtement les paquets avec les types de mon Reader correspondant.

Ensuite pour le subEntities, si tu développes le message exactement comme dans les sources en gros pour te résumer ça donne ça :
- Un entity look est trouvé, on le deserialize
- Si il y'a un SubEntityLook on le créer, puis on le deserialize
- Le SubEntityLook utilise l'EntityLook pour se deserializer
Donc en gros faut le voir réelement comme ça (Avec des mots simples, même si c'est pas les termes exactes mais admettons) :

- EntityLook crane :
- SubEntityLook oeil :
- Oeil.Deserialize();
- EntityLook d'oeil : Pupille
- Etc etc

En gros il interreun SubEntityLook qui peut lui même contenir un SubEntityLook qui peut lui même contenir un SubEntityLook

Donc si tu codes bien ton Message tu devrais pas avoir à te faire de bille, c'est assez simple, c'est au final comme une liste de liste quoi ^^

Et pour le troisième problème, j'ai pas bien compris ce que tu demandais ^^'

Si tu n'arrives pas à comprendre comment convertir les Datas brutes de ton Message j'peux aider

En gros ton Reader si tu cherches à lire un double (8 bytes) il va falloir lui faire récuperer les 8 prochains bytes par rapport à sa position actuel dans le Stream des datas du paquet)

Par exemple :
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000100
est égale à un double dont la valeur est 4
(Tu peux voir qu'un double est codé sur 8 bytes)
Et donc pour Dofus (En big endian) :
00100000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ça donne ça

Tout ce que tu dois retenir c'est que si tu veux lire un double, tu dois récuperer les 8 prochains bytes dans ton flux de donnée (Toujours à partir de la position de ton "curseur" dans le stream)
 
Dernière édition:
Inscrit
1 Octobre 2019
Messages
30
Reactions
6
#8
Ok, je regarderais du côté du header de mon paquet,

Alors pour ton premier problème j'avoue que je ne peux pas trop t'éclairer ^^ J'ai juste choppé un Reader donc j'me contente de copier bêtement les paquets avec les types de mon Reader correspondant.

Ensuite pour le subEntities, si tu développes le message exactement comme dans les sources en gros pour te résumer ça donne ça :
- Un entity look est trouvé, on le deserialize
- Si il y'a un SubEntityLook on le créer, puis on le deserialize
- Le SubEntityLook utilise l'EntityLook pour se deserializer
Donc en gros faut le voir réelement comme ça (Avec des mots simples, même si c'est pas les termes exactes mais admettons) :

- EntityLook crane :
- SubEntityLook oeil :
- Oeil.Deserialize();
- EntityLook d'oeil : Pupille
- Etc etc

En gros il interreun SubEntityLook qui peut lui même contenir un SubEntityLook qui peut lui même contenir un SubEntityLook

Donc si tu codes bien ton Message tu devrais pas avoir à te faire de bille, c'est assez simple, c'est au final comme une liste de liste quoi ^^

Et pour le troisième problème, j'ai pas bien compris ce que tu demandais ^^'

Si tu n'arrives pas à comprendre comment convertir les Datas brutes de ton Message j'peux aider

En gros ton Reader si tu cherches à lire un double (8 bytes) il va falloir lui faire récuperer les 8 prochains bytes par rapport à sa position actuel dans le Stream des datas du paquet)

Par exemple :
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000100
est égale à un double dont la valeur est 4
(Tu peux voir qu'un double est codé sur 8 bytes)
Et donc pour Dofus (En big endian) :
00100000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ça donne ça

Tout ce que tu dois retenir c'est que si tu veux lire un double, tu dois récuperer les 8 prochains bytes dans ton flux de donnée (Toujours à partir de la position de ton "curseur" dans le stream)
Ok, du coup c'est bien ce qui me semblait pour l'EntityLook, parfait.
J'ai pas de souci pour lire un double. Le problème c'est pour convertir mon binaire en Double (IEEE754 Double precision 64-bit) pour obtenir la même mapid que la commande /mapid. Parce que quand je lis les 8 bytes de la mapid, j'ai 4724707086590542000 en décimal. Pas de souci j'attendrais la réponse de quelqu'un d'autre pour m'éclairer, pareil pour l'histoire des varShort.
Merci pour ton aide :)
 
Inscrit
12 Aout 2021
Messages
35
Reactions
6
#9
Ok, du coup c'est bien ce qui me semblait pour l'EntityLook, parfait.
J'ai pas de souci pour lire un double. Le problème c'est pour convertir mon binaire en Double (IEEE754 Double precision 64-bit) pour obtenir la même mapid que la commande /mapid. Parce que quand je lis les 8 bytes de la mapid, j'ai 4724707086590542000 en décimal. Pas de souci j'attendrais la réponse de quelqu'un d'autre pour m'éclairer, pareil pour l'histoire des varShort.
Merci pour ton aide :)
Avec plaisir, en effet, ça à l'air d'être une autre paire de manche en NodeJS, bon courage, hésite pas à partager un peu quand tu auras trouver la solution, ça pourra surement en aider d'autre

J'pose ça là au cas où ça pourrait t'aider et que ça t'aurai echapé : https://stackoverflow.com/questions/59039806/node-buffer-readfloatbe-extends-data-to-64-bit
 
Inscrit
1 Octobre 2019
Messages
30
Reactions
6
#10
En node je ne sais pas comment ça se passe, en C# il y aurait par exemple BitConverter.Int64BitsToDouble(byte[]) comme alternative. Tout en sachant qu'à partir de net core, cette méthode n'est plus nécessaire.
Ah voilà c'est ça qu'il me fallait, pour nodeJS

Avec plaisir, en effet, ça à l'air d'être une autre paire de manche en NodeJS, bon courage, hésite pas à partager un peu quand tu auras trouver la solution, ça pourra surement en aider d'autre

J'pose ça là au cas où ça pourrait t'aider et que ça t'aurai echapé : https://stackoverflow.com/questions/59039806/node-buffer-readfloatbe-extends-data-to-64-bit
Je n'avais pas vu ton message avant mes recherches mais c'est ça qu'il me fallait en effet

----------------------------------------------------------

En nodejs, il fallait donc faire un
JavaScript:
new Buffer.from(mapID.toString(16), "hex").readDoubleBE(0);
 
Inscrit
12 Aout 2021
Messages
35
Reactions
6
#11
Ah voilà c'est ça qu'il me fallait, pour nodeJS


Je n'avais pas vu ton message avant mes recherches mais c'est ça qu'il me fallait en effet

----------------------------------------------------------

En nodejs, il fallait donc faire un
JavaScript:
new Buffer.from(mapID.toString(16), "hex").readDoubleBE(0);
Ravi de voir que tu progresses :)
 
Inscrit
1 Octobre 2019
Messages
30
Reactions
6
#12
Je confirme pour ceux qui passeraient par là, les "variables variables" comme VarShort VarInt... se lisent comme dans mon exemple : on enlève le bit de poids fort pour chaque byte et on lit le tout
Exemple : 1001 1100 1010 1011 0100 0000 = 464320
 
Inscrit
12 Aout 2021
Messages
35
Reactions
6
#13
C'est quand même dingue cette façon de faire je trouve
 
Haut Bas