Logo Khaganat
Traductions de cette page?:

Ceci est une ancienne révision du document !


Récupérer les données : Mercurial, Git

Pour partager les modifications de code et de graphismes, nous utilisons un système de gestion des dépôts.

Les données du serveur de jeu Ryzom Core sont hébergées sur Bitbucket (mercurial) mais nous avons mis en place notre propre serveur Gitlab pour la gestion des données de Khaganat.

Site Internet de Bitbucket Elles sont régulièrement mises à jour par les participants au projet. C'est à partir de là que l'on peut récupérer tous les fichiers nécessaires à l'installation d'un serveur, à la création d'un jeu ou au déploiement d'un client. Pour l'heure, il n'existe pas de dépôt de tous les binaires que l'on peut compiler à partir de ces sources.

Cette page sert à expliquer les concepts clés de la gestion de dépôts. Pour ce qui est de l'utilisation et de l'apprentissage des commandes de chacun des deux systèmes de gestion de version, voyez les pages plus précises sur Mercurial et Git.

Si vous connaissez déjà tout ça, rendez-vous directement sur notre serveur Gitlab ! Vous pouvez aussi lire principe_de_développement_sur_khaganat pour savoir comment nous acceptons les contributions.

Nous allons donc voir dans un premier temps comment récupérer les fichiers, les synchroniser, voire proposer des modifications.

Gestion de dépôt : vocabulaire et concepts

Avant de voir comment réaliser les différentes opérations, il semble important de préciser quelques notions de vocabulaire. Les termes anglais ont été conservés car il est très fréquent que cela soient ceux que vous rencontrerez sur IRC ou dans des tutoriels.

L'endroit où les fichiers sont conservés sur Internet (la zone de Bitbucket qui accueille les fichiers Ryzom Core par exemple) s'appelle un repository (dépôt en français). En créant un compte sur Bitbucket (ou Github, ou Gitlab), vous allez créer votre propre repository, qui contiendra votre version des données, celle avec laquelle vous allez synchroniser votre répertoire local (sur votre ordinateur).

Le dépôt contient en outre un historique des modifications faites (dans le répertoire .hg pour mercurial, .git pour git). On présente chaque nouveau dépôt comme un fork (ang. bifurcation) de son dépôt initial, car il peut donner lieu à un projet distinct, selon les choix d'échange et de synchronisation qu'il choisit.

Clone, pull, update & merge

La première chose à faire pour travailler avec un repository de référence est de récupérer les données par un clone (ang. clone ) dans son propre repository. Si on l'a déjà fait voilà un moment et que l'on n'est pas certain d'avoir les dernières versions, il faut alors le vérifier et, le cas échéant, les récupérer, ce qui modifiera les données dans notre propre dépôt, on appelle cette opération un pull (ang. tirer). Une fois cela fait, on peut synchroniser les données que l'on a en local avec son dépôt : un update (ang. mise à jour).


Si des fichiers ont été modifiés des deux côtés, le système refusera de faire cela et proposera plutôt un Merge (ang. fusion, “comparer”). A priori cela se fera également automatiquement, tant que ce sont des lignes différentes qui auront été modifiées au sein d'un même fichier. Dans le cas contraire, il vous sera proposé manuellement de faire un choix ou de choisir comment synthétiser les deux modifications en une.

Commit & push

Lorsque l'on a réalisé un certain nombre de modifications sur ses fichiers locaux, il faut les enregistrer sur son repository. Pour cela, on fait un commit (ang. envoi, livraison), qui va copier en vérifiant si un merge ne serait pas préférable, s'il constate que des changements ont été fait également dans le repository (par le biais d'un pull récent par exemple). On indique généralement à cette occasion quels fichiers et lignes ont été modifiés, ou de très synthétiques commentaires.

Une fois ses données dans son repository, on peut faire un push (ang. pousser, “demande d'ajout”) pour que ses modifications soient acceptées par le repository du projet initial. Dans la cas probable où des fichiers y auront été modifiés depuis votre dernier pull, il faudra sûrement faire un pull/merge pour que cela soit possible (et donc un update de vos fichiers locaux également).

Principe de développement sur Khaganat

WIP

Nous avons organisé les données au sein du projet Khaganat en plusieurs dépôts, à la fois pour des raisons historiques (héritage des structures de Ryzom Core, voire de Nevrax), de nécessité pour les pipeline ou par commodité.

Adminsys

Khanat code

Le code servant à créer les binaires du jeu :

  • services du serveur ;
  • client ;
  • outils du pipeline ;
  • outils de création (Ryzom Core Studio, Georges Editor et World Editor…).

Khanat ressources

Les données utilisées pour créer le monde :

  • datasheets ;
  • primitives ;
  • fichiers de configuration ;
  • fichiers de traduction ;
  • système de son y compris les .wav.

Khanat assets source

Les fichiers utilisés pour créer les données graphiques du jeu :

  • dessins 2D multi-calques ayant généré les .png
  • textures de base ;
  • concept arts ;
  • bibliothèque d'éléments 3D servant à créer les objets 3D du jeu.

Khanat assets

La database graphique nécessaire au pipeline graphique de génération des éléments graphiques pour NeL, le moteur de jeu 3D :

  • fichiers de systèmes de particules et leurs textures, éléments 3D;
  • fichiers 3D à exporter ;
  • textures de jeu finales ;
  • fichiers de végétation ;
  • textures environnementales et les banks.

Khanat assets export

Un exemple de résultat d'un passage dans le pipeline graphique, avec tous les objets dans formats utilisés par NeL :

  • fichiers .shape pour les objets 3D ;
  • fichiers de LODs générés ;
  • fichiers de zone du terrain.

Ce dépôt est transitoire, présent à titre d'information / exemple des données. Il sera rendu obsolète avec le déploiement d'un pipeline complet

Khanat sound source

Les fichiers utilisés pour générer les fichiers sons du jeu :

  • sons à des formats différents ;
  • bibliothèque de sons utilisés dans des assemblages.

Khanat client data

Les fichiers qui sont déposés dans des .bnp dans le dossier /data du client lirria.

Ce dépôt est transitoire, présent à titre d'information / exemple des données. Il sera rendu obsolète avec le déploiement d'un pipeline complet

Rq: Les dépôts Fabrique et login-screen vont disparaître d'ici peu

CC Attribution-Share Alike 4.0 International Driven by DokuWiki
fr/recuperer_les_donnees.1463136067.txt.gz · Dernière modification : 2021/12/03 19:18 (modification externe)

Licences Mentions légales Accueil du site Contact