2.0 Bytes inconnus

Inscrit
5 Juillet 2020
Messages
3
Reactions
0
#1
Bonjour à tous,

Je n'arrive pas à comprendre certains messages.
Je me retrouve avec des bits que je ne comprends pas.

Par exemple, avec le contenu suivant :

8b:d5:1e:00:00:00:25:00:01:bd:dd:4a:c5:83:01:00:00:00:25:00:01:1a:40:8b:01:01:00:03:f3:03:b7:17:00:11:5c

Mon analyse :
- Packet ID : 8949 (ExchangeTypesItemsExchangerDescriptionForUserMessage)
- Length Type : 1
- Length : 30
- ObjectType : 37
- Item Description length = 1
- Item Description #1
- Object uuid = 1224381
- Object gid = 16837
- Object type = 37
- Nb effets : 1
- Effet #1 :
- Type id : 6720
- action id : 139

- ???
- Prix
- 499
- 2999
- 0

- ???

Pour le 01, sa taille semble varier en fonction du contenu du vecteur contenant tous les effets.
Si je n'ai pas de vecteur, je n'ai pas de soucis, il n'y a rien.

Pour le 11:5c, j'ai l'impression de le retrouver souvent avec cette valeur.
Donc pas en fonction du contenu du vecteur.
(à la limite, il me dérange moins, car il est en fin de message, il ne décale pas mes lectures)

J'aimerais surtout les comprends pour ne pas casser ma lecture des données.

Est-ce que vous auriez une piste sur leur origine, svp ?

Merci d'avance,
 
Inscrit
13 Octobre 2020
Messages
5
Reactions
11
#2
Salut ! Pour se désérializer le packet semble faire appel aux fonctions ReadVarInt et ReadVarShort, Tu as bien vérifié ton implémentation de ces deux fonctions qui peuvent facilement décaler tout ton flux ?
 
Inscrit
5 Juillet 2020
Messages
3
Reactions
0
#3
Je n'ai pas l'impression de m'être trompé sur mes readVarInt(), readVarShort() et readVarLong().
Quand je compare avec les prix en HDV, j'ai tout bon.
J'ai testé (aléatoirement) plusieurs identifiants lus comme ça, tout me semblait bon.

Si j'ai bien compris le mécanisme, on regroupe les bytes tant qu'ils commencent pas un "1".
Donc en hexa, on prend les blocs supérieurs à 0x80. (1000 0000)
Dans l'exemple initial, la liste des effets, j'ai : 00:01:1a:40:8b:01:01
- 00:01 : Taille du vecteur, Short qui vaut 1.
- 1a:40 : TypeId, Short qui vaut 6720.
- 8b:01 : VarShort. Le premier bit du premier octet vaut "1", alors on doit prendre le suivant.
Fini. Mais j'ai mon "01" qui traine, je ne comprends pas pourquoi.

J'ai même switché avec les implémentations de LaBot. J'obtiens les même résultats.


On est d'accord que quand il y a des classes imbriquées dans d'autres classes, on n'a pas de checksum ou truc du genre en fin d'imbrication ? J'ai l'impression que c'est quelque chose du genre, mais je ne vois aucun code qui va dans ce sens.
 
Inscrit
5 Juillet 2020
Messages
3
Reactions
0
#4
Ok, j'ai compris mon erreur ! \o/

Pour chaque élément sérialisé, s'ils précisent le TypeId, c'est parce qu'ils utilisent des sous-classes de ObjectEffect.
Or, je restais sur la classe ObjectEffect qui n'a qu'un champ.
C'est comme ça que je me retrouve le "01", c'est un champ de la sous-classe.

Je ne comprends toujours pas mon "11:5c" en fin de message, mais il ne me dérange pas pour en comprendre le contenu.
(probablement un vrai checksum, lui)

Problème résolu, merci. :)
 
Inscrit
10 Novembre 2020
Messages
3
Reactions
0
#5
Ok, j'ai compris mon erreur ! \o/

Pour chaque élément sérialisé, s'ils précisent le TypeId, c'est parce qu'ils utilisent des sous-classes de ObjectEffect.
Or, je restais sur la classe ObjectEffect qui n'a qu'un champ.
C'est comme ça que je me retrouve le "01", c'est un champ de la sous-classe.

Je ne comprends toujours pas mon "11:5c" en fin de message, mais il ne me dérange pas pour en comprendre le contenu.
(probablement un vrai checksum, lui)

Problème résolu, merci. :)
Salut, pour le 11:5c il s'agit de BasicNoOperationMessage (1111)
une sorte d'accusé de réception je crois

{
"fields": [],
"name": "BasicNoOperationMessage",
"namespace": "com.ankamagames.dofus.network.messages.game.basic",
"protocolID": 1111,
"super": "NetworkMessage",
"super_serialize": false,
"supernamespace": "com.ankamagames.jerakine.network",
"use_hash_function": false
},
 
Haut Bas