Aller au menu du forum Aller au contenu du forum Aller à la recherche dans le forum
Logo Khaganat
Menu principal

Compilation et mise à disposition des clients

Zatalyz

Actuellement, les clients foirent, sur tous les OS, parce qu'on a modifié trop de chose sans remettre à jour.

Il faudrait donc tout reprendre.

Autant essayer d'en profiter pour mettre en place une structure plus résiliente aussi.

1) Les clients à proposer
Nous avons plusieurs types de clients (indépendamment des OS) :
- Clicodrôme (un setup.exe à lancer sur Windows, un dépôt à ajouter sur Linux, et sur Mac je ne connais pas assez)
- Un client statique "pour les blonds" : ne s'installe pas forcément, mais est facile à lancer.
- Un client statique à bidouiller : on prend les éléments qu'on veut et on se débrouille comme un grand.

Je vais mettre le clicodrôme de côté pour le moment, car ça demande de répondre à des problématiques très différentes suivant les OS.

Le client statique pour les blonds, renommé "Blondie", lui, est relativement similaire sur chaque plate-forme : un zip, dans lequel on trouve les data, le client, les options de configuration, le tout déjà bien configuré, et il n'y a plus qu'à double-cliquer sur l'exécutable.

Nous allons avoir le "Full-Blondie", assez lourd, avec les datas ; au premier lancement, il y aura peut-être un premier petit patch, mais pas trop, puisque dès qu'on commencera à avoir beaucoup de changements dans les datas, on rafraichira Full-Blondie.

Il y a aussi "Smokey-Blondie" (ne vous demandez pas où je vais chercher ces noms ; je suis lasse des "vanilla", il est temps de s'amuser) : ce dernier est assez léger, avec uniquement le nécessaire pour lancer le client une première fois, ensuite il va patcher tout le reste (dont les datas).

L'intérêt est que Smokey-Blondie est une bonne base pour les hackers, sans avoir à recharger toutes les datas ; Full-Blondie, lui, est adapté aux gens qui préfèrent tout avoir en une fois, et ce sera la proposition de base.

Pour les "client statique à bidouiller", on propose bêtement de charger séparément les différents composants : exécutable, fichier de configuration, data, les deux derniers étant les mêmes pour tous les OS, avec des instructions détaillées dans le wiki sur comment bidouiller, par exemple l'usage du dossier user.

2) Un détour sur le Client Clicodrôme
Faire un exécutable pour Windows est relativement simple, en partant de la base du client Full-Blondie pour windows ; il suffit de demander dans quel dossier installer le jeu et de mettre un lien dans le menu de lancement. Y'a pas de raison qu'on ne l'ait pas, donc ?

Pour Mac, Siela1915 maitrise la question ; par contre, nous n'aurons pas Khanat disponible dans l'Apple Store de façon officielle, car c'est extrêmement cher. Cependant, les utilisateurs de Mac savent comment ajouter une application non-officielle, surtout si on leur fournit une solution où il n'y a qu'à cliquer sur "oui, je sais, c'est pas authentifié, mais je veux quand même y jouer".

Pour Linux, nous avons des choses à revoir. Dremor maitrise l'empaquetage pour toutes les distributions ; il faut ensuite ajouter un dépôt à ses sources, mais la plupart des utilisateurs linux savent faire, d'autant que le compilateur générique d'Opensuse donne des indications détaillées. Nous ne serons pas disponible dans les dépôts officiels des diverses distributions tant que le projet ne sera pas vraiment mature, mais... c'est normal. Le vrai point compliqué est la gestion des patchs ; une fois qu'on passe par un dépôt, le système n'apprécie pas que l'application se patche sans passer par le gestionnaire de paquets, et le gestionnaire de paquet demande les droits root. Bref, il faudra sans doute réfléchir pas mal avant d'arriver à quelque chose de vraiment fonctionnel.

3) Compilation automatique et mise à disposition
Une fois nos clients paramétrés, il faudrait pouvoir relancer la compilation d'une ou plusieurs versions assez rapidement, si possible sur le serveur. Visiblement, Gitlab permet ça, même si la compilation pour windows et mac risque d'être compliquée (vu que notre serveur est un linux...). Avec les hook, on peut aussi alléger la charge du serveur en proposant son propre ordi pour la compilation. Cette façon de procéder évite que la compilation des clients dépendent d'une personne et de sa disponibilité. La compilation pour les nul(le)s, je trouve ça cool, moi...

Si j'ai bien compris, on a divers morceaux à compiler : l'exécutable lui-même, différents suivant les OS et les architectures ; les datas (sauf qu'on a pas de pipeline donc on s'en moque), et ensuite il faut tout mettre ensemble dans un joli paquet (dossier=>zip) avec les fichiers de configuration. Et ça fait un Client.

Une fois qu'un client est compilé, il faudrait que ça se mette de façon quasi automatique sur une page propre et clair pour télécharger ça. Là, il est possible qu'un petit script permette de faire ça, du style :

mv ./linux-full-blondie-20161023.zip /var/www/clients/linux-full-blondie-current.zip


Donc : un dossier déjà compressé (pas forcément en zip, hein... même si ça a le mérite d'être compris partout), qu'on va déplacer dans un dossier en accès web, en renommant d'une façon toujours similaire, et on va faire une page web toute belle, avec des liens vers ces noms qui ne changent pas.

Comme ça, peu importe le niveau de blonditude des gens, ils auront une page pour télécharger le dernier client propre à leur OS, sans qu'on s'embête trop à faire des manips ; il y aura à lancer la compilation, puis à dire "ok, c'est officiel". Évidement, envoyer une nouvelle version du client vers la partie web ne sera accessible qu'aux gens autorisés (nos devs, quoi), mais pour ces derniers, ça va macher le boulot.

4) C'est bien beau, mais comment on refait les clients ?
Il y a plusieurs choses qui ne vont pas, et il fait tout faire en même temps.

- client_default.cfg : il doit être propre. Il serait temps de le documenter, de s'assurer qu'il est bien configuré, en accord avec nos datas et notre serveur de patch.

- Datas : Deed et moi avons nettoyé et réarrangé les datas ; ça va encore évoluer, mais pour le moment, on s'appuie sur ça. Il faut donc repartir de cette base-là, pour le client_default.cfg et le serveur de patch.

- Serveur de patch : Kervala a réussi à améliorer le serveur de patch, qui peut patcher tout le dossier d'installation à présent, y compris le client_default.cfg (et l'exécutable ?). Il faudrait voir avec lui comment faire, sans doute mettre à jour notre serveur, puis configurer le serveur de patch pour qu'il fonctionne avec la nouvelle version des datas.

- Exécutables : Je ne sais pas si recompiler les exécutables est réellement nécessaire ou non ; il y a sans doute des nouveautés côté Ryzom Core à merger avec notre client, mais même sans, ça devrait marcher ?

J'attends vos précisions pour la suite des opérations : comment s'y prend-t-on pour que ça marche ?


deed

oui ok tout a fait d'accord , faudra juste faire une mise a jour de l'exécutable que si ca demande une obligation avec le server
et garder les clients fait par gitlab pour les dev

Dremor

Pour Linux, mon problème est le suivant :

- Le patcheur cherche les datas dans un dossier relatif au fichier "client_config" de base (celui qui est dans /etc/khanat), c'est à dire dans /etc/khanat/data.
- Le jeu, lui, le cherche dans /usr/share/khanat
- Les gestionnaire de paquets ne peuvent pas mettre de fichiers dans les dossier utilisateurs (à ce que je sache tout du moins), ce qui exclut d'utiliser /home/[votre nom]

Il faudrait recoder le patcheur pour qu'il puisse mettre les datas dans $HOME/.khanat (notez de $HOME, qui est automatiquement remplacé par /home/[votre nom de compte], équivalent à %USERDIR% dans Windows), chose que je ne sait pas faire.

Zatalyz

Citation- Les gestionnaire de paquets ne peuvent pas mettre de fichiers dans les dossier utilisateurs (à ce que je sache tout du moins), ce qui exclut d'utiliser /home/[votre nom]
Pourtant il y a pleins de fichiers de config dans /home/user. Mais c'est parce que c'est généré par le logiciel lui-même au premier lancement et pas mis directement par le gestionnaire de paquets ?

Pour que le patcheur mette les datas dans $HOME/.khanat, l'idée serait peut-être que le gestionnaire de paquet installe dans le dossier où il a le droit (/etc, /usr/share ?), mais qu'au premier lancement il créé dans  $HOME/ le dossier .khanat avec la copie du client_config, donc toutes les datas seront là. En gros, le client linux installe ce qui sert à lancer le jeu, mais stocke toute la configuration dans $HOME/ comme n'importe quel autre logiciel ; sauf que là, cette "configuration" c'est aussi les datas :D

Dremor

Citation de: Zatalyz le 31 Juillet 2016 à 17:15:21
Citation- Les gestionnaire de paquets ne peuvent pas mettre de fichiers dans les dossier utilisateurs (à ce que je sache tout du moins), ce qui exclut d'utiliser /home/[votre nom]
Pourtant il y a pleins de fichiers de config dans /home/user. Mais c'est parce que c'est généré par le logiciel lui-même au premier lancement et pas mis directement par le gestionnaire de paquets ?

Exactement

Citation de: Zatalyz le 31 Juillet 2016 à 17:15:21
Pour que le patcheur mette les datas dans $HOME/.khanat, l'idée serait peut-être que le gestionnaire de paquet installe dans le dossier où il a le droit (/etc, /usr/share ?), mais qu'au premier lancement il créé dans  $HOME/ le dossier .khanat avec la copie du client_config, donc toutes les datas seront là. En gros, le client linux installe ce qui sert à lancer le jeu, mais stocke toute la configuration dans $HOME/ comme n'importe quel autre logiciel ; sauf que là, cette "configuration" c'est aussi les datas :D

Oui, c'est par exemple ce que fait GOG et Steam. Le gestionnaire de paquet installe un "installeur", qui s'occupe de DL et mêtre à jour Steam et tout ce qui est nécessaire avec.

Licences Mentions légales Accueil du site Contact