[Deyonara]

Voilà... j'avoue ne pas avoir beaucoup cherché, mais je cherche à savoir qui pourrait, ou bien où pourrais-je, me renseigner sur les différents systèmes de persistance externes.

- Quels sont les avantages par rapport aux objets non-droppables (à part le fait, bien sûr, qu'il n'encombreront pas l'inventaire)

- Un comparatif petit mais explicite sur : la performance, la facilité d'utilisation, et la fiabilité

Merci d'avance, et pardon d'avance pour les messages du type : "Il y a déjà un post là dessus si tu cherchais un peu mieux"

[Azmathiel]

Je vais exposer ce que je pense objectivement des systèmes que j'utilise moi :

A) La persistance individuelle par objet non droppable :


Avantages :

- le plus gros de ses avantages est sa simplicité extrême
- ultra-léger coté charge système et gestion :
Il permet d'accéder à toutes les variables concernant un PJ depuis n'importe quel script sans avoir besoin de consulter une foule de fichiers. Pas besoin du tout de base de données quelconque. Pas de tables.
En cas hypothétique d'échange entre des "mondes" différents, pas besoin de système tarabiscoté de transfert de tables. L'objet est dans l'inventaire et le servervault partagé suffit pour accéder aux données concernant le PJ.
- toujours accessible en jeu quand le personnage est connecté
- sauvegarde automatique en cas de déconnexion du personnage (avec l'inventaire)
- se gère comme les variables locales. Donc sans aucune difficulté.
- Légèreté de la sauvegarde du personnage. (Un simple appel à une fonction d'export suffit)
- Suffit à vérifier par la seule présence de l'objet si un personnage est "légal" ou pas sur le serveur
- fiabilité totale
- Persistance sauvegardée par sauvegarde du servervault en même temps que les personnages. Ce qui fait un gain de temps et de place assez conséquent.


Inconvénients :

- n'est pas accessible quand le PJ n'est pas connecté (personnellement, je n'en ai pas besoin mais ça peut influencer un choix)
- nécessite (comme tous les systèmes) des sauvegardes régulières du personnage pour prévoir d'éventuels plantages du serveur (mais là, il a sa légèreté pour lui).



B) La base Bioware :

Avantages :

- Facilité d'accès par script
- Documentation
- Standard à tous les modules
- Accès extérieur au jeu aussi bien en consultation qu'en écriture.
- Rapidité relative d'écriture des variables de base (int, string, float)


Inconvénients :

- Lenteur épouvantable et insupportable en écriture d'objets dans les tables
- Nécessite de compresser les tables manuellement avec un utilitaire fourni
- sa lenteur impose une limitation d'utilisation à des choses cruciales et si possibles très ponctuelles.
- Nécessité de sauvegarder les tables régulièrement en plus du servervault.
- foutoir rapidement installé dans le répertoire des tables.

Note : étant donné que je ne l'utilise que pour un système de banque dépôt/retrait et que ce système n'est pas encore accessible à mes joueurs, je n'ai encore aucun retour sur la fiabilité.

A n'utiliser, à mon avis, qu'en complément d'un système de persistance par objet.



C'est à peu près tout ce que je vois comme choses à dire sur ces systèmes.


[EDIT pour rajout :]

Pourquoi n'ai-je pas utilisé d'autres systèmes comme NWNX par exemple ?

Question de choix personnel.
Les arguments que je me suis trouvés pour me dissuader de tenter l'aventure :

Ces systèmes ne sont pas standard et demandent le rajout de surcouche(s) à un système déjà bien chargé.
Nécessité d'apprendre des choses en plus pour maîtriser leur déploiement. (SQL par exemple)
En cas de problème, on peut toujours courir pour attendre des mises à jour ou des corrections. Ces systèmes reposent sur le bon vouloir de "volontaires" et une fois qu'ils ont disparu du circuit, on peut se brosser. En cas de bug, ou de soucis, personne vers qui se tourner. Pas de support.
Pas plus légers que ce qui existe en standard et sûrement pas plus simples à utiliser.
Leurs seuls avantages me paraissent être la possibilité d'utilisation à l'extérieur du jeu et une rapidité plus soutenue que les tables Bioware.

[Mickey974]

NWNX2

AVANTAGE
> Aucun problème à déplorer lors de l'utilisation de NWNX, ni en terme de perte de données, ni de Maj, ni d'informations que l'on peut obtenir sur le forum officiel de bioware ou celui d'Avlis. Il y a des Maj régulières. J'utilise NWNX depuis la première version et j'ai suivit toutes les versions et je dois dire que de ce coté il y a un excellent support.
> Requêtes hiérarchisées. Tri. Requêtes multicritères.
> Interconnection de la base de données avec des pluggins pour aider NWNServer dans certains calculs.
> Interconnexion de la base de données avec du PHP/ASP pour des interventions direct via site web.
> Pas moins rapide (malgré certains dires) que d'autres systèmes de persistances.
> Super stable
> Open source permettant d'auto maintenir le logiciel en cas de défaillance des éditeurs.

INCONVENIENT
> Installation manuelle de NWNX ainsi que de la liaison ODBC indispensable pour se connecter à une base de données du type MySQL, SQL server ou Access.
> L'utilisation de NWNX n'est pas à la portée de tout le monde car il faut maîtriser l'aspect relationnel des bases de données ainsi que le SQL.

[Biboule]

J'ajouterai un inconvénient sur la gestion de la persistance par objet non droppable : Pas de sauvegarde possible sur l'objet lors de l'évènement OnClientLeave (Les GetLocalXXX fonctionnent parfaitement mais pas les SetLocalXXX ). Ceci peut-être utile pour la sauvegarde des points de vie lors de la déconnexion par exemple. Personnellement j'utilise un système combiné de Base de Donnees Bioware (pour les points de vie) et d'objet non droppable (pour tout le reste : faction, localisation, quête ...).

Petite question au passage, j'avais lu a l'époque que les items de créatures (Peau en l'occurrence) n'étaient pas sauvegardées avec le personnage, est ce toujours vrai ? Car j'utilise ce système et je n'ai pas rencontre de soucis pour l'instant. Cela évite les HasItem ou GetItemPossessedBy (surtout quand l'inventaire du PJ est surcharge ), juste un GetItemInSlot qui je pense est moins coûteux au niveau des ressources et ne gaspille pas de place dans l'inventaire du joueur.

[Zyzko]

La base de données bioware est fiable certes limitée par rapport a mysql, mais fiable. Je n'ai jamais perdu de données ou rencontré une quelquonque corruption.

L'utiliser pour gérer les quetes via des commandes Set/GetCampaign & co est simple et ne pause pas de problèmes.

A toi par contre de bien architecturer ta base pour éviter des tables qui font des km. Pense aussi par exemple aux joueurs qui vont créer un 2e perso sous le meme nom, pas forcement le meme account etc.

[Azmathiel]

Citation :

Publié par Deyonara

Merci d'avance, et pardon d'avance pour les messages du type : "Il y a déjà un post là dessus si tu cherchais un peu mieux"

Si ça peut te rassurer, le dernier fil traitant de ce sujet a plus d'un an d'âge et parlait encore de systèmes pré-SoU, datant donc d'avant la sortie officielle du système de tables Bioware. Je pense que ce n'est pas un mal d'en refaire un avec les dernières connaissances et le recul suffisant des utilisateurs.

@mickey :
N'oublie pas que les gens ici ne sont pas des geeks ou ingénieurs en informatique capables de maintenir un système développé par un tiers. Ce sont avant tout des passionnés de jeu de rôle. Et de ce côté, moins on perd de temps avec des trucs inutilement complexes, plus on avance vite sur son projet et moins on se disperse. Déjà en procédant comme ça, j'ai mis personnellement plus d'un an à arriver où j'en suis et je n'ai pas chômé...
Ce que tu qualifies d'avantages en parlant de maintenabilité, je range ça dans les inconvénients en me disant "En plus, va falloir que je me paluche ce qui ne va pas ou qui n'est pas à mon goût dans ce système (PUMA, NWNX, etc)". Donc, éjection sans appel de mon bac à sable de tous les trucs "exotiques". Après, c'est à chacun de voir ce qui lui convient le mieux et les objectifs qu'il s'est fixé.

@Biboule :
Rien de standard, à ma connaissance, ne permet de récupérer toutes les valeurs affectées à un PJ en cours de déconnexion. Mais de toute façon, récupérer ces valeurs, quelles qu'elles soient, à la déconnexion ne résout en rien le problème des plantages serveur. La seule façon d'avoir un système fiable de sauvegarde est de faire des sauvegardes régulières et répétées. Et plus elles seront rapprochées, plus ton delta d'erreurs sera faible et le retour en arrière de l'état des choses sur le serveur, peu important. C'est au développeur de se fixer sa marge acceptable d'erreur là-dessus.

@Zyzko
Oui, et penser aussi aux glands qui ont des noms de personnage genre {[\\/\/\YpJRoXXor//]} dont les caractères vont semer la merde dans le système d'exploitation

[Mickey974]

Citation :

Et de ce côté, moins on perd de temps avec des trucs inutilement complexes, plus on avance vite sur son projet et moins on se disperse

Ne généralisons pas. Pas parce que toi tu n'aimes pas qu'il faut tout de suite qualifier cela "d'inutilement complexe". Tout ce qu'on peut faire avec NWNX2, tu ne le fera jamais avec les variables locales semi persistantes tels que tu les utilises. C'est bien dommage pour toi ! Enfin c'est ton choix. De plus, utiliser NWNX2 te permet un gain de temps faramineux puisque tu n'a plus de question à te poser concernant "un réinventage d'une roue carré" .

1 - Moi je ne trouve pas ca inutile
2 - Et encore moins complexe

Je dirai plutôt utilement facile ... ... au vue du nombre de serveur qui utilise NWNX2.

[Deyonara]

Et bien , tu as l'air calé là dessus, mon cher Mickey974... et je me demandais... si tu ne pouvais pas me donner un coup de pouce pour tenter une timide approche vers NWNX2, vu que moi aussi je suis militante, mais pour la cause des vraies quiches en systèmes externe de persistance (avec des lardons en vrai lard dedans)*.


* Expression revendiquée par Camelia d'Oriel, qui détient tous les droits d'auteur sur cette signature, je tiens à le préciser, avant l'instauration de tout malentendu.

[PinMaster]

Moi je suis totalement pour un système de base de données externe comme le MySQL. Donc pour NWNX2 ...
Pas besoin d'avoir fait d'énormes études pour faire du MySQL... certes certaines requêtes ne seront pas optimal. Mais si l'individu suit bien les conseils que l'on peut trouver sur la toile, il devrait arriver à comprendre comment cela marche. En plus il existe des systèmes tout fait comme le FastFrench... et celui qui ne connais pas le MySQL mais comprend bien les script de nwn, il tirera son épingle du jeu.

Bref, moi je suis pour ce genre de système car il offre beaucoup d'avantage côté persistance et ouvre des possibilités immense pour le bonheur des joueurs (comme une gestion totale du contenu d'une biblio avec des bouquins créer par des PJ, système de mon cru présent sur un serveur en dev).

Sinon, j'ai pu constaté l'avantage offerte encore bien plus en apportant une amélioration du BBS (Bulletin Board System) qui travaille avec la bd de bio... et j'ai fait le portage pour NWNX2... et franchement il est plus rapide et plus maléable.

A bientôt
Le Pin qui passe de temps à autres.

[Garrath]

Chaque system a son avantage et son inconvenient... on en a deja discute a plusieurs reprises.
Par contre pour ce qui concerne un system avec une base de donnée externe type MySQL, Acces ou autre y a un avantage que l'on ne retrouve pas facilement ni avec des constantes sur des objets d'inventaire, ni avec la bd de bioware.
On peut faire des choses que tu ne peux pas faire par l'exterieure. Ex : un PNJ qui raconterai ce qui se passe dans le monde au fur et à mesure. C-a-d qu'on lui rentre un dialogue dynamique que l'on modifie en base. je vois pas comment le faire avec la Bd de bioware...

Donc le truc c'est de prendre l'outil le mieux adapte a son besoin et a ce que l'on veut faire.
Les constantes sur des objets d'invenataire c'est super pour stocker des donnees directement liées à un PJ, genre la localisation, le nombre de PV, les sorts utilisés etc...
La bd de bioware est parfaite pour d'autre truc (elle permet de svg un objet completement a priori...) mais bon moi j'avoue que je l'utilise pas du tout...
Une Bd exterieure a de nombreux avantages ...

A savoir aussi que si tu utilises MySQL, le mieux et le plus simple c'est NWNX-FF. C'est compatible avec APS-NWNX mais surtout l'avantage c'est que tu passes par ODBC (c'est vachement moins chiant a installer, et c'est plus rapide). Seul hic c'est que c'est specialisé MySQL et que en plus cela ne tourne que sous Windows...

[Mickey974]

D

Citation :

et je me demandais... si tu ne pouvais pas me donner un coup de pouce pour tenter une timide approche vers NWNX2

Demander aussi gentiment, ca sera avec plaisir !

Citation :

vu que moi aussi je suis militante, mais pour la cause des vraies quiches en systèmes externe de persistance (avec des lardons en vrai lard dedans)*.

lol ! On est tous quelque part sur un sujet, de vraies tartes à la crème ! Durant ma courte existence, je n'ai rencontré personne de parfait ! (Ceci dit je ne désespère pas d'en rencontrer un, un jour !)

[Azmathiel]

Citation :

Publié par Garrath

Chaque system a son avantage et son inconvenient... on en a deja discute a plusieurs reprises.
Par contre pour ce qui concerne un system avec une base de donnée externe type MySQL, Acces ou autre y a un avantage que l'on ne retrouve pas facilement ni avec des constantes sur des objets d'inventaire, ni avec la bd de bioware.
On peut faire des choses que tu ne peux pas faire par l'exterieure. Ex : un PNJ qui raconterai ce qui se passe dans le monde au fur et à mesure. C-a-d qu'on lui rentre un dialogue dynamique que l'on modifie en base. je vois pas comment le faire avec la Bd de bioware...
...

Contrairement à des "c'est simple", "plein de modules l'utilisent" et une pointe de condescendance dans "C'est dommage pour toi", ça, c'est un vrai argument recevable. Mais, je ne comprends pas bien. Pourquoi faire ça en extérieur et ne pas tout simplement tenir à jour le dialogue via l'éditeur ? Je pourrais reprendre le même exemple pour la bibliothèque citée plus haut. Ca change quoi de copier le texte dans une table plutôt que de le coller directement soit dans un dialogue, soit dans la description ?

Je suppose qu'il y a d'autres arguments plaidant en faveur d'un système externe, non ?

[Sherazade]

En ce qui me concerne, l'argument de poids qui a fait que je suis passée à NwN-MySQL est la possibilité d'agir de l'extérieur de NwN et de ne pas avoir besoin d'avoir untel de connecté pour connaître certaines de ses caractéristiques (artisanat, réputations de factions, etc...), très utile aussi pour régler certains bugs.

De plus, il est aussi possible, via MySQL, de maintenir une page web donnant des informations comme les meilleurs artisans, les petites annonces en cours, etc... Bon hmmm... je n'ai pas encore mis ne pratique ce dernier point, mais j'y songerai en 2012 quand j'aurais un peu plus de temps .

Et Deyonara, je crois t'avoir vu passer sur notre serveur, n'hésite pas à poser des questions si nécessaire .

[Mickey974]

C'est pas dans mon habitude d'être condescendant ! Désolé que tu l'interprètes ainsi.

Ceci dit je vais t'expliquer ce que tu peux faire grâce à une base de données au niveau des dialogues que tu ne pourra jamais faire avec des variables, où alors en plombant ta mémoire.

J'ai créer un PNJ dans mon module qui raconte des blagues. A chaque fois qu'il détecte un PJ, il se précipite sur lui et lui sort une vanne (plus ou moins scabreuse ca dépend des actions passées du PJ en question). Cette vanne est tirée aléatoirement dans une table que j'alimente régulièrement par de nouvelles blagues. Je n'ai qu'une constante (1 seule) à modifier qui est le nombre de vannes que le PNJ peut dire. Il y a un seul dialogue. Un seul script et une seule requête.

Pour faire la même chose sans bd, il te faudrait scripter le nombre de dialogue que j'ai pour ma constante, faire un pre dialogue directif qui appellerait un dialogue tiré en aléatoire et qui permettrait au PNJ de lancé une blague. Mais là, il ne pourrait pas ajuster la blague en fonction du passif du PJ. Ou alors, mettre 1000 variables sur le PJ qui raconte l'historique de ses actions passées. Bref. Mieux vaut une BD !

[Sherazade]

Tiens, j'ai un bouffon qui fait la même chose sur mon serveur, mais pas besoin de DB externe pour les blagues, elles sont juste stockées dans une librairie à cet effet, et je n'ai que deux scripts pour gérer l'affaire. Un initialisant la DB interne et un tirant aléatoirement la blague et la collant dans le dialogue.

Cela dit, j'aurai aussi pu mettre ça dans une DB externe, mais je n'en ai pas vu l'utilité.

Par contre, pourrais-tu développer sur le "en fonction du passé du PC" ? Si la blague est définie en fonction du passé du PC, tu dois bien avoir besoin de stocker des variables locales au PC, non ?

[Deyonara]

Merci pour ces précieuses infos, mais... sinon... y a-t-il d'autres systèmes de persistance qui mériteraient un coup d'oeil ?

[Nek]

Citation :

J'ai créer un PNJ dans mon module qui raconte des blagues. A chaque fois qu'il détecte un PJ, il se précipite sur lui et lui sort une vanne (plus ou moins scabreuse ca dépend des actions passées du PJ en question). Cette vanne est tirée aléatoirement dans une table que j'alimente régulièrement par de nouvelles blagues. Je n'ai qu'une constante (1 seule) à modifier qui est le nombre de vannes que le PNJ peut dire. Il y a un seul dialogue. Un seul script et une seule requête.

Quelle utilité de faire appel à une base externe ??

Tu gères ça en script avec un switch/case où tu peux ajouter tes nouvelles vannes en incrémentant le random, c'est tout à fait faisable sans BD....

Et qu'on ne vienne pas me dire qu'une lecture MySQL est plus rapide qu'une affectation de variable string dans switch/case hein, parce que là je frappe

[Mickey974]

Soyons sérieux. J'ai une tonne de texte, (environ 500 vannes qui sont plutôt longues que courtes) et vous souhaitez gérer ca par switch case dans un dialogue ? Bah moi je vois l'utilité de mettre ca dans une table !

1 - Mise à jour extrêmement aisée.
2 - Pas besoin de recompiler chaque fois qu'une vanne change, ou qu'on en rajoute.
3 - Possibilitée que ce soit les joueurs qui intègre leur propre vanne, sans recompilation aucune

Quand à l'argument rapidité ... je suis pas sur de comprendre ou tu veux pécher un gain de temps ? A l'ouverture d'un dialogue ... Je suis certain qu'avec ma requête et mon petit script mon dialogue s'affichera aussi rapidement que le tien. Pourquoi parce que l'ODCD est une couche qui est optimisée par des années de programmeurs qui ont bossé dessus et qu'une requête sur un critère tel qu'un numéro d'enregistrement ne tuera pas le serveur et s'exécutera très rapidement. De plus, ton script à toi devra lire un fichier de constante dans lequel tu aura enregistré au préalable tous tes textes, ou pire, tu aura fait un gros dialogue, qui va mettre un temps fou à se charger et à se transmettre au joueur.

Bref, la base de données est un outil indispensable. En tout cas pour moi et pour beaucoup.

[Azmathiel]

Ben euh... sans vouloir jouer les emmerdeurs :

vanne1 = dialogue avec vanne n°1
etc

vanne500 = dialogue avec vanne n°500

Code PHP:

// Def des objets utilisés PJ, PNJ avant d'utiliser ça, donc tout au plus deux lignes
int NumVanne = Random(500) + 1
AssignCommand(ObjetPNJ, ActionStartConversation(ObjetPJ, "vanne" + IntToString(NumVanne), TRUE, FALSE)); 

Je ne vois pas où le script ferait deux mille "case". Et je ne comprends toujours pas la différence d'accès entre une table, et le fait d'éditer ça avec Aurora. 'Scusez moi, mais je suis un peu lent pour un humain

[Sherazade]

Personnellement, je gère ça comme Azmathiel, pas de gros dialogue, pas de gros scripts avec des switch, juste quelques lignes de scripts comme il le montre si bien...

[Mickey974]

donc il me faudrait 500 dialogues numéroté de 1 a 500. Pour 10, je veux bien... mais après c'est une perte de place et de temps totale.

De plus si une maj est nécessaire, faut aller rechercher le bon dialogue contenant la vanne que l'on doit mettre à jour (correction orthographique par exemple). C'est pas gagné!

Comment faites vous pour savoir quel dialogue ouvrir ?

[PinMaster]

Certe on peut ce passer de base de donnée externe....
Mais pour le cas de la biblio que j'ai cité, tu es très loin du compte...

En fait c'est une biblio totalement dynamique. Où les pjs viennent écrire leur récit. Ce récit est ensuite valider par un MD en ligne. Il faut savoir que la biblio fait appel à un autre système de récompense en différé. C'est à dire que si le PJs n'est pas présent lorsque le MD valide le récit. Il sera récompensé pour cette preuve de RP à sa connexion.
Il faut aussi savoir que les DMs sont averti à leur connexion de la présence de bouquin à valider.
Bref cette biblio reste en soit une véritable biblio, car des livres peuvent apparaître à n'importe quel moment... et sans reboot du serveur pour y ajouter un livre.

Et ce n'est que la première version de la biblio...
A ne pas mettre dans le même panier qu'une variation de dialogue, car ma biblio est totalement dynamique et persistante.

Bref avec une BD externe comme MySQL, les possibilités de persistances et de dynamisme sont largement accrues. A mon goût.

[Azmathiel]

Et ben on va finir par y arriver à savoir où se cache ce petit plus.
Dans ce système, je fais confiance à ma mémoire et j'adapte ma nomenclature de textes/objets/dialogues.
(Oui, j'utilise aussi un système de dialogue aléatoire avec des PNJ de rencontre, mais pas 500 différents non plus, hein, faut pas déconner ! )

Donc, je te retourne la question, avec une base extérieure, tu fais comment pour identifier quel est le texte à éditer/corriger ? Tu passes tout à la moulinette en mettant le texte à rechercher dans tes requêtes ? Et ça marche aussi avec des approximations de texte (dans le cas que tu cites pour les fautes, par exemple) ?

Edit :
@PinMaster
Loin de moi l'idée de vouloir enlever à ton mérite d'avoir imaginé un système performant, mais on peut faire exactement pareil avec un forum, puis recopier les livres à la main. CTRL-C, CTRL-V.
Par contre, chapeau si tes PJ jouent le jeu, parce que là, c'est nettement plus dur d'avoir des joueurs participant à ce genre d'exercice que de mettre au point la technique le gérant... Et j'en sais quelque chose, j'ai tenté ça sur un serveur de jeu il y a un bon moment...

[Sherazade]

Citation :

Publié par Mickey974

donc il me faudrait 500 dialogues numéroté de 1 a 500. Pour 10, je veux bien... mais après c'est une perte de place et de temps totale.

Non, un seul dialogue avec des tokens.

Citation :

De plus si une maj est nécessaire, faut aller rechercher le bon dialogue contenant la vanne que l'on doit mettre à jour (correction orthographique par exemple). C'est pas gagné!

Euhhh... ben le problème est le même quel que soit le moyen de stockage. Tu as 500 données, il faut les gérer (ajouter, éditer, supprimer, etc...), que ce soit dans une DB externe ou dans une librairie NwN-script, le problème est le même. Je ne vois pas ce qu'apporte de plus une DB externe mis à part en effet si les personnages peuvent ajouter dynamiquement leurs propres blagues. Dans ce cas là, oui je suis bien d'accord avec toi, sinon, non je ne suis pas d'accord sur la nécessité absolue d'une DB externe.

[PinMaster]

L'utilisation d'une BD externe doit ce faire de manière réfléchi... avoir une BD externe pour gérer des dialogues pour un PNJ... bonjour l'usine à gaz. Il en va de même pour la BD de bioware (quoiqu'avec elle, ce serait pire qu'une usine à gaz).

Citation :

Publié par Azmathiel

Loin de moi l'idée de vouloir enlever à ton mérite d'avoir imaginé un système performant, mais on peut faire exactement pareil avec un forum, puis recopier les livres à la main. CTRL-C, CTRL-V.

Oui mais ta méthode demandera de créer en dur les bouquins dans aurora puis de redémarrer le serveur pour les voir apparaître.
La mienne pas besoin et en plus on pourrait très bien envisager de créer un lien avec le forum surtout s'il utilise une BD MySQL. Bref cette option se fera sans doute à l'ouverture du serveur et après création du dit forum... (purée pas encore fini moi avec Pandorn)

Voilou, a bientôt