Ce qui se passe dans la Krypte depuis novembre dernier

Nous enchaînons les points hebdomadaires, mais il n'y a pas eu de résumé sur le blog depuis très longtemps. C'est l'occasion d'une première partie de bilan, centré sur les aspects les plus informatiques du projet. Un autre bilan suivra sur les autres aspects.

Ces derniers mois, Deed a continué à exécuter beaucoup de tests sur divers éléments du projet, ce qui a mené à beaucoup de débugage en collaboration avec les autres devs, en particulier Aleajactaest. Ce travail en commun entre serial tester et serial debogger a porté ses fruits. L'aspect le plus concret est que la migration du serveur sous Debian Stretch a enfin fonctionné. Le code est à jour, patché avec les dernières modifications faites par Ryzom Core.

Deed a aussi réussi à mettre plusieurs shard sur une seule adresse IP ; c'était jusque là compliqué techniquement et nous obligeait à louer plusieurs serveurs pour tester plusieurs shard. Acheter plusieurs ip n'est pas toujours le moins cher, surtout sur les serveurs lowcost, quand à passer à l'ipv6… c'est une bonne solution, mais entre la vieillesse du code et nos propres manques techniques, ce n'est pas encore fait.

Aleajactaest a travaillé sur les patchs pour Khanat OpenNeL, ainsi qu'à améliorer la compilation du serveur via gitlab-ci.

Un des travaux en cours était de remplacer l'interface de gestion via screen par un module python, plus simple ensuite à brancher sur une interface web (via Django). Ce module s'appelle Pymanager. Il a amélioré la réalisation du package afin de tirer parti des bonnes pratiques de Python (utilisation de pip). La documentation est générée avec grâce à Sphinx. Le code est testé ; c'est assez rare sur le projet pour être signalé !

YannK a commencé à faire une petite librairie python pour lire les Georges Sheet. Le but est de pouvoir les lire quand Blender 2.8 sortira, et d'y faire un éditeur qui fonctionne avec des outils plus pratiques que l'édition à la main des XML. Tycho a travaillé sur le package de cette librairie.

La cross-compilation du client marche aussi, grâce au travail en amont de Kervala, expliqué et détaillé par Glorf, testé et appliqué par Deed.

Aleajactaest a aussi travaillé sur les packages pour diverses distributions : Fedora, Archlinux, Ubuntu. Ce n'est pas encore dans les dépôts officiels, et ça ne le sera pas tant que le jeu lui-même ne sera pas plus stable, mais l'installation des clients sur ces OS peut s'en retrouver améliorée. Ces clients, ainsi que les versions static 32 bit et 64 bit, se trouvent dans le dépôt khanat-opennel-code, section “Artefact”.

Dans la grande suite de l'épopée “comment gérer le client”, certaines sont allé regarder les autres moteurs de jeu, et en particulier Godot. Godot est un projet qui a atteint une vraie maturité et qui est activement développé, et en plus on aime bien papoter avec les membres de leur projet.

Il a été décidé de tester Godot, dans deux optiques. Tout d'abord, pouvoir tester les visuels, marcher dans le Khanat ; bref, proposer un client assez minimaliste mais qui permette de mettre en valeur les propositions graphiques, 3D, musicales. C'est une façon de contourner les problèmes de pipeline de NeL et de voir un peu ce que ça donne.

Mais à partir de là… Les outils de Godot sont vraiment bien faits, et le fait que ce soit maintenu par une autre équipe permet de diviser le travail. Il est donc envisagé d'aller plus loin, de transformer ce premier client Godot minimaliste en un vrai client relié au serveur de MMORPG. Cette deuxième étape demandera du temps, car il faut en particulier travailler sur tout l'aspect réseau : comprendre ce que le serveur demande, précisément, afin que le client Godot envoie et reçoive les bonnes informations.

Cette annonce remet à plat nos souhaits de développer le pipeline graphique et les outils de leveldesign pour le client OpenNeL. Dans cette optique, il semblerait plus pertinent de se concentrer sur Godot, et donc de trouver des personnes compétentes sur l'aspect réseau (ce qui n'est pas forcément plus simple que de trouver des personnes compétentes sur l'aspect librairie graphique).

Rien n'est encore acté ; actuellement, Godot est en test pour ce client minimaliste et solo, qui verra forcément le jour. Mais ces tests permettent de valider notre hypothèse selon laquelle ce moteur de jeu et de création de jeu est adapté à nos besoins.

Osquallo et YannK travaillent activement à cette partie, et StraToN, l'un des développeurs de Godot, nous aide régulièrement.

C'est Aleajactaest qui travaille principalement sur la question : le but est de fournir des images docker permettant de tester le client et le serveur de façon simplifiée, de pouvoir faire des tests aussi dans un environnement isolé (vous ne voulez pas mettre le bazar dans vos librairies sur votre OS principal).

Depuis novembre, Aleajactaest a migré ses scripts docker sur un dépôt dédié, et mis la documentation à jour. Il y a un runner en place, et des artefacts. Les artefacts sur Gitlab sont des fichiers compressés contenant les binaires des divers éléments. L'image docker est volumineuse (environ 3Go) et contient le serveur, le client static 64bit, un accès ssh, web, l'interface texte avec screen.

Deed a installé Snowball sur son serveur et a réussi à s'y connecter avec un client. Pour rappel, Snowball est un jeu “démo” créé par Nevrax afin de montrer les propriétés de base du client et du serveur. C'est très minimaliste, et l'intérêt est donc d'avoir moins de choses à étudier pour comprendre le cœur des échanges réseau. Mais le client ne marche pas chez tout le monde, ce genre de test est réservé aux mages averties.

Vous avez déjà un bilan récemment ici. Teampass a été désactivé suite à une alerte de sécurité, mais il nous manque. Le pastebin n'a pas été réinstallé, le but étant de passer à Django et à l'excellent module codé par Tychobrahe.

Shepeng a amélioré et mis sur le Gitlab un playbook ansible pour faire une VM archlinux sous Xen. Ça marche, sauf la configuration réseau qui demande quelques ajustements. Le boot utilise le noyau de l'hyperviseur et non le noyau archlinux.

merlin8282 est passé Sysadmin général après avoir montré pendant plusieurs mois son implication dans le projet et ses compétences.

Neodarz a paramétré une instance searx afin de faire de la recherche sur plusieurs sites de la galaxie (khaganat, ryzom, ryzom core). Mais sur certains sites, il n'y a pas de moteur de recherche interne à brancher sur Searx, qui est un métamoteur, pas un crawler. De plus le moteur interne de certains morceaux est de toute façon très mauvais, par exemple celui de gitlab ne permet pas de trouver quoi que ce soit. Il s'est récemment remis au travail pour trouver une solution à ces soucis.

Nous avons trié le Kloud, jetant au passage plein de vieilles choses. Il reste à transférer ce qui a été trié là où il faut…

La page fr:principe_de_developpement_sur_khaganat a été mise à jour fin d'améliorer la participation au projet. Les dépôts Khaganat ont été réorganisés au sein d'un groupe, on voit ainsi toutes les issues d'un coup. De façon générale, les wikis ont été beaucoup relus ces derniers mois avec de la correction de coquilles, des précisions… Il y a cependant un certain nombre d'articles qui sont devenus obsolètes, tagguez-les comme tel et mettez un avertissement en haut de page si vous les croisez (en attendant de pouvoir les mettre à jour). Le Wikhan a aussi été nettoyé d'un certain nombre de pages doublon, reste d'un ancien transfert mal finalisé.

Isilin a trouvé un moyen de s'identifier de manière unique sur une ferme dokuwiki, en utilisant un seul cookie pour tout. Cela a été récemment mis en place sur notre propre installation.

Le transfert à XMPP est acté pour l'organisation générale. Voir le résumé dans l'article précédent. Linkmauve nous a permis de mettre de jolis logos pour illustrer les salons, il a créé le bot qui logue et ramène des flux rss. Vous pouvez l'aidez à l'améliorer sur https://git.linkmauve.fr/linkmauve/BotLogMauve/issues.