A propos des quetes

[Tienos]

Bonjour,

depuis quelques jours je me ballade sur le forum et dans les codes source du projet histoire d'en observer un peu les tenants et aboutissants. D'une vision extérieure comme la mienne je trouve relativement bizarre la façon de procéder. Chacun y va de sa database, patch, script. A l'arrivé je me retrouve un peu perdu et ai la sensation que ça part un peu dans tous les sens.
Enfin je ne suis pas là pour juger. Je voulais juste donner ma sensation.

Le but de ce post était à la base de savoir si vous vouliez un coup de main pour les quetes, ML, artefact ?
J'ai vu que peu de quetes ont été insérée.
Ou peut etre autre chose : c'est vous qui savez qu'il vous manque comme tacheron
Ou peut etre faire un peu de ménage sur le forum.

Enfin voila
Mon post a changé par rapport a ce que je voulais mettre au début
Donc si besoin d'un coup de pouce je traine dans le coin.

PS : Je prefere en parler ici plutot que de me chercher une mission en me baladant dans le code. J'aime pas tourner sans but ^^

NB : Ce post pouvant etre mal perçu
Je ne cherche pas à etre prétencieux. Juste à savoir si je pouvais etre utile à quelquechose.

[Leodagan]

Les quêtes n'ont plus pour but d'être programmées

Le mieux serait d'essayer de basculer une grande partie des quêtes présentes sous forme de scripts vers des quêtes de type "DataQuest" qui sont paramétrables entièrement en base de données...

Le problème des quêtes "DataQuest" c'est qu'elles ne peuvent pas être autonomes comme une quête codée (en fait c'est même le but recherché !)

Du coup si tu propose des mise à jour de base de données pour les DataQuest, il ne faut pas oublier d'y adjoindre les enregistrements nécessaire dans ItemTemplate, Mob ou encore NPCTemplate (avec éventuellement les enregistrements de d'habillage et de liste de marchand, j'ai un peu zappé les noms...) pour faire apparaitre correctement les NPC/Mob et Récompenses...

Il faut souvent se débarrasser de clé "primaire" dans les exports de base de donnée pour ne pas empiéter sur les enregistrements déjà présents dans la base d'un utilisateur

je te rejoint sur le coté "Bazar", mais le projet DOL n'a pas pour but de proposer du contenu pour les Shards mais un "moteur", après je dois admettre que j'ai participé moi-même (ainsi que beaucoup d'autres) à transformer un maximum de "module" codé directement dans DOL vers des genre de "loader" qui établissent le comportement du jeu en fonction des données en base (DataQuest, Battlegrounds, Data Career)

Du coup beaucoup de ces évolutions n'ont pas eu tout "l'amour" nécessaire à faciliter la distribution des données en base qui reproduise un comportement initial (du coup il y a un peu une "perte" pour ceux qui n'ont pas suivi les mises à jour en question et ne retrouvent pas les données nécessaires sur le forum...)

Livrer de la "donnée" n'a rien a voir avec la distribution d'un code source, il n'y a jamais eu de projet vraiment spécialisé dans ce domaine autour de DOL, mais j'ai toujours cru comprendre que ceux qui veulent s'y coller sont les bienvenues

Pour mon point de vue perso, il est très difficile d'adapter un projet basé sur de la "donnée" à la gestion communautaire, il faut des outils spécialisés qui permettent d'identifier les modifications dans une base de données, d'en faire un historique, et de proposer des patchs ou des livrables qui ne détruise pas les réglages de chaque admin, j'ai cherché vite fait mais c'est pas ma spécialité, en l'absence d'un tel outil j'ai peur que le travail "en communauté" soit très difficile si ce n'est impossible ! (La plupart des projets de base de données jusque là ont été des travaux réalisé par une seule personne...)

[Tienos]

Le problème des quêtes "DataQuest" c'est qu'elles ne peuvent pas être autonomes comme une quête codée (en fait c'est même le but recherché !)

Dans quel sens? Je comprends pas trop le but recherché dont tu parles.

J''avais mal compris/mal lu le projet je pense. Comme tu indiques c'est le contenant qui vous interesse et non le contenu. Je croyais que vous montiez un daoc-like. ^^'

Méa culpa

[Eudes]

Bonsoir Tienos,

Peut-être pourrais-tu décrire, même brièvement ce que tu peux proposer comme compétences dans le projet DOL (ou pour n'importe quel serveur finalement) car les domaines sont nombreux et il est difficile de t'orienter sans savoir ce que tu pourrais techniquement apporter à un projet.

Bonne soirée et bon DAoC

[snoopydo]

Bonsoir tienos,

j'ai du boulot pour toi si tu veux !

mon skype est bouba421@hotmail.be

[Leodagan]

Le problème des quêtes "DataQuest" c'est qu'elles ne peuvent pas être autonomes comme une quête codée (en fait c'est même le but recherché !)

Dans quel sens? Je comprends pas trop le but recherché dont tu parles.

J''avais mal compris/mal lu le projet je pense. Comme tu indiques c'est le contenant qui vous interesse et non le contenu. Je croyais que vous montiez un daoc-like. ^^'

Méa culpa

Pour les DataQuest :

La Table DataQuest doit référencer des éléments pré-existants (Mob, et Item de Quête ou Item de Récompenses) ce qui permet plus de souplesse en n'utilisant pas de scripts qui créent leurs objets n'importe comment (comme les quêtes de gameserverscript...), par contre la création des enregistrements annexes revient à la charge du "gestionnaire de contenu" (qui peut aussi ne pas nécessiter de création si la quête s'appuie sur des Mobs/Items déjà existants dans sa base de données, ou des version customisées de ces derniers sans modifier le code de la quête...)

Jusque là beaucoup de quêtes scriptées initialisent leur propre NPC et leur propres Items pour ne pas tomber sur des références null, certaines quêtes se permettent d'enregistrer ces objets dans la base de données sans "obéir" aux paramètres du serveur (qui propose d'enregistrer les items manquant ou non), en mode debug cela provoque une duplication à chaque démarrage, car les quêtes peuvent chercher leurs objets dans les "collections" du serveur alors que ce dernier à reçu une configuration qui le force à réduire les zones chargées...

Donc les DataQuest permettent de s'appuyer sur "l'existant" et ne fourni pas de méthode de création automatique pour laisser le soin à l'administrateur de pointer ses propres enregistrements... (et ne pas reproduire les bugs de fonctionnement des anciens scripts... qui franchement peuvent être fatals pour un serveur en production !)


Au sujet d'un projet orienté "Donnée" :

Franchement tu imagines bien qu'un contenant sans contenus n'a que peu d'intérêt, c'est bien la raison pour laquelle il y a une section dédié du forum pour ceux qui veulent publier leur base de données, ou même intervenir sur la base de données publique pour proposer des mises à jour...

Mais le projet "Public DB" est dissocié du projet "DOL", il est peu maintenu, il a finalement attiré peu de contributeurs et sa méthode de distribution ne permet pas d'intégrer facilement des mises à jour pour ceux qui ont un "shard" qui tourne déjà bien...

...Ni d'y apporter facilement des modification d'ailleurs, vu qu'il est assez utopique d’espérer faire un export SQL incrémental (à moins de bien séparer chaque table, et d'utiliser un tri prédéfini peut être... enfin c'est encore du travail sur un projet qui n'est pas "DOL")

La maitrise du SQL parmi les contributeurs du projet "moteur" est assez approximative en général et l'organisation du travail nécessite d'y apporter un soin particulier, donc voilà ça n'est surtout pas maintenu par ce que ça demande des compétences spécifiques et que la collaboration est très difficile sans outils approprié (SVN n'est pas du tout adapté à ça !)

Donc les contributions DB sont bienvenues sous toutes leur formes dans la partie Base de données, mais il faudra trouver des volontaires par toi même pour même du propre dans ce bazar, et (re)construire un projet autour de la base de donnée (Et si je dis ça c'est que j'ai moi même tenté l’expérience en publiant la version PublicDB 3.1a qui de mon avis n'est pas la meilleure... et j'ai galéré pour un résultat médiocre !)

Une bonne Update de la PublicDB pourrait être nécessaire afin d'inclure les dernières mises à jour qui bascule du "code" en "données", mais il n'y a absolument personne qui encadre ce projet, donc c'est pas comme si on pouvait t'indiquer une marche à suivre, si ce type de projet t'intéresse tu as toute liberté de mettre tes propositions en actions sans aucune contraintes hiérarchique

Bien sur comme le dis Eudes, ce n'est pas imposé, si tu peux apporter tes compétences dans le domaine de "DOL" (donc du moteur) il y aura plus de facilité à t'indiquer des composants qui nécessitent des améliorations (vu que là il y a encore des contributeurs et un encadrement )

[Graveen]

Salut Tienos,

Leodagan résume bien. DOL est d'abord un moteur qui permet la création de contenu, mais sans distribuer lui même ce contenu.
En réalité, c'était une mission annexe au départ, mais elle ne l'est plus, car cela necessite une organisation draconienne et un suivi trés régulier... La base de donnée fournie est à prendre comme un showroom.

Ceci dit, les mises à jour de données sont appréciées. Elles sont incluses dans la mesure du possible (cf PublicDB 3.1 de Leodagan qui est un sôcle), mais les bribes éparses manquent de cohérences.

Je vais mettre à jour le post 'Most Wanted', et si tu souhaites t'investir, nous n'arrivons déjà pas à couvrir les nouveautés de BroadSword (support 1.109+, forts NNF avec dynamic lightning, siegecraft, classes, et nouveau DF qui va certainement apparaitre tout blanc !). Côté contenu, effectivement, migrer toutes les quetes scriptées en DQ serait pas mal, même si j'y vois peu d'impact dans la lisibilité du code (elles peuvent etre externalisées de la partie GameServer et l'ancien système sera sans doute toujours nécessaire).

Enfin il y a le dev des outils. J'ai en cours et pas si mal avancé un DQ creator, mais un Mob creator ou un Path designer (et les fixes qui vont avec si ces projets existent) peuvent aider enormément s'ils sont cohérents avec DOL (par exemple, ils utilisent les templates et permettent de les concevoir, etc...)