Bonsoir à tous !
Je suis en train de travailler avec quelques amis sur un module persistant. Jusque là, je n'ai jamais réalisé que des modules soli.
Or, en lisant divers posts sur plusieurs forums, j'ai compris qu'il y avait une grosse différence entre les deux, notement en ce qui concernait l'enregistrement des variables sur les joueurs.
J'ai donc fait quelques recherches sur la bibliothèque, et j'ai trouvé certains posts, assez anciens sur différents aspects du sujet, mais aucun qui ne m'ait satisfait vraiment.


Il semblerait qu'il y ait plusieurs possibilités :

1) Les variables doivent être enregistrées sur un objet de l'inventaire du joueur. Cela impliquerait de faire pour tous les scripts de dialogue par exemple à la place du
un


Arrêtez-moi si je me trompe !

On m'a dit par ailleurs que l'on ne pouvait pas mettre plus de 20 variables sur un objet. (Personnellement je trouve ça plutôt étrange) Est-ce vrai ?

2) Utiliser la base de données de Bioware SetCampaignInt(.....) etc... : d'après ce que j'ai lu, là aussi, cela est assez lent (lag ?) et peu pratique (Mais en quoi ?). Et deviendrait vite assez lourd !

3) Utiliser un logiciel externe, comme PUMA (assez ancien ma samble-t-il), NWNX 2, ou NWN-FF ( basé, tout comme le précédent sur le système MySQL, si j'ai bien tout suivi ! )

Avec l'expérience que certaines personnes ont acquise en utilisant ces méthodes :
- Lequel de ces trois systèmes est-il le plus pratique ?
- Avez-vous éprouvé les limites de l'un ou l'autre ?

Bref, que pouvez-vous me conseiller et pourquoi ?

Merci par avance !

Enki a écrit :Bonsoir ^^


Enki a écrit :En général on enregistre plutôt avec un objet persistant dans l'inventaire (genre livre des règles, pierre de vie, etc).


Enki a écrit :On en entend beaucoup dire à propos de la limitation, moi j'avais entendu 100 car à partir de là ça pouvait générer du lag, mais je pense que ça depend de beaucoup de choses.


Enki a écrit :Lente, peu efficace et lourde. Si tu n'as pas besoin de faire beaucoups d'accès je trouve ça idéal combiné à des variables locales.


Enki a écrit :Meilleur mais necessite d'installer différents logiciels, je pense pour une plus haute utilisation.



Enki a écrit :Les limites des variables locales sont leur nombres, on peut facilement le détourner.
Les limites de la DBBio sont clairement expliquées plus haut.
MySQL a des limites très éloignés ^^ (et il permet de grande flexibilités nottament niveau changement en direct).


Enki a écrit :Je pense que pour le choix c'est plus par rapport à ton profil d'utilisation, si tu fait des systèmes de script avec de fort appel à la DB, et que ton module tourne autour -> MySQL.
Pour un module "simple" la DBBio fait facilement l'affaire, mais tant que tu peux faire des variables sur objets pour éviter de l'allourdir, fait le.


Petit résumé, les pros de MySQL pourront t'en parler plus longuement.
A+
_________________
Scripts, systèmes, fonctions,... c'est par ici...
Pyjama pour castor, une vocation, un avenir sûr

SetCampaignInt(.....) devient lent, il faut rester relatif, c'est tout de même pas pour tout de suitesi tu as un bon DD et un serveur dédié. Bon si je ne m'abuse (qu'on me reprenne ou qu'on m'achève si je me trompe !) le SetCampaignInt utilise la sérialisation, bref un fichier texte pour stocker toute les infos, ce qu'il faut donc comprendre (un peu de notion informatique sa fera pas de mal pour la digestion tardive!):
La sérialisation stocke donc les infos dans un fichier sous forme de texte brut, donc il se contente à chaque nouvelle variable de rajouter une entrée dans le fichier, donc plus le nombre d'entrées augmentent plus le fichier est volumineux. Bon jusque là pas de soucis, sauf que pour trouver une variable quand on y fait appel, il faut relire tout le fichier... Je pense que vous commencez donc à comprendre le soucis. Plus le fichier est gros, plus la lecture devient longue et ainsi de suite... Vous multiplier par le nombre de comptes/joueurs/pjs différents et vous vous apercevez vite que le nombre de variablesdevient vite important d'où les ralentissements...

Après voila la différence avec une base de données (ici MySql), lorsque des infos sont stocker dns une base de données MySql (quelquesoit le nom) l'information est hierarchisé que se soit de manière volontaire (création de tables ou autre) ou pas, par défaut le logiciel organisera les données de manière à ne pas TOUT relire à chaque fois( je ne connais pas les différents systèmes de stockage, je me contente donc de notions générales aux BD). Bref cela revient à comparer un étagère avec des rayonnages et une simple caisse. Lorsqu'il y a peu de papier à ranger tout va bien avec la caisse, mais si vous devez stocker des papiers comme le ferait une administration française (attention message subliminal ici) et bien vous pouvez jeter la caisse sous peine de passer plus de temps à chercher le formulaire E511 qu'à remplir ce dernier.

Bref tout sa pour dire que dans l'absolu le système de bioware ne convient pasaux serveurs populeux ni même au monde multijoueurs permanent. Il ne faut pas perdre de vu que Nwn n'était pas prévu pour la persistence ni le multi-massif.

Dans m'espoir de vous avoir éclairer un petit peu (et surtout de pas m'être gourer quelque part )

EDIT: rhan coiffé au poto par Ivellios!

Merci pour ces précisions Ivellios. Je vais y réfléchir sérieusement !


Ivellios a écrit :Je pensais à un objet directement sur le joueur car il me semblait que c'était plus rapide (pas besoin de "scanner" tout l'inventaire du joueur ).
Je n'ai jamais testé, mais pourquoi pas l' INVENTORY_SLOT_CARMOUR ?

P.S. : Pardon pour les fautes d'orthographe du message précédent, j'étais peu attentif !

Merci encore.

EDIT :
Harmelyo a écrit :Ivellios n'est pas le seul !

Je te remercie également pour ces précisions techniques !
As-tu l'habitude d'un logiciel en particulier ?

Salut Enki

Sur les bases de données, outre qu'elle est très simple d'utilisation, la DB Bioware a (à ma connaissance, c'est aussi une question en fait...) l'avantage de permettre le stockage "réel" des objets. En gros, tous les systèmes que j'ai vu utilisant SQL enregistre les objets par leur resref, ce qui fait que les modifications (itemproperties, apparence) disparaissent lors de la récupération. Donc (à moins que je me trompe et que NWNX 2 le permette) il vaut mieux utiliser cette DB au moins pour les objets (coffres persistants).

Sinon, la DB utilisée par Bioware ne purge pas les données effacées. Donc il faut s'arranger pour :
- Ne pas multiplier les entrées.
- Quand des données ont une durée de vie temporaire, ou si tu sais qu'elle va être vide à un certain moment, créer une DB spécifique et la détruire quand elle ne sert plus. (exemple : un lot de variable & objets à charger sur le module : tu les charges, détruit la DB et tu la recrèes si besoin, c'est bourrin, mais ça gagne de la place).

Autre chose : il me semble (en tout cas ça m'a posé des problèmes...) que les objets de créature ne sont pas enregistrés sur le joueur, donc ne pense pas à stocker les infos sur une peau. (là non plus je suis pas sur de moi, mais je l'ai experimenté, je sais pas si ça vient de moi ou pas.)

Pour donner mon avis , je pense simplement qu'il n'y a pas de " bon outils " ou de " mauvais outils " , je ne pense pas que l'on puisse dire qu'il faille éviter d'utiliser ceci ou cela , mais plutôt qu'il faut utiliser l'outil adapté selon la situation et les besoins.

NWN met a ta disposition différentes commandes de script , il faut les utiliser selon les circonstances en tenant compte des points forts et faibles de chaque commande.

Par exemple :

SetLocalInt , SetLocalObject , SetLocalBidule :
Avantage : C'est rapide et pratique
Inconvénient : Ne reste pas en mémoire aprés un reboot

SetCampaignBidule :
Avantage : Ca reste en mémoire aprés un reboot
Inconvénient : Est un peu plus lent que la commande ci dessus et a chaque SetCampaignBidule nouveau , tu agrandi la taille de la base de données ( un fichier texte !!! ) qui sera a chaque fois un peu plus longue a ouvrir , modifier , et sauvegarder.

En clair , je pense que il ne faut pas systématiquement utiliser telle ou telle commande , mais savoir inteligement jongler en utilisant ce qu'il faut quand il le faut , l'idéal étant d'utiliser le plus souvent possible les variables locales " non permanentes " et de n'utiliser les variables locales " permanentes " QUE si c'est vraiment indispensable.


Citation :C'est comme si tu nous montrait une pioche , un marteau piqueur et une grosse pelleteuse et que tu nous demandais ce qui est le plus pratique !

La réponse c'est : " ça dépends "

Si tu veux planter une fleur , prends la pioche , le marteau piqueur et la peleteuse , ça marche aussi , mais ce ne sera pas adapté !

Si tu veux creuser le goudron pour réparer un tuyau sous le bitume , prends le marteau piqueur , la pioche et la peleteuse , ça marche aussi , mais ce ne sera pas adapté !

Si tu veux creuser une grosse tranchée bien longue et bien profonde , prends la pelleteuse , la pioche et le parteau piqueur , ça peut être sympa , mais juste pour galérer des heures et pour que tout le monde se foutte de toi !

Il faut l'outil adapté selon la tâche a effectuer , c'est tout !

EDIT : MDR !!!! On s'est tous jetés pour répondre comme des morts de faim !!!
_________________
" La ruse doit être employée pour faire croire que l'on est où l'on est pas, que l'on veut ce qu'on ne veut pas. " CdG
" La véritable école du Commandement est la culture générale. " CdG
" Une société prête à sacrifier un peu de liberté contre un peu de sécurité ne mérite ni l'une ni l'autre et finit par perdre les deux. " B.F
" La gloire se donne seulement à ceux qui l'ont toujours rêvée. " CdG
" La fin de l'espoir est le commencement de la mort. " CdG

Personnellement, j'ai mis au point un système de cache database qui est publié dans "vos scripts" dans sa version "simple"
Compléments BBS MOD
Il est basé sur des travaux de Knat à l'origine et il tournait sur SoW puis maintenant le TN Bouchon depuis plus d'un an sans pertes de données. (plus de 500 démarrages modules)
Personnellement, j'utilise aussi APS-NWNX et NWN-FF mais comme je n'ai pas besoin de requêtes complexes pour l'instant, je préfère de loin mon système, tout simplement parce que j'ai déjà pas mal de scripts déjà fait avec ...
J'ai pas le temps de tout réécrire pour mySQL et surtout, comme on héberge à plusieurs, nous ne voulons pas nous prendre la tête à obliger à la configuration d'un mySQL pour chaque hébergeur : "take the pack and launch the server".

J'ai fais des tests comparatifs, affiché sur la guilde NWN-FF : j'obtiens de meilleurs résultats, jusqu'à 3 fois plus rapide pour la gestion d'objets "linéaires" comme les coffres persistents.

Pour mettre au clair quelques idées reçues, la limite technique du nombre de variables sur des objets est largement supérieure à 10000.
Par contre, un conseil, au delà de cette valeur (ca dépend du CPU sur votre machine en fait), optez pour une database qui utilise des index, ça fera le boulot plus rapidement.

Enfin, pour ceux qui se sont penchés sur le problèmes d'inventaires persistents dans des coffres : la limite en nombre d'objets mémorisables en une passe avoisine les 300 objets, tout simplement parceque les scripts sont limités en nombres d'instructions par le moteur nwn.
Cette limite est indépendante de la méthode de stockage choisie, et encore, c'est si vous ne cherchez pas à mémoriser une apparence spécifique d'un objet modifié via le système de "craft nwn". Dans ce il vaut mieux utiliser les fonctions natives nwn Store/Retrieve


Egalement, ces deux fonctions quand elles seront corrigées, devraient permettent de récupérer facilement TOUTES les variables positionnées sur des objets en un seul appel.

ben moi en fait je n'ai pas fait appel a grand chose. J'utilise les variable local (SetLocal et GetLocal) quand j'ai pas besoin que les donnée soit recupérée. Sinon j'utilise la BDD Bioware (SetCampaingn et GetCampaingn). Par contre j'utilise plusieur BDD, une pour les quetes, une pour les Items, une pour les PJ, une pour chaque banque.

Je doit aussi avouer que c'est parce que je ne comprend pas trop le fonctionnement des autres systèmes

Et je ne pense pas que cela fasse trop de lag sur mon serveur.

Par contre, je regrette juste que cette BDD soit aussi Opaque, j'aurais bien aimer pouvoir aller jetter un oeil dedans et de pouvoir changer la valeur d'une entrée comme je le souhaite.
J'espère juste que pour NWN2 la BDD sera plus aisée d'acces, mais ne ne rêve pas trop !

Yep, c'est promis par les développeurs qu'il y aurait une amélioration de la BDD nwn, ou du moins des possibilités d'interfaçage (parle chinois).
Le standard XML devrait se généraliser partout dans le nwn2

A part ça, pas de bidules secrets en ce qui me concerne : c'est juste un enrobage savant des SetCampaign et GetCampaign pour les "String" et les "Int"
Mes fonctions de base sont évocatrices : SetCacheInt, GetCacheInt, SetCacheString, GetCacheString.
C'est même plus court à écrire au final quand tu codes.

M'enfin je l'admets volontiers, l'implémentation actuelle n'est pas simple, mais c'est normal le concept n'est pas simple non-plus. Il faut bien passer 1/4 heure à positionner correctement les scripts.

Bonsoir !

Tout d'abord merci à tous de m'avoir répondu aussi vite et de façon aussi détaillée !

Si je résume ce que j'ai compris :

1) Les variables sur un objet persistant de l'inventaire sont plus rapides mais peu pratique car non-accessibles.

2) La data Base de Bioware peut convenir mais pour une utilisation limité.

3) Les bases de données Sql sont assez rapides et facilement accessibles mais présentent l'inconvénient d'utiliser un programme externe plus où moins facile à configurer/utiliser.

4) Le système de Lylver à l'air intéressant, je vais essayer d'y jeter un coup d'oeil "sérieux" et voir s'il est plus simple et s'il peut convenir.

J'y vois déjà beaucoup plus clair.
Nous allons en discuter au sein de ma team, faire différents tests et nous aviserons en conséquence.

Merci encore !
A bientôt !

Citation :Si on ne peut pas y avoir accès, c'est quand même embêtant !

H.S.: Au fait, tu travailles sur quel module?

Salut !
Je travaille sur un module persistant action dans l'univers de Star Wars.


Citation :Ce que je voulais dire, c'est que les CampaignInt sont accessibles via un fichier texte alors que ( si j'ai bien tout compris), on n'a pas l'équivalent pour les localInt sur les objets.
A bientôt !

Enki a écrit :Pour ma part j'utilise cette solution.

Avantages: Scripts simple, possibilité d'avoir la base de données sur internet ou sur son pc (*.db)
Désavantages: Utilisation de nwnx et nwserver : ce qui peut dérouter les novices en la matière.

Enki a écrit :Oui pour les CampaignInt, ils sont l'équivalent d'une base SQL sur le pc (vous me direz alors pourquoi utilisez NWNX ? Parce que je le trouve plus clair, enfin après chacun son truc.)

Mais les localInt ou tous les local (string, object) sont supprimé lors de l'extinction du serveur non ? Je les utilise pour les scripts momentanée moi. (Mais encore une fois c'est à vérifier, même si je suis à 95% sûr)
_________________
"Ne dit pas affronter les ténèbres celui qui n'a jamais connu la tombée de la nuit."

Bonsoir, j'en profite pour vous poser une question pendant que les amateurs du sujet sont encore ici, sur une station unix, (debian), dans l'optique d'utiliser une connection SQL, que faut il utiliser comme programme, car il me semble que ceux proposé plus haut ne fonctionne que sous plateforme windows? Quelqu'un pourrait il m'éclairer? Merci.
_________________
nwn.ak-team.com:5121
Scripteur/Mappeur, DM
[http]
Responsable de la Communauté. AkTeam-NWN.

http://www.nwnx.org/ a écrit :
http://www.nwnx.org/ a écrit :Lien pour linux : http://sourceforge.net/projects/apsnwnx/

Ya pas trop de précisions mais je pense que tu trouvera des informations en cherchant dans les forum NWNX anglophone.
_________________
"Ne dit pas affronter les ténèbres celui qui n'a jamais connu la tombée de la nuit."

bonjour, je voudrait juste avoir quelques precisions sur SQL.... Comment on l'installe, comment on l'utilise et comment ça marche?
Je veux dire quesque je doit faire pour avoir un systems qui sauvegarde les pj, leurs inventaires, les coffres et les quetes?

Pour ceux que cela intéresse, je viens de déplacer le serveur hébergé chez moi sur un hébergeur pro pendant un mois.
J'ai donc du refaire la procédure d'installation du socle base de données.

Franchement c'est relativement simple avec EasyPhP1.8
Il faut juste repasser avec l'outil d'administration qui se trouve sur l'url Code :
et suivre les directives pour créer une base.
Ensuite vous passez dans la section privilèges et vous utiliser la fonction duplication pour "cloner" le compte root pour un compte dédié à votre nouvelle base, ajuster ensuite tranquillement les droits de ce nouveau compte pour éviter qu'il vienne polluer la configuration maître.
Note : toutes les tables seront ensuite créés par le module lors de son éxécution, vous n'avez qu'à bien remplir les champs compte, mot de passe et nom de la base dans le fichier de paramètres : nwnx.ini ou nwn-ff.ini

-------------------- options ----------------------

Là ou ca peut se compliquer, c'est quand vous avez la base mysql sur une autre machine, il faut mettre 0.0.0.0 dans la configuration d'écoute du serveur mysql et accessoirement changer le mot de passe root de la base en autre chose que '' (vide)
Code :

Si vous changer le mot de passe root n'oublier pas d'indiquer dans le fichier config.inc.php vos changements sinon les outils d'administration ne fonctionneront plus :
Code :

--------------------- fin des options ---------------------

Pour la configuration dans un module, j'utilise NWN-FF 4.1.0, FastFrench code assez cochon pour les éxécutables mais on s'en fout, sa documentation en anglais pour l'implémentation dans un module est bonne, je n'ai pas rencontré de difficulté.
Ni eu à faire de réglages sur les paramètres de mysql pour l'instant, c'est prévu pour un usage bien plus costaud que ce que vous en ferez, ne pas s'en inquiétez sans raison.

Si vous souhaitez jetez un oeil aux statistiques fournies avec NWN-FF, je vous invite à faire un tour là :
Logs TNBs
Soyez gentils de abuser du lien il y a parfois de gros fichiers. (lien valable pendant quelques jours)

Les temps de réponse mysql sont plutôt bons et s'améliorent avec le remplissage de son cache