Derniers messages
Dernier message par YannK - 12 Juillet 2023 à 11:40:49
Cliquez pour afficher le message
Super boulot, Alea, merci beaucoup d'avoir entrepris de mettre tout ça au clair. Je suis trop nul en UML pour avoir osé m'y lancer.
J'adhère globalement à ta proposition, qui est similaire à ce que Nevrax avait fait pour OpenNeL et la résilience de ce modèle n'est plus à prouver je pense.
Est-ce que tu pourrais détailler ce que tu mets dans « Donnée actions » ? Je ne suis pas certain d'en voir les contours : on est ok que c'est le serveur qui valide une action et donc ses répercussions sur le monde/les autres joueuses, mais est-ce que tu y mets plus que ça ? Je ne vois pas la raison qui te pousse à y mettre de la persistance, même si elle n'est pas aussi longue que pour les « Données décor ». Du log me semble intéressant, pour monitorer, est-ce que c'est ça que tu ferais persistant ?
Je sépare la question API de celle des bots :
À partir de tout ça, il y a pour moi quelques questions stratégiques à définir avant qu'on puisse effectivement se mettre au boulot :
Je pense qu'on pourra compléter au fur et à mesure la détermination des différents points mais on a là une belle base pour entamer le boulot serveur, merci beaucoup Alea
J'adhère globalement à ta proposition, qui est similaire à ce que Nevrax avait fait pour OpenNeL et la résilience de ce modèle n'est plus à prouver je pense.
Est-ce que tu pourrais détailler ce que tu mets dans « Donnée actions » ? Je ne suis pas certain d'en voir les contours : on est ok que c'est le serveur qui valide une action et donc ses répercussions sur le monde/les autres joueuses, mais est-ce que tu y mets plus que ça ? Je ne vois pas la raison qui te pousse à y mettre de la persistance, même si elle n'est pas aussi longue que pour les « Données décor ». Du log me semble intéressant, pour monitorer, est-ce que c'est ça que tu ferais persistant ?
Je sépare la question API de celle des bots :
- avoir une API claire me semble intéressant pour permettre des clients différents de celui 3D que nous proposerons par défaut. Il faudrait y intégrer une validation quelconque (token individuel par modèle de client ?) pour permettre d'échanger avec le serveur en toute sécurité. Ce serait valable pour notre client, afin de se garantir contre des modifs dans le code qui permettrait des exploits. Et on pourrait en effet se servir de ça pour faire des tests lors du développement (simulation d'actions en masse, etc.), je trouve ça vraiment super comme idée.
- Sur les bots, Zatalyz a proposé déjà pas mal de chose sur le wikhan : https://khaganat.net/wikhan/fr:reroll et on peut en parler plus longuement sur le sujet qu'elle a initié là : Multicompte, bot et compagnie (oui oui, ce sujet a plus de dix ans
)
À partir de tout ça, il y a pour moi quelques questions stratégiques à définir avant qu'on puisse effectivement se mettre au boulot :
- est-ce qu'on fait un proxy de connexion avec agrégation (c'est le choix d'OpenNeL) ?, ce qui implique une plus grande latence, comme tu dis, ainsi qu'une sérialisation des données afin d'optimiser les échanges. Donc plus de complexité de transfert des infos. J'avoue que je préfère cette approche (y compris par rapport à du multicast) car on réduit la surface d'attaque des serveurs, ce qui semble devenir un souci de plus en plus grand avec le temps.
- la question de la persistance des données longues, qui seront streamées depuis et vers le disque dur, qui sera un goulot d'étranglement selon le volume qu'on décide de valider régulièrement (oui, Star Citizen je pense à toi
). On n'est pas au tick comme sur le déplacement, mais il y a là encore une décision stratégique à prendre. Y prévoir de la souplesse de paramétrage (sur plusieurs variables : délai, façon de streamer les données, distance aux objets InGame qui détermine la densité des infos à récupérer etc.) depuis le backend serveur afin de se garder de quoi faire des stress tests serait pertinent je pense. Il faudra d'ailleurs y inclure l'envoi des données de « Gestion de position » à la déconnexion de la joueuse et, de façon plus globale, des logs sur les différents services, afin qu'on ait de quoi monitorer/modérer depuis le backend. - la partie « Discussion » devra être pensée de façon plus fine, mais ce n'est pas urgent. on a dit qu'on allait se baser sur XMPP, mais il s'y greffe la question de la modération, de l'accès aux messages privés et de l'archivage, qui sont des questions délicates. Il faut donc y intégrer un point de persistance.
- Enfin, comme on est en France, il serait bon de se mettre quelque part les questions RGPD afin qu'on ne galère pas par la suite. Je me disais qu'on pourrait l'aborder de la même façon que Marien, de Framasoft, qui propose une solution qui pourrait s'implémenter au fur et à mesure : https://marienfressinaud.fr/gdpr-txt.html
Je pense qu'on pourra compléter au fur et à mesure la détermination des différents points mais on a là une belle base pour entamer le boulot serveur, merci beaucoup Alea
Dernier message par Lyne - 08 Juillet 2023 à 21:43:47
Cliquez pour afficher le message
Compte-rendu du point hebdo du 06/07/2023
K'Deed
J'ai mis à jour Gitlab !!
Nouvelle interface ou pas, c'est réglable
Si il y a rien d'autre : " Godot 4.1 est sorti, ce matin" !!!!
J'ai joué avec le plugin de Zylann pour créer des maps, il ne bug pas avec Godot 4.0 mais il ne se lance pas avec Godot 4.1. J'ai fait un grand terrain plat avec des bordures autour (comme dans les lacs de Ryzom pour faire une délimitation facile). Il y a une petite montagne avec une piste pour la grimper. Il y a un lac . Le but, c'est de me faire la main , petit à petit en faisant une map style Silan (petit mais complet)
K'Deed
J'ai mis à jour Gitlab !!
Nouvelle interface ou pas, c'est réglable
Si il y a rien d'autre : " Godot 4.1 est sorti, ce matin" !!!!
J'ai joué avec le plugin de Zylann pour créer des maps, il ne bug pas avec Godot 4.0 mais il ne se lance pas avec Godot 4.1. J'ai fait un grand terrain plat avec des bordures autour (comme dans les lacs de Ryzom pour faire une délimitation facile). Il y a une petite montagne avec une piste pour la grimper. Il y a un lac . Le but, c'est de me faire la main , petit à petit en faisant une map style Silan (petit mais complet)
Dernier message par aleajactaest - 05 Juillet 2023 à 22:20:45
Cliquez pour afficher le message
Je vous soumets ma vision sur l'architecture.
Bon évidemment il s'agit d'une réflexion sur le sujet, tout remarque/analyse est bonne.
[Merci de détailler pourquoi]
Je me focalise sur la partie serveur, qui va recevoir les communications et centraliser les actions.
Lexique :
Client : programme lancé sur les postes permettant d'interagir dans l'univers (avec plus ou moins des fonctionnalité suivantes : déplacement, communication instantané, 3D, ...)
Serveur : il s'agit d'une (ou plusieurs machines) utilisé pour contenir des processus (programmes) qui gèrent la communication avec les Clients
Bot : programme qui simule un joueur
Je pars du postulat suivant:
1- Le serveur a toujours raison [idiot comme paradigme, mais il faut choisir entre les clients et le serveur, notez que je dis les clients mais lesquels à raison parmi eux]
2- Minimiser les éléments entre les clients et le serveur (afin de réduire au maximum la latence)
3- Avoir la scalabilité (capacité à continuer de manière normale avec l'augmentation du nombre de personne connecté, bon il faudra voir aussi les limite car suivant les moyen on devra limiter le nombre de machine serveur)
4- Avoir de la redondance (être capable de fonctionner avec la perte d'une partie de l'infrastructure, possibilité de reconnexion rapide, voir le pire bascule complet sur un autre site, bon les délais de bascule varie en fonction du problème)
5- Avoir le moins d'interaction avec la base de donnée [évite des écriture intempestive, relation trop complexe dans la base, éviter les traitements post-séance]
6- Avoir un système d'équité sur l'utilisation de la bande passante réseau (ne pas avoir que le joueur 1 qui répond et agit sans de retour du joueur 2, bref des mécanismes permettant de réguler l'activité de façon équitable [tant que le temps de réponse reste raisonnable pour tout le monde])
7- Gestion des "Bots", ici on rentre plus dans comment gère t-on cela car cela va arriver.
* avoir une API claire avec une identification qu'il s'agit d'un BOT
* avoir la localisation des sources/données/version utilisé pour démarrer le BOT
* Licence qui me semble doit être identique au notre (voir plus ouvert)
* savoir si le Bot est autoriser à s'exécuter dans l'environnement de Prod ou Dev (utile pour les testeurs et claire pour ceux qui font volontairement des erreurs)
* Comment doit-on gérer les personne qui utilise un Bot comme étant un joueur réel?
* Faut-il mettre des différence entre Joueur/Bot?
- Je dirais que oui: concernant la durée d'utilisation un Bot travail 24h, pour un humain s'est impossible
( caractéristiques différentes ?, temps de réponse différent ?)
Ma première idée de séparer les processus de communication serveur pour chaque fonction.
Certaine comme le déplacement sont tout le temps sollicité, à l'inverse l'inventaire auront une activité plus faible.
En séparant les activités, on permet de se séparer d'un étage d'agrégation/compression, et aussi de pouvoir lancer sur une machine différente les processus gourmands en cpu/mémoire ou réseau.
Le problème est que l'on augmente la surface d'attaque sur le serveur.
Le deuxième problème est que certain joueur n'aurait pas la possibilité de communiquer avec plusieurs serveur (problème de firewall), dans ce cas je propose de mettre un processus d'agrégation pour eux (seule eux sont impacté)
J'avais aussi imaginé pouvoir faire une communication en multicast, avantage pour le déplacement des joueurs, pas besoin de renvoyer la même information plusieurs fois. Idée difficile à mettre en place si la partie réseau [que l'on ne maîtrise pas] n'ouvre pas ce type de flux.
Processus:
1- Authentification
2- Gestion de la position
3- Gestion de l'inventaire
4- Gestion des quêtes
5- Gestion des actions en cours [ici on pensera à écrire dans la Base de Donnée l'heure de début, facile ensuite à savoir si l'action est fini en comparant avec l'heure actuelle]
6- Gestion des discussions
7- Éléments présents (décors, object amovible, ...]
8- Caractéristique/Compétence/Faculté/...
9- Identification des noms des personnage (propre à chaque joueur)
X- certaine une fonctionnalité que j'ai oublié
La gestion des positions devrait se faire en plusieurs étapes, avec plusieurs cercles autour du joueur pour connaitre les mouvements des autres.
A savoir que l'on a besoin de savoir si notre voisin le plus proche s'est déplacé d'un mètre, par contre celui qui est à 1km, pas besoin d'avoir l'information à chaque pas (que l'on ne verra pas à l'écran car imperceptible)
Bref, il me semble qu'il faudra un processus pour géré un nombre limité de joueur, et des processus réceptionnant ces info pour gérer les masses de joueurs (et échanger entre eux ces mouvements)
Pour la base de donnée, une simple base de donnée clef/valeur me semble plus "simple" à gérer.
Autre point, certainement information ont une durée de vie très courtes (comme la position), privilégié la mémoire, et d'autre très long (comment l'inventaire), ici on pourrait par exemple se reposer sur un fichier.
Le processus d'authentification aura pour fonction de démarrer/attribuer les processus utilisable pour le client (avec un identifiant/clef pour chaque processus)
La redondance des processus, un primaire et un secondaire (le primaire donnant les info au secondaire), en cas de crash du premier, le secondaire devient primaire et un processus de supervision relance un autre processus (afin d'avoir un deuxième processus actif)
La réplication sur un autre site demandera plus un processus intermédiaire pour copier les info avec durée moyen/longue sur le site distant (aucun intérêt pour les données à durée courte)
You cannot view this attachment.
@+
AleaJactaEst
PS.:
Fichier PlantUML pour ceux qu'ils veulent reprendre et améliorer.
You cannot view this attachment.
Bon évidemment il s'agit d'une réflexion sur le sujet, tout remarque/analyse est bonne.
[Merci de détailler pourquoi]
Je me focalise sur la partie serveur, qui va recevoir les communications et centraliser les actions.
Lexique :
Client : programme lancé sur les postes permettant d'interagir dans l'univers (avec plus ou moins des fonctionnalité suivantes : déplacement, communication instantané, 3D, ...)
Serveur : il s'agit d'une (ou plusieurs machines) utilisé pour contenir des processus (programmes) qui gèrent la communication avec les Clients
Bot : programme qui simule un joueur
Je pars du postulat suivant:
1- Le serveur a toujours raison [idiot comme paradigme, mais il faut choisir entre les clients et le serveur, notez que je dis les clients mais lesquels à raison parmi eux]
2- Minimiser les éléments entre les clients et le serveur (afin de réduire au maximum la latence)
3- Avoir la scalabilité (capacité à continuer de manière normale avec l'augmentation du nombre de personne connecté, bon il faudra voir aussi les limite car suivant les moyen on devra limiter le nombre de machine serveur)
4- Avoir de la redondance (être capable de fonctionner avec la perte d'une partie de l'infrastructure, possibilité de reconnexion rapide, voir le pire bascule complet sur un autre site, bon les délais de bascule varie en fonction du problème)
5- Avoir le moins d'interaction avec la base de donnée [évite des écriture intempestive, relation trop complexe dans la base, éviter les traitements post-séance]
6- Avoir un système d'équité sur l'utilisation de la bande passante réseau (ne pas avoir que le joueur 1 qui répond et agit sans de retour du joueur 2, bref des mécanismes permettant de réguler l'activité de façon équitable [tant que le temps de réponse reste raisonnable pour tout le monde])
7- Gestion des "Bots", ici on rentre plus dans comment gère t-on cela car cela va arriver.
* avoir une API claire avec une identification qu'il s'agit d'un BOT
* avoir la localisation des sources/données/version utilisé pour démarrer le BOT
* Licence qui me semble doit être identique au notre (voir plus ouvert)
* savoir si le Bot est autoriser à s'exécuter dans l'environnement de Prod ou Dev (utile pour les testeurs et claire pour ceux qui font volontairement des erreurs)
* Comment doit-on gérer les personne qui utilise un Bot comme étant un joueur réel?
* Faut-il mettre des différence entre Joueur/Bot?
- Je dirais que oui: concernant la durée d'utilisation un Bot travail 24h, pour un humain s'est impossible
( caractéristiques différentes ?, temps de réponse différent ?)
Ma première idée de séparer les processus de communication serveur pour chaque fonction.
Certaine comme le déplacement sont tout le temps sollicité, à l'inverse l'inventaire auront une activité plus faible.
En séparant les activités, on permet de se séparer d'un étage d'agrégation/compression, et aussi de pouvoir lancer sur une machine différente les processus gourmands en cpu/mémoire ou réseau.
Le problème est que l'on augmente la surface d'attaque sur le serveur.
Le deuxième problème est que certain joueur n'aurait pas la possibilité de communiquer avec plusieurs serveur (problème de firewall), dans ce cas je propose de mettre un processus d'agrégation pour eux (seule eux sont impacté)
J'avais aussi imaginé pouvoir faire une communication en multicast, avantage pour le déplacement des joueurs, pas besoin de renvoyer la même information plusieurs fois. Idée difficile à mettre en place si la partie réseau [que l'on ne maîtrise pas] n'ouvre pas ce type de flux.
Processus:
1- Authentification
2- Gestion de la position
3- Gestion de l'inventaire
4- Gestion des quêtes
5- Gestion des actions en cours [ici on pensera à écrire dans la Base de Donnée l'heure de début, facile ensuite à savoir si l'action est fini en comparant avec l'heure actuelle]
6- Gestion des discussions
7- Éléments présents (décors, object amovible, ...]
8- Caractéristique/Compétence/Faculté/...
9- Identification des noms des personnage (propre à chaque joueur)
X- certaine une fonctionnalité que j'ai oublié
La gestion des positions devrait se faire en plusieurs étapes, avec plusieurs cercles autour du joueur pour connaitre les mouvements des autres.
A savoir que l'on a besoin de savoir si notre voisin le plus proche s'est déplacé d'un mètre, par contre celui qui est à 1km, pas besoin d'avoir l'information à chaque pas (que l'on ne verra pas à l'écran car imperceptible)
Bref, il me semble qu'il faudra un processus pour géré un nombre limité de joueur, et des processus réceptionnant ces info pour gérer les masses de joueurs (et échanger entre eux ces mouvements)
Pour la base de donnée, une simple base de donnée clef/valeur me semble plus "simple" à gérer.
Autre point, certainement information ont une durée de vie très courtes (comme la position), privilégié la mémoire, et d'autre très long (comment l'inventaire), ici on pourrait par exemple se reposer sur un fichier.
Le processus d'authentification aura pour fonction de démarrer/attribuer les processus utilisable pour le client (avec un identifiant/clef pour chaque processus)
La redondance des processus, un primaire et un secondaire (le primaire donnant les info au secondaire), en cas de crash du premier, le secondaire devient primaire et un processus de supervision relance un autre processus (afin d'avoir un deuxième processus actif)
La réplication sur un autre site demandera plus un processus intermédiaire pour copier les info avec durée moyen/longue sur le site distant (aucun intérêt pour les données à durée courte)
You cannot view this attachment.
@+
AleaJactaEst
PS.:
Fichier PlantUML pour ceux qu'ils veulent reprendre et améliorer.
You cannot view this attachment.
Dernier message par deed - 02 Juillet 2023 à 18:18:42
Cliquez pour afficher le message
Oui, tu y es admin, je crois.
Tu as plein de choix differents mais je n'ai pas réussi à tous faire fonctionner.
Tu peux créer un fork, créer une branche.
Tu peux utiliser ton user ou utiliser le bot weblate pour push.
Tu as plein de choix differents mais je n'ai pas réussi à tous faire fonctionner.
Tu peux créer un fork, créer une branche.
Tu peux utiliser ton user ou utiliser le bot weblate pour push.
Dernier message par YannK - 02 Juillet 2023 à 17:08:21
Cliquez pour afficher le message
AH oui, c'est vrai qu'on a weblate aussi. Il faudrait que je regarde quelles serait la solution la plus simple pour nous pour en récupérer les traductions et y ajouter les nouveaux termes. Tu as regardé un peu comment ça marche en interne ?
Dernier message par deed - 02 Juillet 2023 à 14:22:28
Cliquez pour afficher le message
Voir comment on s'organise avec Weblate pour les fichiers de traduction.
J'ai jamais trop bien compris l'ensemble (et je ne suis pas dev :p) mais j'aimerai bien que le client soit coupé en un maximum de plugin.
Pour une raison, c'est que les plugins peuvent servir à d'autre et surtout que c'est "autre" peuvent aider à dev.
J'ai jamais trop bien compris l'ensemble (et je ne suis pas dev :p) mais j'aimerai bien que le client soit coupé en un maximum de plugin.
Pour une raison, c'est que les plugins peuvent servir à d'autre et surtout que c'est "autre" peuvent aider à dev.
Dernier message par YannK - 02 Juillet 2023 à 11:36:29
Cliquez pour afficher le message
Je propose qu'on échange ici sur la façon dont on met les choses en place sur la forge.
Nous allons travailler sur le client 3D Godot depuis le groupe MMORPG Khanat comme précédemment. Après un peu de ménage et d'archivage, on trouve en son sein :
Un ensemble de dépôt qui ne seront alimentés que via des Merge Request afin d'avoir des Changelogs propres et des commits apportant un lot de fonctionnalités répondant à un Ticket :
Le dépôt suivant pourrait aussi n'être rempli que via des Merge Request, si un pipeline alimente automatiquement ensuite le dépôt Khanat client 3D assets. Il pourrait aussi être alimenté via un plugin Blender dédié (du type Khanat tools, en cours de conception) afin de garantir un contrôle qualité :
Enfin, ces deux dépôts servent à rendre accessibles des éléments pouvant alimenter les différents travaux, sans qu'un fonctionnement précis pour chacun ait été décidé :
Et il reste encore :
Enfin, il y a le milestone 0.1 que je me propose d'effacer et d'en réorganiser les tickets pour correspondre à ce qu'on peut faire avec Godot 4 en l'état.
Qu'en pensez-vous ?
Une fois qu'on sera un peu fixées, je reprendrai la page Contribuer : les dépôts du projet Khaganat du Wikhan.
Nous allons travailler sur le client 3D Godot depuis le groupe MMORPG Khanat comme précédemment. Après un peu de ménage et d'archivage, on trouve en son sein :
- Khanat Guide de Développement qui définit les bonnes pratiques et qui doit servir, à terme, à alimenter des pages du wikhan, peut-être à générer un pdf, un epub etc. afin d'en faciliter la consultation par les contributrices.
Un ensemble de dépôt qui ne seront alimentés que via des Merge Request afin d'avoir des Changelogs propres et des commits apportant un lot de fonctionnalités répondant à un Ticket :
- Khanat client qui est le dépôt principal pour le client
- Khanat client 3D assets, qui pourrait aussi recevoir du contenu via un pipeline automatique depuis Khanat Client 3d Assets Sourcefiles
- Khanat client 3D textures library
Le dépôt suivant pourrait aussi n'être rempli que via des Merge Request, si un pipeline alimente automatiquement ensuite le dépôt Khanat client 3D assets. Il pourrait aussi être alimenté via un plugin Blender dédié (du type Khanat tools, en cours de conception) afin de garantir un contrôle qualité :
Enfin, ces deux dépôts servent à rendre accessibles des éléments pouvant alimenter les différents travaux, sans qu'un fonctionnement précis pour chacun ait été décidé :
Et il reste encore :
- Khanat server docker que je me propose d'archiver car plus en rapport avec le développement actuel.
Enfin, il y a le milestone 0.1 que je me propose d'effacer et d'en réorganiser les tickets pour correspondre à ce qu'on peut faire avec Godot 4 en l'état.
Qu'en pensez-vous ?
Une fois qu'on sera un peu fixées, je reprendrai la page Contribuer : les dépôts du projet Khaganat du Wikhan.
Dernier message par Lyne - 30 Juin 2023 à 21:48:05
Cliquez pour afficher le message
Compte-rendu du point hebdo du 29/06/2023
Zatalyz
De mon côté j'ai continué un peu à me former sur le mail pas pas autant que je l'aurais voulu, depuis dimanche l'AFK ne m'a pas vraiment laissé geeker... donc rien de plus
YannK
J'ai commencé à bosser sur la modélisation depuis les concepts du cmuzda, mais je ne suis pas convaincu par le résultat. Il va falloir que je trouve une autre façonde procéder moins laborieuse
J'ai aussi échangé avec rollniak à propos de l'accueil de la contribution et il m'a donné quelques idées et pistes à suivre
Lyne
De mon côté, j'ai publié l'article de blog sur l'AG
K'Deed
a mis à jour Peertube, Nextclouds*3 et Collabora !
annonce la sortie de RC1 de Godot 4.1 mais y est pour rien :p
Zatalyz
De mon côté j'ai continué un peu à me former sur le mail pas pas autant que je l'aurais voulu, depuis dimanche l'AFK ne m'a pas vraiment laissé geeker... donc rien de plus
YannK
J'ai commencé à bosser sur la modélisation depuis les concepts du cmuzda, mais je ne suis pas convaincu par le résultat. Il va falloir que je trouve une autre façonde procéder moins laborieuse
J'ai aussi échangé avec rollniak à propos de l'accueil de la contribution et il m'a donné quelques idées et pistes à suivre
Lyne
De mon côté, j'ai publié l'article de blog sur l'AG
K'Deed
a mis à jour Peertube, Nextclouds*3 et Collabora !
annonce la sortie de RC1 de Godot 4.1 mais y est pour rien :p
Dernier message par YannK - 29 Juin 2023 à 22:07:04
Cliquez pour afficher le message
Bonjour à toutes, je propose qu'on se serve de ce fil pour organiser le travail en asynchrone pour le client Khanat développé sous Godot.
Le lien vers le document de Game Design (non achevé) : https://khaganat.net/wikhan/fr:gamedesign:khanat:start
Quelques liens vers des sujets toujours valides en 2023 (a priori).
Programmation :
Gameplay
Pipelines
Graphisme
Le lien vers le document de Game Design (non achevé) : https://khaganat.net/wikhan/fr:gamedesign:khanat:start
Quelques liens vers des sujets toujours valides en 2023 (a priori).
Programmation :
- Organisation des dépôts au sein du groupe MMORPG Khanat
- Architecture des services
- Exécutables et partages structurels
- Godot et réseau
Gameplay
- Khompétences, Khapacités et KhasesSignifier le HRP
- Plateforme ou non
- Intégrer le vol en jeu ?
- XMPP en jeu et au-delà ?
- (télé)(konta?)pathie, silence et rêve dans la communication ra
Pipelines
Graphisme
#100
Général / Re : Qui a fait quoi ?
Cliquez pour afficher le message
Compte-rendu du point hebdo du 22/06/2023
Zatalyz
De mon coté une tentative de mise à jour des wikis mais y'a plein de trucs qui ne vont pas alors... ça sera quand les plugins seront mis à jour ou que j'ai le temps de débuguer
Et aussi j'ai bien progressé dans mon apprentissage du mail ; le moment où je pourrait migrer celui de Khaganat approche. Je n'ai pas trop d'inquiétude pour celui-là car on est surtout en mode "réception"
Et ça, je sais recevoir des mails à présent
YannK
J'ai enfin terminé l'outil de génération automatique des Changelog : https://framagit.org/YannKervran/Bareto C'est du BASH car je déteste faire de la maintenance et qu'avec de tels scripts, il n'y en a que très peu
Il est conçu surtout pour servir dans le cadre d'une CI, afin de noter et organiser les Changelog des Merge Request sur le dépôt principal, mais les scripts fonctionnent aussi en local si certaines veulent les utiliser pour leurs besoins propres.
Un exemple de Changelog un peu long ainsi généré : https://framagit.org/YannKervran/Bareto/-/blob/main/CHANGELOG.md
Ça nous permettra d'avoir la liste des contributions bien propres pour les différents projets. Et une Release note facile à rédiger car toute prête
Il me reste à intégrer des explications dans le Guide du Développement pour expliquer la façon dont cela fonctionne un peu plus en détail pour notre fonctionnement au sein de Khanat.
Le prochain outil similaire sera de générer une liste automatique des contributrices pour chaque dépôt et de les concaténer dans le client quelque part pour pouvoir les afficher dans les crédits. Je vais partir pour cela de mon plugin Blender car avec la gestion des assets désormais bien intégrée, il est possible de mettre pas mal de métadonnées sur un objet, du genre copyright, licence et même plein de tags. Selon ce que je pourrais générer comme type de sortie depuis Blender, je proposerai un format de données pour contenir la liste des contributions et des contributrices (il y a de fortes chances que ce soit du json, ça se manipule bien avec python, et donc l'API Blender). Toutefois c'est bien moins pressant que les Changelogs, qui avaient besoin d'être propres depuis le début si on veut être lisibles. Donc je vais (enfin) me remettre à la 3D pour Khanat avant tout
Lyne
J'ai relancé pour l'article de blog sur l'AG
Je vais pouvoir le publier cette semaine, j'espère
Zatalyz
De mon coté une tentative de mise à jour des wikis mais y'a plein de trucs qui ne vont pas alors... ça sera quand les plugins seront mis à jour ou que j'ai le temps de débuguer
Et aussi j'ai bien progressé dans mon apprentissage du mail ; le moment où je pourrait migrer celui de Khaganat approche. Je n'ai pas trop d'inquiétude pour celui-là car on est surtout en mode "réception"
Et ça, je sais recevoir des mails à présent
YannK
J'ai enfin terminé l'outil de génération automatique des Changelog : https://framagit.org/YannKervran/Bareto C'est du BASH car je déteste faire de la maintenance et qu'avec de tels scripts, il n'y en a que très peu
Il est conçu surtout pour servir dans le cadre d'une CI, afin de noter et organiser les Changelog des Merge Request sur le dépôt principal, mais les scripts fonctionnent aussi en local si certaines veulent les utiliser pour leurs besoins propres.
Un exemple de Changelog un peu long ainsi généré : https://framagit.org/YannKervran/Bareto/-/blob/main/CHANGELOG.md
Ça nous permettra d'avoir la liste des contributions bien propres pour les différents projets. Et une Release note facile à rédiger car toute prête
Il me reste à intégrer des explications dans le Guide du Développement pour expliquer la façon dont cela fonctionne un peu plus en détail pour notre fonctionnement au sein de Khanat.
Le prochain outil similaire sera de générer une liste automatique des contributrices pour chaque dépôt et de les concaténer dans le client quelque part pour pouvoir les afficher dans les crédits. Je vais partir pour cela de mon plugin Blender car avec la gestion des assets désormais bien intégrée, il est possible de mettre pas mal de métadonnées sur un objet, du genre copyright, licence et même plein de tags. Selon ce que je pourrais générer comme type de sortie depuis Blender, je proposerai un format de données pour contenir la liste des contributions et des contributrices (il y a de fortes chances que ce soit du json, ça se manipule bien avec python, et donc l'API Blender). Toutefois c'est bien moins pressant que les Changelogs, qui avaient besoin d'être propres depuis le début si on veut être lisibles. Donc je vais (enfin) me remettre à la 3D pour Khanat avant tout
Lyne
J'ai relancé pour l'article de blog sur l'AG
Je vais pouvoir le publier cette semaine, j'espère
