Encore une question ouverte, tu souhaites vraiment sacrifier ton temps libre ? :p
Au niveau des timestamps, en fait dans le code du jeu les dates sont au format texte et pas sous forme de timestamp. C'est néanmoins faisable, je ferais ça tranquillement avec le reste et je rajouterai une entrée "timestamp".
Je ne suis pas encore allez aussi loin dans le code de mon sniffer. Si c'est déjà comme ça dans le code du swf, c'est justifiable et tu peux oublier mon idée du timestamp (bien que je trouve que ça soit le format le plus moderne et le plus facile à gérer).
"protocol" qui stocke toutes les infos sur.... le protocole! qui est différent de "parser", où j'ai inséré les informations récupérées sur le protocole (et pas le client) récupérées dans le client.
Je ne suis pas sûr de comprendre, je pensais que c'était la version de ton code^^'. Si protocol est la version du protocol du jeu et non du parser, met la clef protocol dans client, ça sera plus évident.
En attendant si tu as d'autres remarques sur le JSON sorti
- Quand on fait
./botofu/build/botofu_protocol_parser --indent 2 "$VName.swf" "$PWD/data/protocol.json"
si "data" n'existe pas : On n'a pas d'erreur, et le fichier protocol.json n'est pas créé.
- Pourquoi "VERSION" doit être sous forme de fichier et non de chaine de texte si on l'ajoute via une option ?
Soit j'ai raté un lien mais il n'y a aucune explication sur comment abordé le json, un léger speach sur comment l'utiliser.
Mais ça ne me dérange pas de le faire moi sur le forum, ça m'aidera à comprendre comment utiliser le json
--------
J'ai survolé rapidement le JSON :
- J'aurais bien vue une légende pour tous les types natifs/récurrent utilisés, comme ça d'un coup d'oeil le dev sait de quoi il doit s'attendre en utilisant ton JSON, histoire qu'on mette tout le monde d'accord :
{
"int": {
"type": "Number",
"bits": 32
},
"uint": {
"unsigned": true,
"type": "Number",
"bits": 32
},
"String": {
"type": "String"
}
}
Les "bounds" pourraient être optimisés :
- Il y a 119 fois :
"bounds": {
"low": "-9007199254740992.000000",
"up": "9007199254740992.000000"
},
En reprenant mon idée, de légende des types natifs/récurrents on peut simplifier par :
{
"Number": {
"type": "Number"
"bounds": {
"low": "-9007199254740992.000000",
"up": "9007199254740992.000000"
},
}
- Puis 282 fois :
"bounds": {
"low": "0",
"up": "9007199254740992.000000"
},
Peut être, les remplacer un type "Number-unsigned" Bien que ça soit moche d'appeler ça unsigned, vu que le bit du signe est quand même perdu, Number-positive? :
{
"Number-positive": {
"type": "Number"
"bounds": {
"low": 0",
"up": "9007199254740992.000000"
},
}
- J'ai trouvé quelques chose de très drôle et répétez 800 fois (parce qu'ici on parle d'unsigned...) :
"bounds": {
"low": "0"
},
"type": "uint",
- ...
(je continue à la ligne car l'éditeur bug avec les listes à puce et les codes, ça prend trop de temps à mettre en page)
32 fois :
"bounds": {
"low": "0",
"up": "559"
},
On peut appeler ça cell (ou ucell si on veut garder l'idée du toujours positif)
15 fois :
"bounds": {
"low": "-1",
"up": "559"
},
On peut appeler ça cell
67 fois :
"bounds": {
"low": "0",
"up": "65535"
},
On peut appeler ça ushort
36 fois :
"bounds": {
"low": "0",
"up": "255"
},
On peut appeler ça uchar
12 fois :
bounds": {
"low": "1",
"up": "200"
},
On peut appeler ça level ?
40 fois :
bounds": {
"low": "-255",
"up": "255"
},
On peut appeler ça boundaries ?
10 fois :
bounds": {
"low": "0",
"up": "20000"
},
On peut appeler ça honor ?