Je vais vous parler de la partie communication entre le serveur et le client.

Il s'agit d'une analyse de l'existant, de ce que j'ai compris, des compromis faits, mais aussi des améliorations possibles et de mes suggestions.

Quelle est la communication entre le serveur et les clients ? Comment sont définis la position, les zones, comment fait-on pour changer de zone, la communication (chat), quel sont les états ?

Pourquoi écrire ce document ? Premièrement pour se repérer dans le code, comprendre comment cela marche, et surtout mettre à plat tout ce petit monde afin de recadrer et voir vers où l'on va.

Quand on parle de communication, on parle en fait de deux étapes.

• Étape 1 : connexion & authentification
• Étape 2 : communication continue (ici commence réellement le jeu)

Pourquoi deux étapes?

La première étape concerne la vérification de l’utilisateur et de son mot de passe, s'ils sont correct, vous pouvez vous enfin communiquer (en permanence) avec le serveur. Ce dernier envoie une clef/token afin de pouvoir s'authentifier dans l'étape 2. Ensuite la connexion est maintenue entre le serveur et le client de jeu.

  +---------+
  |         |
  |         +-------+                      +------------------+
  |         | 443   |  <---HTTPS/TCP-----> | Login / Register |
  |         +-------+                      +------------------+
  | Serveur |
  |         +-------+                +----------------------------+
  |         | xxxxx |  <---UDP-----> | Communication avec le jeu  |
  |         +-------+                +----------------------------+
  |         |
  +---------+

Cette étape est exécutée une seule fois et permet de créer un compte.

Dans les faits, on utilise le protocole https [TCP/IP]¹⁾

On lance une requette WEB avec la forme suivante

Le lien dans l'interface web sera de la forme suivante :

[url]/ams/index.php?page=register&Username=[username]&Password=[password]&ConfirmPass=[password]&Email=[email]&TaC=[tac]&function=add_user</nowiki>

Avec:

• username : il doit être unique
• password : le mot de passe
• email : un email
• tac : toujours on (pour dire que la licence est acceptée)

Exemple:

 https://khaganat.net/ams/index.php?page=register&Username=joueurdetest&Password=jenetedonnepasmonmotdepasse&Email=joueurdetest@khaganat.net&TaC=on&function=add_user

Le serveur retourne une ligne:

• [Status]:[commentaire]

si status est égale à 1, la création est effectuée. Sinon, une erreur est survenue, il faut regarder le commentaire.

Cette étape permet de s'assurer que l'utilisateur est bien la bonne personne, via le couple utilisateur/mot de passe.

On utilise le protocole https [TCP/IP]²⁾

On envoie les informations suivantes :

1. Client → Serveur

Demande un mot clef pour permettre le salage du mot de passe.³⁾

URL formatée de la façon suivante :

[url]/login/r2_login.php?cmd=ask&cp=2&login=[login]&lg=[LanguageCode]

2. Serveur → Client

Le serveur retourne une ligne:

• [Status]:[commentaire ou sel]

Si status est égal à 1, le deuxième paramètre est le sel, une suite de chiffres utilisés avec le mot de passe pour générer une chaîne de hachage.

Si le status n'est pas égale à 1, le deuxième paramètre est un commentaire sur l'erreur.

3. Client → Serveur

Renvoie le compte & une clef permettant de vérifier que l'on connaît le mot de passe.

Cette clef est en réalité un calcul réalisé avec le sel et le mot de passe [sha512_crypt]. Cela évite d'avoir à transmettre le mot de passe, donc plus sécurisé.

Sachant que le serveur connaît aussi le sel, il exécute aussi le même calcul afin de vérifier que vous connaissez le mot de passe.

L'URL pour se connecter :

[url]/login/r2_login.php?cmd=login&login=[login]&password=[password]&clientApplication=[ClientApplication]&cp=[cp]&lg=[lg]

4. Serveur → Client

Le serveur retourne deux lignes:

• state#cookie#fsaddr#ringmainurl#fartp
• r2serverversion]#r2backuppatchurl#r2patchurl

Définition de certain paramètre:

• fsaddr = khaganat_host:khaganat_port
• cookie = user_addr|user_key|user_id

Ici, le serveur renvoie trois clefs à utiliser pour se connecter, ainsi que l'adresse du serveur à contacter.

• khaganat_host, khaganat_port : adresse à utiliser pour se connecter au serveur (en UDP)
• user_addr : une chaîne de caractère qui traduit le code hexa (32 bits)
• user_key : une chaîne de caractère qui traduit le code hexa (32 bits)
• user_id : une chaîne de caractère qui traduit le code hexa (32 bits)

Ces clefs seront utiles dans la première phase de communication avec le serveur.

Première chose, on remarque que le protocole est UDP.

Il n'y a donc pas de synchronisation avec le serveur, on envoie les messages, ils arrivent dans n'importe quel ordre et c'est à l'application de faire le tri.

L’intérêt est que la communication est plus rapide, et que sur le principe d'un jeu “temps réel”, les actions passées ne sont pas importantes, seul compte l'état actuel.

Pour faire une analogie, il faut voir le réseau comme une multitude d'autoroute et de péage qui s’entremêlent. Suivant votre chauffeur, vous irez plus ou moins vite, avec des raccourcis plus au moins chanceux (et parfois des accidents).

Au départ, on souhaite envoyer une message du point A vers le point B (serveur → client ou client → serveur).

Les messages sortent les uns après les autres.

Arrivé au premier croisement (switch), certains partent à droite, d'autres à gauche.

Arrivé au péage (firewall), le message est bloqué pour analyse, par contre d'autres poursuivent leur chemin.

On continue sur le même principe.

Mais des fois, nous perdons un paquet suite à un accident (collision avec un autre message).

Et enfin tous les messages restants arrivent à destination (pas forcément dans l'ordre envoyé).

Ce mode de fonctionnement implique une gestion de la couche réseau côté applicatif, au niveau du serveur et du client.

La communication s'effectue suivant différents état.

• NotInitialised : État initiale
• NotConnected : État non utilisé, réception du cookie
• Authenticate : État non utilisé, authentification
• Login : État login
• Synchronize : État synchronisation
• Connected : État connecté, ici, on est dans la phase communication du jeu,
• Probe : État approbation, on demande de vérifier que le client est bien connecté
• Stalled : État bloqué
• Disconnect : État déconnecté
• Quit : État quitter
• ForceSynchronize : État forçant la synchronisation (non existant côté serveur)

Dans le code, l'idéal serait de gérer l'état dans des classes différentes, afin de ne gérer que l'état en cours et de ne pas polluer le code de if/switch/case.

Maintenant, regardons d'un peu plus près chaque message envoyé par le serveur.

  +-------------------+------------+---
  | CurrentSendNumber | SystemMode | . . .
  |    32 bits        |  1 bit     |
  +-------------------+------------+---
                         1 -> system mode
                         0 -> normal mode

• CurrentSendNumber : un compteur qui s'incrémente tout le temps (permet d'ignorer les messages passés). Attention: quand le compteur aura atteint le maximum, le client va refuser tous les messages.
• SystemMode : Informe que le type de message est dit “système” ou “normal”.

  +-------------------+------------+---------+---
  | CurrentSendNumber | SystemMode | Message | . . .
  |    32 bits        |  1 bit     | 8 Bits  |
  +-------------------+------------+---------+---
  |  xxxxxxxxxxxxxxxx |   1        |

Suivant la valeur du message, nous avons des paramètres spécifiques.

Notez qu'ici nous utilisons 8 bits. On aurait pu réduire la taille afin d'être en adéquation avec les messages envoyés.

À savoir qu'il y a 5 types de messages provenant du client & 5 types de messages provenant du serveur, soit une taille de 3 bits.

Message émis par le serveur.

Message utilisé pour synchroniser le client et vérifier que nous avons la même base de définition XML (msg.xml & database.xml)

  +-------------------+------------+---------+-------------+---------+------------+-------------------+------------------------+
  | CurrentSendNumber | SystemMode | Message | Synchronize | stime   | LatestSync | MsgData           | DatabaseData           |
  |    32 bits        |  1 bit     | 8 Bits  | 32 bits     | 64 bits | 32 bits    | 16 * 8 bits       | 16 * 8 bits            |
  |                   |            |         | unsigned    | signed  | unsigned   | md5sum of msg.xml | md5sum of database.xml |
  +-------------------+------------+---------+-------------+---------+------------+-------------------+------------------------+
  |  xxxxxxxxxxxxxxxx |   1        |    1    |         xxx |     xxx |        xxx |               xxx |                    xxx |

Message émis par le serveur.

Message pour vérifier que le client reçoit bien les messages (le client va renvoyer un SYSTEM_ACK_PROBE_CODE, avec tous les PROBE envoyés).

  +-------------------+------------+---------+-------------+
  | CurrentSendNumber | SystemMode | Message | LatestProbe |
  |    32 bits        |  1 bit     | 8 Bits  | 32 bits     |
  |                   |            |         | unsigned    |
  +-------------------+------------+---------+-------------+
  |  xxxxxxxxxxxxxxxx |   1        |    3    |         xxx |

Message émis par le serveur.

  +-------------------+------------+---------+
  | CurrentSendNumber | SystemMode | Message |
  |    32 bits        |  1 bit     | 8 Bits  |
  |                   |            |         |
  +-------------------+------------+---------+
  |  xxxxxxxxxxxxxxxx |   1        |    6    |

Message émis par le serveur.

  +-------------------+------------+---------+
  | CurrentSendNumber | SystemMode | Message |
  |    32 bits        |  1 bit     | 8 Bits  |
  |                   |            |         |
  +-------------------+------------+---------+
  |  xxxxxxxxxxxxxxxx |   1        |    7    |

Message émis par le serveur.

  +-------------------+------------+---------+
  | CurrentSendNumber | SystemMode | Message |
  |    32 bits        |  1 bit     | 8 Bits  |
  |                   |            |         |
  +-------------------+------------+---------+
  |  xxxxxxxxxxxxxxxx |   1        |    7    |

  +-------------------+------------+-------------------+---------+-----------------+
  | CurrentSendNumber | SystemMode | last received ack | Factory | Visual Property |
  |    32 bits        |  1 bit     | 32 Bits           | X bits  | Z bits          |
  |                   |            | unsigned          |         |                 |
  +-------------------+------------+-------------------+---------+-----------------+
  |  xxxxxxxxxxxxxxxx |   0        |

Ici nous avons tout un système de boîtes afin de savoir dans quel rayon on lit le message. Utilisation à voir, peut-être une méthode pour différencier les différents services du serveur.

On stocke les paquets suivant le paramètre CurrentSendNumber. Mais pour chaque paquet, on doit d'abord lire un bit pour identifier si on a des données ou pas.

Les différents niveaux suivant la valeur de CurrentSendNumber :

  +----------+  +----------+  +----------+
  | Packet A |  | Packet B |  | Packet C |
  |   (0)    |  |   (0)    |  |   (0)    |
  +----------+  +----------+  +----------+
                +----------+  +----------+
                | Packet B |  | Packet C |
                |   (1)    |  |   (1)    |
                +----------+  +----------+
                              +----------+
                              | Packet C |
                              |   (2)    |
                              +----------+
                              +----------+
                              | Packet C |
                              |   (3)    |
                              +----------+

Si modulo CurrentSendNumber 4 == 0 :

  +---------+      +----------+----------+----------+
  | Factory |      | Packet A | Packet B | Packet C |
  |         | ===> | pos:0    | pos:0    | pos:0    |
  | X bits  |      | X bits   | X bits   | X bits   |
  +---------+      +----------+----------+----------+

Si modulo CurrentSendNumber 4 == 1 :

  +---------+      +----------+----------+----------+
  | Factory |      | Packet A | Packet B | Packet C |
  |         | ===> | pos:0    | pos:1    | pos:1    |
  | X bits  |      | X bits   | X bits   | X bits   |
  +---------+      +----------+----------+----------+

Si modulo CurrentSendNumber 4 == 2 :

  +---------+      +----------+----------+----------+
  | Factory |      | Packet A | Packet B | Packet C |
  |         | ===> | pos:0    | pos:0    | pos:2    |
  | X bits  |      | X bits   | X bits   | X bits   |
  +---------+      +----------+----------+----------+

Si modulo CurrentSendNumber 4 == 3 :

  +---------+      +----------+----------+----------+
  | Factory |      | Packet A | Packet B | Packet C |
  |         | ===> | pos:0    | pos:1    | pos:3    |
  | X bits  |      | X bits   | X bits   | X bits   |
  +---------+      +----------+----------+----------+

Pour le packet A : tant que next est égale à 1, on lit le paquet (Level A) :

  +----------+     +-------+-----------+-------+-----------+-------+
  | Packet A |     | next  | Factory A | next  | Factory A | next  | . . .
  | X bits   | --> | 1 bit |    (0)    | 1 bit |    (0)    | 1 bit |
  |          |     |       |           |       |           |       |
  +----------+     +-------+-----------+-------+-----------+-------+

Pour le packet B :

• Tant que next est égal à 1, on lit le paquet (Level B)
• La position x dépend de CurrentSendNumber

  +----------+     +-------+-----------+-------+-----------+-------+
  | Packet B |     | next  | Factory B | next  | Factory B | next  | . . .
  | X bits   | --> | 1 bit |    (x)    | 1 bit |    (x)    | 1 bit |
  |          |     |       |           |       |           |       |
  +----------+     +-------+-----------+-------+-----------+-------+

Pour le packet C:

• Tant que next est égal à 1, on lit le paquet (Level C)
• La position y dépend de CurrentSendNumber

  +----------+     +-------+-----------+-------+-----------+-------+
  | Packet C |     | next  | Factory C | next  | Factory C | next  | . . .
  | X bits   | --> | 1 bit |    (y)    | 1 bit |    (y)    | 1 bit |
  |          |     |       |           |       |           |       |
  +----------+     +-------+-----------+-------+-----------+-------+

Exemple avec CurrentSendNumber égal à 7 (donc CurrentSendNumber % 4 = 3)

  +---------+      +-------+-----------+-------+-----------+-------+-------+-----------+-------+-------+-----------+-------+-----------+-------+ 
  |         |      |       | Action    |       | Action    |       |       | Action    |       |       | Action    |       | Action    |       |
  | Factory |      | next  | Factory A | next  | Factory A | next  | next  | Factory B | next  | next  | Factory C | next  | Factory C | next  |
  |         | ===> |       |    (0)    |       |    (0)    |       |       |   (1)     |       |       |   (3)     |       |   (3)     |       |
  | X bits  |      | 1 bit | X bits    | 1 bit | X bits    | 1 bit | 1 bit | X bits    | 1 bit | 1 bit | X bits    | 1 bit | X bits    | 1 bit |
  +---------+      +-------+-----------+-------+-----------+-------+-------+-----------+-------+-------+-----------+-------+-----------+-------+
                   | 1     |       xxx | 1     |      xxxx |     0 |    1  |       xxx |     0 |     1 |       xxx |     1 |       xxx |     0 |
                   | ----              Packet A               ---- | -----     Packet B   ---- | -----             Packet C               ---- |

N'ayant pas la signification exacte, je considère que tout a le même niveau (bref on lit au fil de l'eau).

On lit les trois paquets (A, B & C, que j'ai converti/nommé Z), car je ne vois pas très bien l'interet d'avoir trois niveaux, sachant qu'après on remet tout au même niveau, peut-etre un optimisation pour les reprises suite à la perte de paquet)

  +---------+      +----------+----------+----------+
  | Factory |      | Packet Z | Packet Z | Packet Z |
  | X bits  |      | X bits   | X bits   | X bits   |
  +---------+      +----------+----------+----------+

Puis pour chaque paquet Z on lit le champ next et si ert à '1' on lit ActionFactory X, puis on lit next suivant:

  +----------+     +-------+-----------------+-------+-----------------+-------+
  | Packet Z |     | next  | ActionFactory X | next  | ActionFactory X | next  | . . .
  | X bits   | --> | 1 bit | X bits          | 1 bit | X bits          | 1 bit |
  +----------+     +-------+-----------------+-------+-----------------+-------+

Dans chaque ActionFactory, nous avons la structure suivante:

  +-----------------+     +-------+--------+
  | ActionFactory X | --> | Code  | Action |
  |                 |     | X bit | X Bit  |
  +-----------------+     +-------+--------+

On y découvre un code (qui identifie l'action à décoder) et l'action⁴⁾.

Ici, nous avons une petite structure pour définir ActionCode. En gros, on décode ce chiffre en 3 bits ou 9 bits. Sachant que le plus souvent, on aura à décoder seulement 3 bits.

  +------+    +-----------+---------------------------+
  | Code | -> | ShortCode |        ActionCode         |
  |      |    |   1 bit   |  2 bits, si ShortCode = 1 |
  |      |    |           |  8 bits, si ShortCode = 0 |
  +------+    +-----------+---------------------------+

Voir la section Action pour ActionCode.

  +-------------------+------------+---
  | CurrentSendNumber | SystemMode | . . .
  |    32 bits        |  1 bit     |
  +-------------------+------------+---
                         1 -> system mode
                         0 -> normal mode

• CurrentSendNumber : un compteur qui s'incrémente tout le temps (permet d'ignorer les messages passés). Attention: quand le compteur aura atteint le maximum, le client va refuser tous les messages.
• SystemMode : Informe que le type de message est dit “système” ou “normal”.

  +-------------------+------------+---------+---
  | CurrentSendNumber | SystemMode | Message | . . .
  |    32 bits        |  1 bit     | 8 Bits  |
  +-------------------+------------+---------+---
  |  xxxxxxxxxxxxxxxx |   1        |

Suivant la valeur du message, nous avons des paramètres spécifiques.

Notez qu'ici nous utilisons 8 bits, on aurait pu réduire la taille afin d'être en adéquation avec les messages envoyés.

À savoir qu'il y a 5 types de messages provenant du client & 5 types de messages provenant du serveur, soit une taille de 3 bits.

Message émis par le client.

  +-------------------+------------+---------+-----------+----------+----------+-------- / ---------+
  | CurrentSendNumber | SystemMode | Message | User Addr | User Key | User ID  | Langue             |
  |    32 bits        |  1 bit     | 8 Bits  | 32 bits   | 32 bits  | 32 bits  | String    (x bits) |
  |                   |            |         | unsigned  | unsigned | unsigned |                    |
  +-------------------+------------+---------+-----------+----------+----------+-------- / ---------+
  |  xxxxxxxxxxxxxxxx |   1        |    0    |       xxx |      xxx |      xxx |                xxx |

Message émis par le client. Message utilisé pour acquitter d'une demande de synchronisation.

  +-------------------+------------+---------+-----------+----------+-----------------+----------+
  | CurrentSendNumber | SystemMode | Message | frontack  | backack  | longackbitfield | syncCode |
  |    32 bits        |  1 bit     | 8 Bits  | 32 bits   | 32 bits  | 1024 bits       | 32 bits  |
  |                   |            |         | unsigned  | unsigned | unsigned        | unsigned |
  +-------------------+------------+---------+-----------+----------+-----------------+----------+
  |  xxxxxxxxxxxxxxxx |   1        |    2    |       xxx |      xxx |             xxx |      xxx |

• frontack : dernier message reçu (last_received_number)
• backack : last_ack_in_long_ack
• longackbitfield : suite de bit qui indique les messages normaux reçus (permettra de faire une synchronisation avec le serveur)
• syncCode : _server_sync

Message émis par le client.

Acquitte des messages PROBE envoyés.

  +-------------------+------------+---------+-------------+---------+---------+-- / --+---------+
  | CurrentSendNumber | SystemMode | Message | Taille : X  | Probe 1 | Probe 2 |       | Probe X |
  |    32 bits        |  1 bit     | 8 Bits  | 32 bits     | 32 bits | 32 bits |       | 32 bits |
  |                   |            |         | signed      | signed  | signed  |       | signed  |
  +-------------------+------------+---------+-------------+---------+---------+-- / --+---------+
  |  xxxxxxxxxxxxxxxx |   1        |    4    |

Message émis par le client.

  +-------------------+------------+---------+
  | CurrentSendNumber | SystemMode | Message |
  |    32 bits        |  1 bit     | 8 Bits  |
  |                   |            |         |
  +-------------------+------------+---------+
  |  xxxxxxxxxxxxxxxx |   1        |    5    |

Message émis par le client.

  +-------------------+------------+---------+---------+
  | CurrentSendNumber | SystemMode | Message | Quit Id |
  |    32 bits        |  1 bit     | 8 Bits  | 32 bits |
  |                   |            |         | signed  |
  +-------------------+------------+---------+---------+
  |  xxxxxxxxxxxxxxxx |   1        |    8    |

  +-------------------+------------+----
  | CurrentSendNumber | SystemMode | . . .
  |    32 bits        |  1 bit     | 
  +-------------------+------------+----
  |  xxxxxxxxxxxxxxxx |   0        |

À remplir.

Nous avons différents type Action:

• ACTION_POSITION_CODE = 0 : Disponible en mode ShortCode = 1 ou 0
• ACTION_GENERIC_CODE = 1 : Disponible en mode ShortCode = 1 ou 0
• ACTION_GENERIC_MULTI_PART_CODE = 2 : Disponible en mode ShortCode = 1 ou 0
• ACTION_SINT64 = 3 : Disponible en mode ShortCode = 1 ou 0
• ACTION_SYNC_CODE = 10 : Disponible en mode ShortCode = 0
• ACTION_DISCONNECTION_CODE = 11 : Disponible en mode ShortCode = 0
• ACTION_ASSOCIATION_CODE = 12 : Disponible en mode ShortCode = 0
• ACTION_LOGIN_CODE = 13 : Disponible en mode ShortCode = 0
• ACTION_TARGET_SLOT_CODE = 40 : Disponible en mode ShortCode = 0
• ACTION_DUMMY_CODE = 99 : Disponible en mode ShortCode = 0

  +----------+----------+----------+
  | px       | py       | pz       |
  | 16 bits  | 16 bits  | 16 bits  |
  | unsigned | unsigned | unsigned |
  +----------+----------+----------+

  +-------------------------------+
  | pz                            |
  | 14 bit                        |
  | | | | | | | | | | | | | | | | | | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   + Interior
                                     + IsRelative

On récupère une chaîne contenant le code impulse.

  +----------+------+------+-- / --+--------+        +---------+
  | size     | char | char |       | char   |        |         |
  | 32 bits  |   a    a+1            a+size |    ==> | Impulse |
  | unsigned |                              |        |         |
  +----------+------+------+-- / --+--------+        +---------+

• size : nombre de caractères dans ce bloc
• char : les données

Impulse est la concaténation de toutes les chaines : char [a, a+1, … , a+size].

On ne récupère qu'une partie du code impulse. Il faudra attendre de recevoir toutes les parties pour pouvoir décoder ce code impulse.

  +----------+----------+----------+----------+------+------+-- / --+--------+
  | Number   | Part     | NbBlock  | size     | char | char |       | char   |
  | 8 bits   | 16 bits  | 16 bits  | 32 bits  |   a    a+1            a+size |
  | unsigned | unsigned | unsigned | unsigned |                              |
  +----------+----------+----------+----------+------+------+-- / --+--------+

• Number : Numéro de paquet (doit être unique du moins pendant une courte période)
• Part : position du bloc
• NbBlock : Nombre de bloc (total)
• size : nombre de caractère dans ce bloc
• char : les données

Pour décoder, il faut recevoir pour le même Number toutes les Part (blocs), les remettre dans l'ordre et lancer le décodage impulse.

Exemple :

• Number : 1
• NbBlock : 3

  +---------+---------+---------+      +---------+
  | Part 1  | Part 2  | Part 3  | ===> | Impulse |
  | | | | | | | | | | | | | | | |      |         |
  +---------+---------+---------+      +---------+

Voilà un format/type qu'il faut retenir. Il est utilisé dans la partie visual decode, mais pas comme son nom l'indique. En fait il s'agit d'une structure à taille variable suivant sa destination. Bref, on sent la réutilisation d'un code pour faire autre chose, dommage car vu la capacité, pourquoi ne pas avoir ajouter d'autres format/type ?

Structure utilisée pour la synchronisation.

  +----------+------------+
  | Sync     | BKEntityId |
  | 32 Bits  | 64 bits    |
  | unsigned | unsigned   |
  +----------+------------+

Code pour lancer une déconnexion. Il n'y a pas de paramètre.

Certainement pour associer une nouvelle zone.

  +----------+---------+
  | SheetId  | Replace |
  | 32 Bits  | 1 bit   |
  | unsigned |         |
  +----------+---------+

Un code qui aurait du être utilisé pour l’authentification. Mais on ne l'utilise jamais ! On utilise la commande système SYSTEM_LOGIN_CODE. Bref les mystères de l'évolution du code.

  +-----------+----------+----------+
  | user addr | user key | user id  |
  | 32 Bits   | 32 bits  | 32 bits  |
  | unsigned  | unsigned | unsigned |
  +-----------+----------+----------+

Un nouveau slot ?

  +----------+------------------+
  | Slot     | Target Or Pickup |
  | 8 Bits   | 2 bits           |
  | unsigned | unsigned         |
  +----------+------------------+

Un code de test.

  +-----------+----------+
  | Dummy 1   | Dummy 2  |
  | 32 Bits   | 32 bits  |
  | unsigned  | unsigned |
  +-----------+----------+

Ici, nous allons utilisé la structure msg.xml pour pouvoir décoder le message. Le décodage demande d'abord de comprendre comment lire le fichier msg.xml.

Le fichier xml a une structure du style :

    <client_messages_description>
      <branch name=x1 param_a=y1 param_b=z1 position=0>
         <leaf name=x2 param_aa=y2 param_bb=z2 position=0/>
      </branch>
      <branch name=x3 param_a=y3 param_b=z3 position=1>
         <leaf name=x4 param_aa=y4 param_bb=z4 position=0/>
         <leaf name=x5 param_aa=y5 param_bb=z5 position=1/>
      </branch>
      <branch name=x6 param_a=y6 param_b=z6 position=2>
         <branch name=x7 param_a=y7 param_b=z7 position=0>
           <leaf name=x8 param_aa=y8 param_bb=z8 position=0/>
           <leaf name=x9 param_aa=y9 param_bb=z9 position=1/>
           <leaf name=x10 param_aa=y10 param_bb=z10 position=2/>
         </branch>
         <leaf name=x11 param_aa=y11 param_bb=z11 position=1/>
         <leaf name=x12 param_aa=y12 param_bb=z12 position=2/>
         <leaf name=x13 param_aa=y13 param_bb=z13 position=3/>
         <leaf name=x14 param_aa=y14 param_bb=z14 position=4/>
      </branch>
    </client_messages_description>

Pour msg.xml, la première clef est client_messages_description.

Ensuite nous avons deux types de clefs : branch (branche) ou leaf (feuille).

• La clef branch permet d'indiquer qu'elle contient d'autres clefs à l’intérieur. Ces clefs à l'intérieur de branch peuvent être du type branch ou leaf).
• La clef leaf indique qu'elle ne contient qu'elle : pas de sous-branche ou de sous-feuille.

Pour décoder nous avons le code impulse. Nous avons besoin dans chaque branche de compter le nombre de sous-branches et sous-feuilles.

Par exemple, ici

1. la branche racine s'appelle client_messages_description, nous comptons 3 sous-branches (appelées x1, x3 & x6). Chaque branche/feuille a une position : on commence par zéro, et on incrémente à chaque fois. Ici j'ai ajouté le paramètre position juste pour suivre, il n'existe pas en réalité dans le code msg.xml.
2. La branche x1 (en position 0), nous comptons une seule sous-branche/feuille (appelé x2) ;
3. La branche x3 (en position 1), nous comptons 2 sous-branches/feuilles (appelé x4 & x5) ;
4. La branch x6 (en position 2), nous comptons 5 sous-branches/feuilles (appelé x7, x11, x12, x13 & x14) ;
5. La branche x7 (en position 0), nous comptons 3 sous-branches/feuilles (appelé x8, x9 & x10).

Ce résultat nous permettra d'avoir le nombre de possibilités et aussi connaitre le nombre de bit accordé pour la branche en question. On répète le calcul jusqu’à arriver à une feuille qui termine et donne la fonction complète.

Exemple (ici je ne mets que les bits) :

• code: 010
  • on compte le nombre de branche/sous-branche sur la racine (ici on a en 3, donc le code tient sur 2 bits)
  • on décode les deux premier bit (ici 01, correspond à la position 1, qui équivaut à x3)
  • puis dans la branche x3, on compte le nombre de branche/sous branche, il y en a 1.
  • on décode un bit (ici 0) qui correspond à la position 0, qui équivaut à x4
  • en résumé : 010 ⇒ 01.0 ⇒ 01 → x3, 0 → x4
  • cela donne x3:x4

• code: 1000001
  • on compte le nombre de branche/sous-branche sur la racine (ici on a en 3, donc le code tient sur 2 bits)
  • on décode les deux premier bit (ici 10, correspond à la position 2, qui équivaut à x6)
  • puis dans la branche x6, on compte le nombre de branche/sous branche, il y en à 5 (donc le code tient sur 3 bits).
  • on décode un bit (ici 000) qui correspond à la position 0, qui équivaut à x7
  • puis dans la branche x7, on compte le nombre de branche/sous branche, il y en à 3 (donc le code tient sur 2 bits).
  • en résumé : 1000001 ⇒ 10.000.01 ⇒ 10 → x6, 000 → x7, 01 → x9
  • cela donne x6:x7:x9

Maintenant, vous savez comment décoder l'entête des messages impulse. Attention, le reste du codage dans msg.xml ne sert pas pour le client (mais certainement pour la communication entre les différents services du serveur).

En complément des messages provenant de msg.xml, nous avons une autre référence database.xml qui a un mode de fonctionnement un peu différent. Certainne commande Impulse (msg.xml), auront un message encodé via database.xml

Structure du fichier:

    <database_description>
      <bank_superclass>
        <!-- dans cette zone existe des informations non utilisés par le client -->
      </bank_superclass>
      <branch name=x1 bank="PLR" clientonly="1">
         <leaf name=x2 type=t1/>
      </branch>
      <branch name=x3 bank="PLR" count="c3">
         <leaf name=x4 type=t4/>
         <leaf name=x5 type=t5/>
      </branch>
      <branch name=x6 bank="PLR" atom="1">
         <branch name=x7 atom="1" count="c7">
           <leaf name=x8 type=t8/>
           <leaf name=x9 type=t9/>
           <leaf name=x10 type=t10/>
         </branch>
         <leaf name=x11 type=t11/>
         <leaf name=x12 type=t12/>
         <leaf name=x13 type=t13/>
         <leaf name=x14 type=t14/>
      </branch>
    </database_description>

Nous trouvons le mot de clef branch, que l'on va traduire par branche, et le mot de clef leaf que l'on traduit par feuille.

Ici le premier niveau qui nous interrese est database_description, puis ensuite on ne garde que les branches ayant le parametre bank égale “PLR”. Pour la partie branche, cet élément peut contenir d'autres branches (zero, une, …, X) et/ou des feuilles (de 0, 1 ou X). Dans sa structure interne, ces deux entités (branches & feuilles) sont séparées, et on regardera d'abord dans les branches puis ensuite dans les feuilles.

Si une branch contient le mot de clef “count”, cela implique une duplication de cette branche X fois (avec pour nom le numéro de position commençant par 0)

Ensuite, nous avons la possibilité d'avoir le mot clef 'atom', s'il est à 1, cela implique une gestion différente de l'agragation des données. (dans ce cas, on considère que l'on aura une structure pouvant envoyer toutes les données [dans en premier temps on envoie un booléen pour chaque feuille disponible dans la branche/sous-branche, puis pour chaque booléen ayant la valeur 1/Vrai, on lira la donnée de la feuille correspondante)

L'association de count & atom m'a particulièrement posé des problèmes, dans les fait 'count' est prioritaire, ensuite on gère le cas de 'atom'.

Un petit exemple:

    <database_description>
       <branch name="Entities"
               bank="PLR"
               clientonly="1">
          <branch name="E"
                  count="2">
             <leaf name="P"
                   count="3"
                   type="I8" />
          </branch>
       </branch>
 
       <branch name="USER"
              bank="PLR"
              atom="1">
        <leaf name="HAIR_TYPE"
              type="I8" />
          <branch name="SKILL_POINTS_"
                  count="4">
              <leaf name="VALUE"
                    type="I32" />
          </branch>
          <branch name="FACTION_POINTS_"
                  count="7">
              <leaf name="VALUE"
                    type="I32" />
          </branch>
       </branch>
 
       <branch name="GROUP"
              bank="PLR">
        <branch name=""
                count="5"
                atom="1">
          <leaf name="PRESENT"
                type="I1" />
          <leaf name="UID"
                type="I20" />
        </branch>
      </branch>
    </database_description>

 * Entities
      * E0
         * P0 (type : I8)
         * P1 (type : I8)
         * P2 (type : I8)
      * E1
         * P0 (type : I8)
         * P1 (type : I8)
         * P2 (type : I8)
 * USER (Atom)
   * SKILL_POINTS_0
     * VALUE (type : I32)
   * SKILL_POINTS_1
     * VALUE (type : I32)
   * SKILL_POINTS_2
     * VALUE (type : I32)
   * SKILL_POINTS_3
     * VALUE (type : I32)
   * FACTION_POINTS_0
     * VALUE (type : I32)
   * FACTION_POINTS_1
     * VALUE (type : I32)
   * FACTION_POINTS_2
     * VALUE (type : I32)
   * FACTION_POINTS_3
     * VALUE (type : I32)
   * FACTION_POINTS_4
     * VALUE (type : I32)
   * FACTION_POINTS_5
     * VALUE (type : I32)
   * FACTION_POINTS_6
     * VALUE (type : I32)
 * GROUP
   * 0 (Atom)
     * PRESENT (Type : I1 == Booléen)
     * UID (Type I20)
   * 1 (Atom)
     * PRESENT (Type : I1 == Booléen)
     * UID (Type I20)
   * 2 (Atom)
     * PRESENT (Type : I1 == Booléen)
     * UID (Type I20)
   * 3 (Atom)
     * PRESENT (Type : I1 == Booléen)
     * UID (Type I20)
   * 4 (Atom)
     * PRESENT (Type : I1 == Booléen)
     * UID (Type I20)

Par exemple le message suivant : 00.0.10.11111111

• 00 : <Entities> le 1er nieveau est sur 2 bit (on a trois elements 0,1 & 2) ⇒ 2 bit pour sélectionner celui que l'on veut.
• 0 : <E0> le 2ème niveau, nous avons ici le choix entre E0 & E1, (1 bit suffit pour trouver l'élément)
• 10 : <P1> le 3ème niveau, nous avons ici le choix entre P0, P1 & P2 (2 bits suffisent pour trouver l'élément)
• 11111111 : <I8> le 4ème niveau, la valeur de la branche
• Résumé :
  • Entities:E0:P1 = 255

2ème exemple : 01.0010100.11111111111111111111111111111111.01111111111111111111111111111111

• 01 : <USER> le 1er nieveau est sur 2 bit (on a trois elements 0,1 & 2) ⇒ 2 bit pour sélectionner celui que l'on veut.
• 0010100 : <SKILL_POINTS_2,SKILL_POINTS_4> USER est du type atom, donc on compte le nombre de tous les feuilles ici 7, et pour chaque bit à 1, on doit récupèrer la valeur
• 11111111111111111111111111111111 : <VALUE> 4294967295
• 01111111111111111111111111111111 : <VALUE> 2147483647
• Résumé:
  • USER.SKILL_POINTS_2 = 4294967295
  • USER.SKILL_POINTS_4 = 2147483647

3ème exemple : 10.010.0.1

• 10 : <GROUP> le 1er nieveau est sur 2 bit (on a trois elements 0,1 & 2) ⇒ 2 bit pour sélectionner celui que l'on veut.
• 010 : <2> La branche suivante à count à 5, donc on doit lire 3 bits pour savoir qu'elle est l'element
• 0 : <PRESENT>
• 1 : VALUE = 1

Les types :

• Ixxx : Entier non signé ou xxx et le nombre de bit à récupèrer
• Sxxx : Entier signé, ou xxx et le nombre de bit à récupèrer
• TEXT : Entier non-signé de 32 bit (dont le bit de poids fort est forcé à zero (jamais négatif - si signé)

Les messages impulses sont construits suivant le format suivant : * premier champ contenant le code impulse * champs suivants : les paramètres du code impulse

Cela donne le schéma suivant :

  +--------------+---- / -----+
  | code msg.xml | paramètres |
  | x bits       | x bits     |
  | unsigned     |            [
  +--------------+---- / -----+

Le serveur répond à un CONNECTION:SELECT_CHAR, et renvoie les informations sur le personnage.

Code actuel : CONNECTION:USER_CHAR ⇒ 000001.00000.

  +----------------+--------------+------------------+------------------+------------------+------------------+--------+----------+--------------------------+--------------------+------------------+
  | CONNECTION     | USER_CHAR    | X                | Y                | Z                | Heading          | season | userRole | highestMainlandSessionId | firstConnectedTime | playedTime       |
  | 6 bits         | 5 bits       | 32 bits          | 32 bits          | 32 bits          | 32 bits          | 3 bits | 3 bits   | 32 bits                  | 32 bits            | 32 bits          |
  | 000001         | 00000        | 32 bits unsigned | 32 bits unsigned | 32 bits unsigned | float            |        |          | 32 bits unsigned         | 32 bits unsigned   | 32 bits unsigned |
  +----------------+--------------+------------------+------------------+------------------+------------------+--------+----------+--------------------------+--------------------+------------------+

• X (Sint32) : position X
• Y (Sint32) : position Y
• Z (Sint32) : position Z
• Heading (Float) : Angle (plan X/Y) du personnage (vers ou regarde le perso)
• season (3 bits) : type de saison
• userRole (3 bits)
• highestMainlandSessionId (Uint32)
• firstConnectedTime (Uint32)
• playedTime (Uint32)

Liste tous les paramètres de l'utilisateur, les personnages, les domaines, …

Code actuel : CONNECTION:USER_CHARS ⇒ 000001.00010.

  +------------+------------+--------------------+
  | CONNECTION | USER_CHARS | ServerPeopleActive |
  | 6 bits     | 5 bits     | uint8              | . . .
  | 000001     | 00010      | unsigned           |
  +------------+------------+--------------------+

• ServerPeopleActive (uint8)
• ServerPeopleActive (uint8)
• CharacterSummaries_Len (Uint32) - les paramètres suivants dépendent de la taille définie ici
  • Version (Uint8)
  • Mainland (Uint32)
  • Name (String-UTF-16)
  • People (Sint32)
  • Location (Uint32)
  • VisualPropA (Uint64) : en réalité on utilise moins de bit (mais ici on prend les 64 bits)
  • VisualPropB (Uint64) : en réalité on utilise moins de bit (mais ici on prend les 64 bits)
  • VisualPropC (Uint64) : en réalité on utilise moins de bit (mais ici on prend les 64 bits)
  • SheetId (Uint32)
  • Title (Sint32)
  • CharacterSlot (Uint8)
  • InRingSession (Bool)
  • HasEditSession (Bool)
  • InNewbieland (Bool)
• shard_names_Len (Uint32)
  • session_id (String)
  • display_name (String)
  • short_name (String)
• privileges (String)
• free_trial (Bool)
• mainlands_len (Uint32)
  • id (Uint32)
  • name (String-UTF-16)
  • description (String-UTF-16)
  • language_code (String)
  • online (Bool)

Création d'un nouveau personnage.

Code actuel : CONNECTION:CREATE_CHAR ⇒ 000001.00011.

  +------------+-------------+--------------------+
  | CONNECTION | CREATE_CHAR | Slot               |
  | 6 bits     | 5 bits      | uint8              | . . .
  | 000001     | 00011       | unsigned           |
  +------------+-------------+--------------------+

• Slot (Uint8)
• SheetId (Uint32)
• CSessionId (Uint32)
• name (String-UTF-16) - Attention il n'accepte qu'un nombre restreint de caractère [A-Za-z0-9]
• People (Uint8)
• Sex (Uint8)
• NbPointFighter (Uint8)
• NbPointCaster (Uint8)
• NbPointCrafter (Uint8)
• NbPointHarvester (Uint8)
• StartPoint (Sint32)
• HairType (Sint8)
• HairColor (Sint8)
• GabaritHeight (Sint8)
• GabaritArmsWidth (Sint8)
• GabaritLegsWidth (Sint8)
• GabaritBreastSize (Sint8)
• MorphTarget1 (Sint8)
• MorphTarget2 (Sint8)
• MorphTarget3 (Sint8)
• MorphTarget4 (Sint8)
• MorphTarget5 (Sint8)
• MorphTarget6 (Sint8)
• MorphTarget7 (Sint8)
• MorphTarget8 (Sint8)
• EyesColor (Sint8)
• Tattoo (Sint8)
• JacketColor (Sint8)
• TrousersColor (Sint8)
• HatColor (Sint8)
• HandsColor (Sint8)
• FeetColor (Sint8)

On remarquera ici que le type des différentes caractéristiques est différent dans CONNECTION:USER_CHAR. Ces propriétés sont définies dans VisualPropA, VisualPropB & VisualPropC, et n'ont bien sûr pas la même taille.

Le client sélectionne un personnage.

Code actuel : CONNECTION:SELECT_CHAR ⇒ 000001.00100.

  +----------------+--------------+-----------------+
  | CONNECTION     | SELECT_CHAR  | SelectCharMsg   |
  | 6 bits         | 5 bits       | 8 bits          |
  | 000001         | 00100        | 8 bits unsigned |
  +----------------+--------------+-----------------+

• SelectCharMsg (Uint8) : id du personnage (entre 0 et 4, actuellement on ne peut avoir que 5 personnages maximum)

En retour de cette commande, le serveur va répondre CONNECTION:USER_CHAR.

Le serveur informe au client qu'il est prêt, puis le client informe ensuite au serveur qu'il est prêt.

Code actuel : CONNECTION:READY ⇒ 000001.01000.

  +------------+------------+--------------+
  | CONNECTION | READY      | LanguageCode |
  | 6 bits     | 5 bits     | String       |
  | 000001     | 01000      |              |
  +------------+------------+--------------+

• LanguageCode (String)

Le client donne le nom et son ID (zone ?) et demande une vérification côté serveur.

Code actuel : CONNECTION:ASK_NAME ⇒ 000001.01010.

  +----------------+--------------+------------------+------------------+
  | CONNECTION     | ASK_NAME     | Name             | HomeSessionId    |
  | 6 bits         | 5 bits       | X bits           | Uint32           |
  | 000001         | 01010        | String-UTF-16    | 32 bits unsigned |
  +----------------+--------------+------------------+------------------+

• Name (String-UTF-16)
• HomeSessionId (Uint32)

Retour attendu : CONNECTION:VALID_NAME.

Le serveur répond à une requête CONNECTION:ASK_NAME.

Code actuel : CONNECTION:VALID_NAME ⇒ 000001.01011

  +----------------+--------------+-----------------+
  | CONNECTION     | VALID_NAME   | valide          |
  | 6 bits         | 5 bits       | 8 bits          |
  | 000001         | 01011        | 8 bits unsigned |
  +----------------+--------------+-----------------+

• valide (Uint8) : 1 ⇒ valide, sinon non valide

Le client informe de certains filtres.

Code actuel : BOTCHAT:SET_FILTERS ⇒ 011001.001100.

  +------------+-------------------+------------------+
  | BOTCHAT    | SET_FILTERS       | qualityMin       |
  | 6 bits     | 5 bits            | 32 bits          | . . .
  | 011001     | 001100            | 32 bits unsigned |
  +------------+-------------------+------------------+

• qualityMin (Uint32)
• qualityMax (Uint32)
• priceMin (Uint32)
• priceMax (Uint32)
• classMin (Uint8)
• classMax (Uint8)
• itemPart (Uint8)
• itemType (Uint8)

Le serveur envoie un message, plus précisément le pointeur sur le message.

Code actuel : STRING_MANAGER:PHRASE_SEND ⇒ 011011.001

  +----------------+--------------+------------------+------------------+
  | STRING_MANAGER | PHRASE_SEND  | dyn_id           | string_id        | string_id . . .
  | 6 bits         | 3 bits       | uint32           | uint32           | tant que l'on a au moins 32 bits, on lit un autre string_id
  | 011011         | 001          | 32 bits unsigned | 32 bits unsigned |
  +----------------+--------------+------------------+------------------+

• dyn_id (Uint32) : l'ID du groupe de message
• string_id (Uint32) : le pointeur sur le message

Le client demande le message complet en fonction du pointeur.

Code actuel : STRING_MANAGER:STRING_RQ ⇒ 011011.010.

  +----------------+--------------+------------------+
  | STRING_MANAGER | STRING_RQ    | string_id        |
  | 6 bits         | 3 bits       | uint32           |
  | 011011         | 010          | 32 bits unsigned |
  +----------------+--------------+------------------+

• string_id (Uint32) : le pointeur sur le message

Le serveur va répondre à ce message par STRING_MANAGER:STRING_RESP.

Le serveur renvoie le message complet.

Code actuel : STRING_MANAGER:STRING_RESP ⇒ 011011.011.

  +----------------+--------------+------------------+--------------+
  | STRING_MANAGER | STRING_RESP  | string_id        | MessageUtf8  |
  | 6 bits         | 3 bits       | uint32           | String-UTF-8 |
  | 011011         | 011          | 32 bits unsigned | X bits       |
  +----------------+--------------+------------------+--------------+

• string_id (Uint32) : le pointeur sur le message.
• MessageUtf8 (String-UTF-8) : la chaîne de caractère en UTF-8.

On remarque ici l'utilisation de la chaîne de caractère au format UTF-8 (alors qu’ailleurs nous avons UTF-16).

Commande utilisée pour initialiser le tableau de message.

Ici, on vérifie que notre tableau interne au client a la même date que le tableau du serveur. Sinon, on efface le tableau interne du client, et à chaque nouveau message le client demandera à quoi il correspond.

Code actuel : STRING_MANAGER:RELOAD_CACHE ⇒ 011011.100

  +----------------+--------------+------------------+
  | STRING_MANAGER | RELOAD_CACHE | timestamp        |
  | 6 bits         | 3 bits       | uint32           |
  | 011011         | 100          | 32 bits unsigned |
  +----------------+--------------+------------------+

• timestamp (uint32) : date du tableau de message

Le serveur signale que la guilde⁵⁾ utilise le féminin dans les titres.

Code actuel : GUILD:USE_FEMALE_TITLES ⇒ 011100.10010

  +------------+-------------------+--------------------+
  | GUILD      | USE_FEMALE_TITLES | UseFemaleTitles    |
  | 6 bits     | 5 bits            | bool               |
  | 011100     | 10010             | 1 bit              |
  +------------+-------------------+--------------------+

• UseFemaleTitles (bool) : 1 = Oui, 0 = Non

Et oui, nous avons encore une autre structure pour envoyer des informations du serveur vers le client.

Ici le codage/cryptage est différent, on utilise un arbre (avec des feuilles) pour savoir quelles sont les données à décrypter.

Pourquoi cette structure?

• Peut-etre pour réduire la taille des info, mais on perd la modularité de msg.xml

• l'autre hypothèse est que ces informations sont spécifiques pour les effets visuels (et qu'ils sont suceptibles d'etre tronqué, mais aussi de ne pas bloquer le jeux pour ces effets, car on ne gère pas le renvoie de ces données, enfin je crois)

Visiblement, le serveur gère les mêmes données est il envoie les mises à jour pour certain d'entre eux.

Le début de la structure:

  +----------+-----------------+------------------+----------------+------------------+
  | Slot     | associationBits | timestampIsThere | timestampDelta | VisualProperties |
  | 8 Bits   | 2 bit           | 1 bit            | 4 bit          | X bits           |
  | unsigned |                 |                  | (optionnel)    |                  |
  +----------+-----------------+------------------+----------------+------------------+
  

• slot : position/slot des données
• associationBits : un indicateur (sorte de clef de hachage) pour savoir si on parle de la même donnée, sinon l'ancienne donnée sera effacé.
• timestampIsThere : active le delta sur le timestamp (0: non, 1:oui)
• timestampDelta : permet d'ajouter un delta au timestamp (optionnel dépend de timestampIsThere)
• VisualProperties : ici nous avons une nouvelle structure qui fonctionne par branche (et feuille pour les terminaison)

Il s'agit d'une liste sans fin de VisualProperty

+----------------+----------------+
| VisualProperty | VisualProperty | . . .
+----------------+----------------+

Il s'agit d'un arbre qui se sépare à chaque fois en deux branch VPA et VPB.

Pour chacune des branches (on commence par VPA, puis VPB), on lit un bit (0: pas de donnée, 1: des données), si un branch contient une autre branche, on refait de comme précédement (lecture VPA puis VPB). puis on continue jusqu'à atteindre la feille, là suivant le type de propriété on va lire un certain nombre debit.

Dans les faits, ils utilisent ACTION_SINT64 pour toutes les valeurs, mais avec une taille différents pour chaque éléments (et cerise sur le gâteau, PROPERTY_ORIENTATION n'est pas un entier mais un flotant)

  +----------+----------+----------+
  | px       | py       | pz       |
  | 16 Bits  | 16 Bits  | 16 Bits  |
  | unsigned | unsigned | unsigned |
  +----------+----------+----------+

• px : position x
• py : position y
• pz : position z (isRelative: 0x1, Interior: 0x2)

  +-------------------------------+
  | pz                            |
  | 14 bit                        |
  | | | | | | | | | | | | | | | | | | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   + Interior
                                     + IsRelative

Indique la rotation (par rapport à quoi ?, le nord ?)

  +-------------+
  | Orientation |
  | 32 Bits     |
  | float       |
  +-------------+

  +-------------+
  | Behaviour   |
  | 48 Bits     |
  | Unsigned    |
  +-------------+

  +--------------+
  | Owner People |
  | 3 Bits       |
  | Unsigned     |
  +--------------+

  +----------------+
  | Name String Id |
  | 32 Bits        |
  | Unsigned       |
  +----------------+

  +------------+
  | Contextual |
  | 16 Bits    |
  | Unsigned   |
  +------------+

  +-------------+
  | Target List |
  | 32 Bits     |
  | Unsigned    |
  +-------------+

  +-----------+
  | Target ID |
  | 8 Bits    |
  | Unsigned  |
  +-----------+

  +-----------+
  | Mode      |
  | 44 Bits   |
  | Unsigned  |
  +-----------+

  +-----------+
  | VPA       |
  | 64 Bits   |
  | Unsigned  |
  +-----------+

  +-----------+
  | BARS      |
  | 32 Bits   |
  | Unsigned  |
  +-----------+

  +-----------+
  | VISUAL FX |
  | 11 Bits   |
  | Unsigned  |
  +-----------+

  +-----------+
  | VPB       |
  | 47 Bits   |
  | Unsigned  |
  +-----------+

  +-----------+
  | VPC       |
  | 58 Bits   |
  | Unsigned  |
  +-----------+

  +------------------+
  | Event Faction ID |
  | 32 Bits          |
  | Unsigned         |
  +------------------+

  +----------+
  | PvP Mode |
  | 10 Bits  |
  | Unsigned |
  +----------+

  +----------+
  | PvP Clan |
  | 32 Bits  |
  | Unsigned |
  +----------+

  +-------------------+
  | Entity Mounted ID |
  | 8 Bits            |
  | Unsigned          |
  +-------------------+

  +-----------------+
  | Rider Entity ID |
  | 8 Bits          |
  | Unsigned        |
  +-----------------+

  +---------------+
  | Outpost Infos |
  | 16 Bits       |
  | Unsigned      |
  +---------------+

  +--------------+
  | Guild Symbol |
  | 60 Bits      |
  | Unsigned     |
  +--------------+

  +---------------+
  | Guild Name ID |
  | 32 Bits       |
  | Unsigned      |
  +---------------+

A faire …

Juste un bit, vrai ou faux (true [1]/false [0]).

  +-------+
  | 1 bit |
  +-------+

  +--------+
  | 8 bits |
  +--------+

On écrit le chiffre en commençant par la partie la plus faible jusqu'au plus fort. Format little endian.

Ex. Valeur : 0x1234

  +--------+--------+
  | low    | high   |
  | 8 Bits | 8 Bits |
  +--------+--------+
  | 0x34   | 0x12   |

On écrit le chiffre en commençant par la partie la plus faible jusqu'au plus fort. Format little endian.

Ex. Valeur : 0x12345678

  +--------+--------+--------+--------+
  | root   | low    | medium | high   |
  | 8 Bits | 8 Bits | 8 Bits | 8 Bits |
  +--------+--------+--------+--------+
  | 0x78   | 0x56   | Ox34   | Ox12   |

On écrit le chiffre en commençant par la partie la plus faible jusqu'au plus fort. Format little endian.

Ex. Valeur : 0x12345678

  +--------+--------+--------+--------+
  | root   | low    | medium | high   |
  | 8 Bits | 8 Bits | 8 Bits | 8 Bits |
  +--------+--------+--------+--------+
  | 0x78   | 0x56   | Ox34   | Ox12   |

On écrit le chiffre en commençant par la partie la plus faible jusqu'au plus fort. Format little endian.

Ex. Valeur : 0x0123456789ABCDEF

  +--------+--------+--------+--------+--------+--------+--------+--------+
  | low    | low    | medium | medium | medium | high   | high   | high   |
  | 8 Bits | 8 Bits | 8 Bits | 8 Bits | 8 Bits | 8 Bits | 8 Bits | 8 Bits |
  +--------+--------+--------+--------+--------+--------+--------+--------+
  | 0xEF   | 0xCD   | OxAB   | Ox89   | Ox67   | Ox45   | Ox23   | Ox01   |

Une chaîne de caractères (on définit la taille, puis chaque caractère)

  +------------+---------+--------+------------+--------+
  | Taille : X | 1 char  | 2 char | . . .      | X char |
  | uint32     |  8 bits | 8 Bits |            | 8 bits |
  +------------+---------+--------+------------+--------+
                 1        2                       X == Taille

Une chaîne de caractères (on définit la taille, puis chaque caractère)

  +------------+---------+--------+------------+--------+
  | Taille : X | 1 char  | 2 char | . . .      | X char |
  | uint32     |  8 bits | 8 Bits |            | 8 bits |
  +------------+---------+--------+------------+--------+
                 1        2                       X == Taille

Une chaîne de caractères (on définit la taille, puis chaque caractère - ici un caractère tient sur 16 bits).

Ce format est utilisé sous Windows, nous préférons plus UTF-8 dans Godot, mais une simple conversion suffit pour passer d'un format à l'autre.

  +------------+-------------+-------------+------------+-------------+
  | Taille : X | char utf 16 | char utf 16 | . . .      | char utf 16 |
  | uint32     | 16 bits     | 16 Bits     |            | 16 bits     |
  +------------+-------------+-------------+------------+-------------+
                 1             2                          X == Taille

  +-------------------+--------------------------------+--------------
  | Source -> Dest.   | Message                        | Description
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/USER_CHARS          | Liste tous les personnages du joueur + quelque info sur le système (liste des shard, ...)
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/ASK_NAME            | Demande si on nom est disponible
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/VALID_NAME          | Réponse sur la validité du nom
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/CREATE_CHAR         | Création d'un personnage
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/USER_CHARS          | Liste tous les personnages du joueur + quelque info sur le système (liste des shard, ...)
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/SELECT_CHAR         | Selection le personnage
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/USER_CHAR           | Confirmation du personnage + renvoie des infos
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/READY               | Joueur confirme qu'il est pret
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/SHARD_ID            | Information sur le shard connecté
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | TEAM/CONTACT_INIT              | Liste les contacts du joueur
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | PHRASE/DOWNLOAD                | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | GUILD/UPDATE_PLAYER_TITLE      | Mise a jour pour le joueur
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | BOTCHAT/SET_FILTERS            | 
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | POSITION (X, Y, Z, Heading)    | Definition de la position actuelle du personnage
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | DEBUG/PING                     | Debug message with time
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DEATH/RESPAWN_POINT            | Position pour renaitre (apres une mort)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING/DYN_STRING              | Envoie une message (ici on envoie uniquement un ID, si besoin on interroge le serveur pour avoir le détail du message)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | PHRASE/DOWNLOAD                | message
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | ENCYCLOPEDIA/INIT              | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_INIT/INV                    | Initialise l'inventaire
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | NPC_ICON/GET_DESC              |  
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING_MANAGER/PHRASE_SEND     | Envoie une série de message (toujours via l'ID)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | USER/BARS                      | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | NPC_ICON/SET_DESC              | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | VisualProperty/Slot            | Description de l'environnement (autres joueurs/personnages
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_INIT/PLR/DatabaseXML        | Initialise la base de donnée - ici on trouve toutes les descriptions de l'environnement (personnage, groupe, pack animal et peut-être plus)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_GROUP/INIT_BANK             | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_UPD_PLR                     | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | PVP_EFFECTS/PVP_FACTION_POINTS | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_UPD_PLR/DatabaseXML         | Mise à jour la base de donnée - ici on trouve toutes les descriptions de l'environnement (personnage, groupe, pack animal et peut-être plus)
  +-------------------+--------------------------------+--------------

Dans les faits, le serveur envoie des identifiant pour le message, si le client ne connais pas l'identifiant, il demande au serveur qui lui répond.

+——————-+——————————–+————–

  | Source -> Dest.   | Message                        | Description
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING_MANAGER/PHRASE_SEND     | Envoie d'une phase à afficher (pouvant contenir des paramètres à remplacer) - envoie une liste d'ID (chaque ID correspond à un identifiant présent dans un tableau)
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | STRING_MANAGER/STRING_RQ       | Interrogation sur le contenu d'un identifiant 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING_MANAGER/STRING_RESP     | Retour du serveur pour une chaine de texte demande
  +-------------------+--------------------------------+--------------

Ex.:

Le serveur demande d'afficher le message 2264924217 (qui est la somme des messages 7705 avec comme paramètre 7849 + 7859)
7705 : &ZON&Vous êtes dans la région %s sur le continent %s.
7849 : Dispensaire
7859 : Terres Contrôlées

Cela donne le message : &ZON&Vous êtes dans la région Dispensaire sur le continent Terres Contrôlées.

  +-------------------+--------------------------------+--------------
  | Source -> Dest.   | Type de message                | Description
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/USER_CHARS          | Liste tous les personnages du joueur + quelque info sur le système (liste des shard, ...)
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/ASK_NAME            | Demande si on nom est disponible
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/VALID_NAME          | Réponse sur la validité du nom
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/CREATE_CHAR         | Création d'un personnage
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/USER_CHARS          | Liste tous les personnages du joueur + quelque info sur le système (liste des shard, ...)
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/SELECT_CHAR         | Selection le personnage
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/USER_CHAR           | Confirmation du personnage + renvoie des infos
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | CONNECTION/READY               | Joueur confirme qu'il est pret
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | CONNECTION/SHARD_ID            | Information sur le shard connecté
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | TEAM/CONTACT_INIT              | Liste les contacts du joueur
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | PHRASE/DOWNLOAD                | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | GUILD/UPDATE_PLAYER_TITLE      | Mise a jour pour le joueur
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | BOTCHAT/SET_FILTERS            | 
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | POSITION (X, Y, Z, Heading)    | Definition de la position actuelle du personnage
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | DEBUG/PING                     | Debug message with time
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DEATH/RESPAWN_POINT            | Position pour renaitre (apres une mort)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING/DYN_STRING              | Envoie une message (ici on envoie uniquement un ID, si besoin on interroge le serveur pour avoir le détail du message)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | PHRASE/DOWNLOAD                | message
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | ENCYCLOPEDIA/INIT              | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_INIT/INV                    | Initialise l'inventaire
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | NPC_ICON/GET_DESC              |  
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING_MANAGER/PHRASE_SEND     | Envoie une série de message (toujours via l'ID)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | USER/BARS                      | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | NPC_ICON/SET_DESC              | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | VisualProperty/Slot            | Description de l'environnement (autres joueurs/personnages
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_INIT/PLR/DatabaseXML        | Initialise la base de donnée - ici on trouve toutes les descriptions de l'environnement (personnage, groupe, pack animal et peut-être plus)
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_GROUP/INIT_BANK             | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_UPD_PLR                     | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | PVP_EFFECTS/PVP_FACTION_POINTS | 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | DB_UPD_PLR/DatabaseXML         | Mise à jour la base de donnée - ici on trouve toutes les descriptions de l'environnement (personnage, groupe, pack animal et peut-être plus)
  +-------------------+--------------------------------+--------------

Dans les faits, le serveur envoie des identifiant pour le message, si le client ne connais pas l'identifiant, il demande au serveur qui lui répond.

  +-------------------+--------------------------------+--------------
  | Source -> Dest.   | Type de message                | Description
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING_MANAGER/PHRASE_SEND     | Envoie d'une phase à afficher (pouvant contenir des paramètres à remplacer) - envoie une liste d'ID (chaque ID correspond à un identifiant présent dans un tableau)
  +-------------------+--------------------------------+--------------
  | Client -> Serveur | STRING_MANAGER/STRING_RQ       | Interrogation sur le contenu d'un identifiant 
  +-------------------+--------------------------------+--------------
  | Serveur -> Client | STRING_MANAGER/STRING_RESP     | Retour du serveur pour une chaine de texte demande
  +-------------------+--------------------------------+--------------

Ex.:

Le serveur demande d'afficher le message 2264924217 (qui est la somme des messages 7705 avec comme paramètres 7849 + 7859)
7705 : &ZON&Vous êtes dans la région %s sur le continent %s.
7849 : Dispensaire
7859 : Terres Contrôlées

Cela donne le message : &ZON&Vous êtes dans la région Dispensaire sur le continent Terres Contrôlées.

La structure du personnage est différente entre la création et l'envoie les caractèristiques vers les autres joueurs. Il en résulte une contrainte sur les paramètres pour faire coincidé les deux structures. Dans un premier cas, on retrouve toutes les propriétés sur un mutltiple de 8 bits, and le deuxième cas, on contracte les données en trois entier de 64 bits. (bref moins de place donc certain paramètres on pas la possibilité d'utiliser toutes les valeurs pouvant etre mise dans le premier cas. De plus quand on recharge les personnages, on retrouve la réduction appliqué.

• * Liste à puce

Type de message : CONNECTION/CREATE_CHAR

• (Uint8) Slot
• (Uint32) SheetId
• (Uint32) CSessionId
• (Uint32) name:size
• (UString) name:ustring (si la size > 0, attention, il y a des fortes contraintes uniquement [A-Za-z]+)
• (Uint8) People
• (Uint8) Sex
• (Uint8) NbPointFighter
• (Uint8) NbPointCaster
• (Uint8) NbPointCrafter
• (Uint8) NbPointHarvester
• (Sint32) StartPoint
• (Sint8) HairType
• (Sint8) HairColor
• (Sint8) GabaritHeight
• (Sint8) GabaritTorsoWidth
• (Sint8) GabaritArmsWidth
• (Sint8) GabaritLegsWidth
• (Sint8) GabaritBreastSize
• (Sint8) MorphTarget1
• (Sint8) MorphTarget2
• (Sint8) MorphTarget3
• (Sint8) MorphTarget4
• (Sint8) MorphTarget5
• (Sint8) MorphTarget6
• (Sint8) MorphTarget7
• (Sint8) MorphTarget8
• (Sint8) EyesColor
• (Sint8) Tattoo
• (Sint8) JacketColor
• (Sint8) TrousersColor
• (Sint8) HatColor
• (Sint8) ArmsColor
• (Sint8) HandsColor
• (Sint8) FeetColor

Source :

 khanat-opennel-code/code/ryzom/common/src/game_share/msg_client_server.h:114 class CCreateCharMsg
 khanat-opennel-code/code/ryzom/common/src/game_share/character_summary.h:35  struct CCharacterSummary
 khanat-opennel-code/code/ryzom/server/src/pd_support_service/stat_character.h:844 CStatsScanCharacter()

Ils existent plusieurs messages qui receptionne les caractèristiques.

• Les messages du type CONNECTION/USER_CHARS (qui les tous les personnages du joueur)
  • Utilise la structure VPA, VPB & VPC
• Les messages du type VisualProperty (on réception les caractèristiques des différentes entités [personnages d'autres joueurs, annimaux, …])
  • Utilise la structure VPA & VPC (pas la VPB - étrange)

VPA: VisualPropA est de type Uint64 (unsigned int 64 bits).

[Source: khanat-opennel-code/code/ryzom/common/src/game_share/player_visual_properties.h:32 struct SPropVisualA]

• Sex : 1 bit/booléan (max 1)
• JacketModel : 8 bits (max: 255)
• JacketColor : 3 bits (max: 7)
• TrouserModel : 8 bits (max 255)
• TrouserColor : 3 bits (max: 7)
• WeaponRightHand : 10 bits (max: 1023)
• WeaponLeftHand : 8 bits (max: 255)
• ArmModel : 8 bits (max: 255)
• ArmColor : 3 bits (max: 7)
• HatModel : 9 bits (max: 511)
• HatColor : 3 bits (max: 7)

Remarque concernant le sexe : On peut noter qu'il n'y a que 2 possibilités pour le sexe, mâle ou femelle. (on peut dire adieu aux autres formes de reproduction (asexuée, clonnage, changement de sexe suivant l'alimentation/age/température/…)

VPB: VisualPropB est de type Uint64 (unsigned int 64 bits).

[Source: khanat-opennel-code/code/ryzom/common/src/game_share/player_visual_properties.h:105 struct SPropVisualB]

• Name : 16 bits (max: 65535) → ID qui permettrant de retrouver dans la liste des mots stockés
• HandsModel : 9 bits (max: 511)
• HandsColor : 3 bits (max: 7)
• FeetModel : 9 bits (max: 511)
• FeetColor : 3 bits (max: 7)
• RTrail : 4 bits (max: 15)
• LTrail : 3 bits (max: 7)
• Reste : 17 bits non utilisée

VPC: VisualPropC est de type Uint64 (unsigned int 64 bits).

[Source: khanat-opennel-code/code/ryzom/common/src/game_share/player_visual_properties.h:163 struct SPropVisualC]

• MorphTarget1 : 3 bits (max: 7)
• MorphTarget2 : 3 bits (max: 7)
• MorphTarget3 : 3 bits (max: 7)
• MorphTarget4 : 3 bits (max: 7)
• MorphTarget5 : 3 bits (max: 7)
• MorphTarget6 : 3 bits (max: 7)
• MorphTarget7 : 3 bits (max: 7)
• MorphTarget8 : 3 bits (max: 7)
• EyesColor : 3 bits (max: 7)
• Tattoo : 7 bits (max: 127)
• CharacterHeight : 4 bits (max: 15)
• TorsoWidth : 4 bits (max: 15)
• ArmsWidth : 4 bits (max: 15)
• LegsWidth : 4 bits (max: 15)
• BreastSize : 4 bits (max: 15)
• Reste : 10 bits non utilisée