|
[SM]
Oracle
|
Je suis fort étonné de ne presque rien trouver ici ou très peu d’information concernant NWNX, qui est la révolution pour les modules persistant ramenant au rang d’archaïsme primaire les autres solutions qui avaient cependant tout de même le mérite d’exister avant sa venue.
NWNX apporte ce qui faisait cruellement défaut à nwn c’est à dire la gestion par une base de donnée les différentes informations qui circulent au sein du module et devant être conservé et manipulé tout en permettant l’évolution du module. Il est même possible de qualifier les variables pour leurs affectés une qualité temporelle, c’est à dire que la variable sauvée peut être effacée par nwnx au bout d’un certain temps définit par le scripteur. L’intérêt d’usage d’une telle solution est d’éviter un ensemble de manipulation à la re-compilation du module lors de mise à jour, qui peut être source d’erreur et de difficultés lors d’une mise à jour. Eviter un volume trop important de ligne de scripte dédié uniquement à la sauvegarde des variables et aussi à la gestion d’objet placeable volumineux ne servant qu’à la sauvegarde (cf Ambrosia). Le gain de temps à la recompilation est remarquable, les scripteurs faisant des multiples recompilations pour l’évolution de leur module en verront un intérêt majeur. De ne pas charger l’inventaire du personnage ou le personnage lui-même d’éléments pour conserver les variables. La gestion des variables se fait comme elle doit logiquement être faite, en dehors de la jouabilité du personnage et totalement transparente pour le joueur. La solution nwnx prend également en charge la gestion de portabilité des persos sur d’autres serveurs qui devront être équipés de la même solution. Il n’y a pas de limite de quantité globale de variable. Cela évite ainsi d’être limité à cause de la limitation de la quantité de ligne de scripte sur aurora. Comment fonctionne NWNX ? C’est vraiment simple. C’est un exécutable qui est lancé, une fenêtre DOS apparaît en même temps que le chargement de la fenêtre de lancement du serveur qu’il faut ensuite normalement utiliser pour lancer le module. Il existe également la possibilité d’y inclure une ligne de commande pour lancer automatiquement le module. Ce qui permet de gérer sous forme de fichier batch (un fichier .bat ou .com) le lancement du module. On voit tout de suite l’intérêt d’administration à distance se profiler. Nwnx ensuite, se charge des transactions sous forme de requête SQL entre le module et la base de donnée dont on a plus à s’en soucier. Comment l’installer ? C’est encore plus simple. Il suffit de placer l’exécutable nwn extender dans le dossier de nwn. Importer le point erf fournie qui contient deux malheureux petit scripte et non pas une ribambelle de scripte plus compliqué les uns que les autres qui peuvent se corrompre lors de mise à jour ou d’importation d’un autre erf qui serait malheureux en les écrasant. Une ligne de scripte à mettre dans l’event OnModuleload pour initialiser nwnx en y incluant la bibliothèque. Les fameux et classiques includes à mettre en début de scripte pour gérer les bibliothèques, qu’on retrouve un peu partout. A noter que nwnx n’en possède qu’une, cela évite de se retrouver avec une tonne de bibliothèque s’appelant mutuellement. Ensuite on passe au chose sérieuse avec la base de donnée. Il faut lancer l’utilitaire de gestion d’ODBC et déclarer le lien avec le moteur de la base de donnée à utiliser en lui donnant comme nom nwn. C’est expliqué dans la procédure d’installation, rien de bien difficile en soit. Comment utiliser et employer NWNX ? Si on ne veut pas s’ennuyer avec la gestion de base de donnée ou que le modèle fourni nous convient, on l’emploie pour y stocker les variables au fur et à mesure qu’on en a besoin. Pour les gérer, on les nomme tout simplement et ensuite on les gère comme les autres systèmes. Sinon il y a un moyen beaucoup plus riche et puissant de travailler sur la base de donnée en écrivant directement des requêtes SQL dans ses scriptes, c’est assez puissant pour permettre de gérer même un ensemble de variable en retour. Par exemple l’ensemble des persos de telle catégorie pourrait être aisément retrouvée avec une requête. L’élément fort est la possibilité de gérer les variables à l’extérieur de nwn et du coup de pouvoir apporter une interactivité avec l’extérieur du module. Rassembler par exemple un ensemble d’information et les gérer sur une page web est de l’ordre du possible. Alimenter la base de donnée de manière externe pour élargir les fonctionnalités du module. Le défaut principal de cette solution, est qu’elle ne tourne actuellement que sur des serveurs windows. L’auteur (papillon) a fourni les sources, c’est du visual c++ afin de pouvoir rendre nwnx compatible avec une solution Linux. On ne devrait plus trop attendre avant qu’une solution équivalente en Linux ne sorte, à moins qu’ici on ait des personnes suffisamment qualifiées pour le faire. Je vous dis tout de suite que je serais preneur. Voici le lien pour la version 1,23 de nwnx avec les codes sources. NWNX Ocan |
19/02/2003, 12h55
|
NWNX
| Suivre |
|
|
Partager | Rechercher |
|
Alpha & Oméga
|
Avant d'opter pour une autre solution que le PUMA, je crois que je vais plutot attendre la solution de Bioware, l'avantage c'est qu'au moins tout le monde l'aura.
Je pense que nwnx, mais ce n'est que mon avis, ne durera que jusque là. Personellement je porte beaucoup d'espoir dans ce que Bioware nous prépare et je crois que c'est le cas de pas mal d'entre nous. Wait and see  Jaha Effect 
|
|
19/02/2003, 13h09
|
|
Oracle
|
Je suis d'accord avec Jaha.
Deux choses me pousserai a m'intéresser a NWNX : -que le système de BdD de la 1.29 soit décevant -que je trouve enfin une explication sur le fonctionnement (c.a.d comment exportent-ils des données ailleurs que dans le log, et comment vont-ils lire dans la BdD a partir de NWN) Mais une chose est sur : respect envers les développeurs qui ont fait ca |
|
19/02/2003, 13h24
|
|
Oracle
|
Tout à fait d'accord avec Jaha. Inutile de se disperser tant qu'il est possible de tous être rassemblés sous un même système. Disons que pour l'instant, PUMA, APTS ou NWNX sont autant de solutions temporaires.
La question se posera si l'on constate que Bioware nous a pondu une grosse "esbroufferie"...pour rester poli. |
|
19/02/2003, 13h30
|
|
[SM]
Oracle
|
Comme je l’ai dit en début de mon post, il me semblai anormal qu’il n’ait aucune ou presque pas d’information sur le système d’enregistrement de variable le plus performant actuellement.
Je pense qu’aujourd’hui s’il fallait faire un choix pour un nouveau module persistant à construire, NWNX serait la meilleurs des solutions. Maintenant, bien sur, suivant l’historique et les travaux de chacun sur leur propre module, remettre en question le système de sauvegarde est un autre sujet, qui n’est pas celui qui est mis ici. En ce qui concerne d’attendre la sortie de la 1,29, c’est effectivement une solution aussi mais toujours pour un module existant et non pas un module à créer. Je ne sais pas encore comment bioware va gérer cela, si la BDD sera propriétaire et fermée ou bien une base exploitable extérieurement. Je ne sais pas également si elle sera liée à la version du serveur et s’il sera possible de créer autant de table que l’on souhaite et qu’on ait besoin. L’idéale serait d’avoir un gestionnaire ou un utilitaire de la BDD fournie et de permettre de l’attaquer extérieurement. Mais j’anticipe certainement un peu trop et que Bioware voudra très certainement garder le contrôle là dessus. Iridian : sur le source tu trouveras l’information que tu souhaite. En résumé c’est une interruption du serveur, une recherche dans la pile mémoire de variable, nwnx se charge ensuite d’effectuer la transaction soit, il récupère la variable et la charge dans la BDD via l’odbc soit, il charge dans une variable le résultat d’une requête. Donc comme je le disais, ce post n’est pas là pour vous dire que vous avez eut tord de prendre autre chose et de changer votre système mais juste une présentation et une information importante dans le choix d’un système de sauvegarde des variables. Ensuite chacun est libre de faire ce qu’il souhaite. On ne va pas brider l’information au motif que cela remettrait en question les travaux de certain. Ocan |
|
19/02/2003, 14h07
|
|
Alpha & Oméga
|
Et c'est effectivement un tres bon procede de sauvegarde.
Pour ma part, j'attends encore le procédé officiel dans un soucis de simplicite d'utilisation serveur, mais je ne m'inquiete pas, des que je veut de la persistance, il y en aura, et du bon ^^ Je te remercie donc d'avoir pris le temps de faire de l'info a ce propos : allez hop => Persistant 
|
|
19/02/2003, 14h14
|
|
Alpha & Oméga
|
Citation :
Je le répète, le gros avantage de la version Bioware c'est que tout le monde l'aura. Les évolutions suivront les mises à jour de bioware ce qui est un autre avantage. Et le dernier avantage, c'est que ça focalisera toutes les énergies dans le même sens, force est de constater que chacun fait sa soupe de son côté, PUMA, APTS, et autres c'est quand même des projets différents qui ont le même but. Si on doit faire évoluer NWN, autant qu'on travaille sur les mêmes bases. Jaha Effect
|
|
19/02/2003, 14h33
|
|
[LeCo]
Prophétesse
|
Tres interessant.....
Tres interessant, mais certaine questions restent en suspend:
- Le systéme doit il obligatoirement passer par une liaison ODBC? - Quelles sont les Base de données prise en charges? - Y a t il un schéma de base à respecter ou est ce que le schéma est totalement libre? - Et au niveau de la charge, le systeme est il gourmant en ressource systéme? Prophetia |
|
19/02/2003, 14h47
|
|
Oracle
|
Voila qui répond a ma question
Pour ma par, si le système made in bioware me déçois la 1.29 venue, je m'intéresserai TRES sérieusement a ce logiciel Ultime question (sans doute débile mais c'est pas grave) : L'odbc n'est utile que sur le serveur ? Pour prophetia : en théorie l'avantage de l'odbc, c'est que tu peu attaquer n'importe quel type de base a condition d'avoir le bon pilote odbc et le moteur de bdd installé. Donc en théorie toujours, tu devrais pouvoir faire tourner sa sous mysql ou acces ou même SQLServeur, etc ... |
|
19/02/2003, 17h02
|
|
[LeCo]
Prophétesse
|
Citation :
Ensuite, comme 99,99% des personnes développant des modules sont des particulier, je vois mal un particulier investir dans un serveur SQL Serveur. Alors que MySQL (ou Progrest SQL si on veut un peu plus de performance) étant completement gratuit et sous licence GNU, il n'est pas tres compliqué d'integré des connections native, beaucoup plus performante et rapide surtout sur des grosses requétes, le système pouvant tout à fait coexister avec une gestion ODBC. Rassurez vous, je vous demande pas encore de connection native à ORACLE  quoi que..... 
|
|
19/02/2003, 17h51
|
|
[SM]
Oracle
|
Pour compléter l’excellente réponse d’Iridian fait à Prophetia, je dirais qu’effectivement il faut obligatoirement avoir le pilote ODBC pour pouvoir attaquer la base de donnée. De toute façon celui-ci est fourni avec le moteur de la base de donnée. Toutes les bases de donnée qui fournissent un pilote ODBC sont utilisables, ce qui veut dire en résumé toute, et c’est bien là un des avantages de la solution. Des tests probants ont été effectués sur ACCESS, Oracle, Mysql, SQLServer…
Mysql est un SGBD qui a l’avantage d’être libre de diffusion, on peut le récupérer sur le site www.mysql.com différente version sont actuellement en circulation. Certaine validé par la communauté et d’autres en cours de bêta-test. Il est inutile de se précipiter sur la dernière version qui risquerait de vous jouer des tours, la version 3,23 pourrait être utilisé, je pense. Le pilote ODBC se nomme MyOdbc on le trouve au même endroit. Nwnx fournie en exemple un schéma, une structure de base, à mettre en place, mais si on ne souhaite pas le faire, il est fourni également un module, en exemple, qui permet de créer la structure de la base donnée. Il suffit de lancer le module (en ayant pris soins bien évidemment de lancer avant Nwnx et de déclaré la liaison odbc) En fait ce module, vous permet de tester si la liaison nwnx et l’ODBC est bien en place, il vous crée une table dans votre base de donnée qui se nomme pwdata et définie sa structure, vous pourrez même tester un enregistrement. Vous pourrez par la suite, pour votre module conserver cette structure dans votre module. L’appel des variables se fait ensuite suivant ce schéma dans l’include fournie, qui en fait transforme le tout en requête SQL, mais vous n’avez pas à vous soucier de cela si vous ne souhaitez pas modifier l’include et travailler sur les requêtes SQL. Par contre pour ceux qui maîtrise les requêtes SQL, ils peuvent se faire plaisir en tapant directement des requêtes dans les scriptes. En ce qui concerne la charge, c’est là où il y a actuellement quelques interrogations, papillon travaille dessus pour l’optimiser. Le serveur n’est pas bloqué, ni saturés mais on note cependant une augmentation sensible de la charge, si vous avez des serveurs qui sont limités en capacités de traitement vous devriez voir la charge monter mais cela n’est pas bloquant. Iridian, je ne comprends pas bien le sens de ta question. Un ODBC est une interface entre une application et une base de donnée. Il permet d’interroger et d’écrire sur les tables d’une base de donnée comme si on utilisait la base de donnée en elle-même. Lors de la déclaration de la liaison avec la base de donnée on indique : le pilote ODBC choisit (en correspondance avec le moteur de la base de donnée) et le chemin de la Base de donnée (là où se situe la BDD). Il est possible en ce sens d’attaquer une base de donnée de n’importe où, mais toujours faut-il que la machine, sur laquelle on déclare la liaison, ait les droits de pouvoir y accéder. L’ODBC est utile là où on a besoin de faire une liaison pour un traitement. Pour NWNX par exemple il n’est utile que pour le serveur où le module tourne. Si un autre module doit attaquer la même base de donnée, il faudra simplement dans l’ODBC de se module indiquer le chemin de la même base de donnée. Ocan |
|
19/02/2003, 18h01
|
|
[LeCo]
Prophétesse
|
A en lire cette réponse, je me dis qu'apriorit le systéme n'utilise que le SQL de base et que dans ce cas il aurait été assez judicieux de se contenter d'une connection native MySQL, etant un SGDB totallement gratuit marchand aussi bien sur Linux que sur Windows.
L'interet d'utiliser d'autre SGDB consiste surtout à la possibilitée d'utiliser des langage SQL évolués tel que le TRANSACT SQL ou le pl-SQL... Ce qui aurrait contribué largement à une diminution de la charge sur le serveur... [edit]Bon ben je vais telecharger Oracle 9i et tester les requètes pl-SQL [/edit]
|
|
19/02/2003, 18h17
|
|
Oracle
|
Citation :
merci @Prophetia : Oracle est gratuit ?!? je savais pas ca tient ! tu aurais un ch'ti lien ? |
|
19/02/2003, 20h39
|
|
[LeCo]
Prophétesse
|
http://www.oracle.com, il faut savoir pour oracle que le logiciel (si on peut appeler ça un logiciel lol) en lui meme est gratuit et téléchargeable sur le site d'oracle, seule la licence d'utilisation est payante, et là je vous raconte meme pas le prix....
Donc en gros on à tout à fait le droit d'utiliser Oracle de façon personnelle afin de developper des outil autour d'Oracle par exemple, par contre son utilisation courante necessite une liscence, et là faut avoir les moyens... Donc une version Oracle9i Database Release 2 Enterprise/Standard/Personal Edition for Windows NT/2000/XP, il faut compter environs 1,3 Go juste pour les fichier à télécharger Prophetia p.s: depuis le post, ils ont mis un systeme login mot de pas, mais il suffit de s'enregistrer, c'est gratuit, mais bon atention aux utilisations froduleuse
|
|
19/02/2003, 20h53
|
|
Oracle
|
A quand Oracle sur kazaa...
|
|
20/02/2003, 10h42
|
|
[LeCo]
Prophétesse
|
Citation :
Et puis je ne vois pas trop l'intérêt d'aller s'encombrer les connections avec des fichier des cette taille en pear to pear alors que n'importe qui peut le télécharger sur le site d'Oracle.... Sinon, j'ai passé la nuit à le télécharger, et j'ai récupérer NWNX, par contre comme j'ai pas trop le temps pour l'instant, je ferrais les test ce Week-End sur des requête pl-SQL, Transaction, Procédures Stockées, je vous tiendrais au courant, mais bon je ne sais même pas si ma machine va tenir le coup.... *Croise les doigts* |
|
20/02/2003, 11h28
|
|
[LeCo]
Prophétesse
|
Citation :
Maintenant comme pour moi Acces c'est vraiment pas une Base de données, je me suis installé Oracle, j'ai creer mon DSN qui fonction tres bien puisque j'ai fait un test en faisant une liason de table dans Access, mais parcontre, pas moyen de lancer avec NWNX, ben oui, il y a un problème, comment renseigner le Login et le Mots de PAsse pour la connection au serveur? ben comme c'est expliqué nul part, je suis rentrée dans le code pour voir, ben la réponse que c'est impossible. Dans le code le nom du DSN et ecrit en dur, et la fonction de connection passe en dur un login et un mot de passe NULL Donc à part l'authentification NT, et encore je suis pas certaine, je vois pas comment ça a put etre testé sur SQLServer ou Oracle... |
|
22/02/2003, 20h27
|
|
Oracle
|
Par un lien ODBC vers Oracle, il doit être possible de mettre un login et un mdp par défaut non ?
Apres je ne sais pas si un appel du lien par le programme et sans ces données déclenchera l'utilisation de ces informations. (je dit peut-être n'importe quoi, mes rapport avec l'ODBC s'arrêtent a Access et Informix) |
|
22/02/2003, 21h52
|
|
[LeCo]
Prophétesse
|
Bon ben apres avoir recherché un peu plus, j'ai trouvé, grace à l'authentification NT, mais bon ça serrait quand meme mieux de pouvoir passer le login et le mot de passe
|
|
22/02/2003, 23h16
|
|
[SM]
Oracle
|
C'est sur l'ODBC qu'on indique le login et le mot de passe d'accés à la base de donnée. Je n'ai pas sous la main d'exemple à te donner pour la marche à suivre qui est relative également au client oracle incluant l'ODBC.
Si tu as du mal à trouver je t'indiquerai le mode opératoire spécialement pour Oracle, je ne l'ai pas fait pour nwnx mais pour d'autres applications et ça passe bien. Ocan |
|
23/02/2003, 22h06
|
|
[LeCo]
Prophétesse
|
Citation :
 Mais par contre, il est possible de créer un utilisateur utilisant l'authentification NT, en ne renseignant pas l'utilisateur à utiliser pour la connection dans le pilote ODBC, celui-ci prend ce dernier utilisateur par défaut, donc étant authentifier sous l'OS, on est automatiquement authentifie pour Oracle, il suffit d'ajouter les bon droit dans Oracle pour l'utilisateur de l'OS dont on se sert pour lancer le serveur, et le tour est joué J'ai donc tester, ça fonctionne très bien, il suffit juste de changer quelque ligne dans les requête de l'aps, car les requête accès fonctionne pas trop bien avec Oracle Il me reste encore tout une série de test à faire avant de me lancer dans l'écriture de bibliothèques "aps" dédiées au différentes bases MySQL, SQLServer, Sybase, ProgrestSQL et Oracle. Je pense qu'avec ça ça devrait déjà suffir.... Prophetia p.s: Normallement pour Sybase et SQLServeur, ça devrais être la même puisque c'est le même moteur à la base. |
|
23/02/2003, 22h58
|
|
[SM]
Oracle
|
Je dois t'avouer que je ne gère pas encore de base de donnée Oracle en 9i, j'ai commencé à la 7,34 qui tourne toujours
et je dois en avoir 2 ou 3 en version 8 et des poussières.Tu as renseigné ta chaine de connexion ? Qu'est ce que tu as mis dans ton tnsname.ora ? |
|
24/02/2003, 01h46
|
|
Légende
|
Bonjour a tous,
je sais que le post n'est plus d'actu mais j'ai de serieux problemes pour faire marcher le CNR et ma bd SQL en meme temps... il y a des scripts par defaut utilisant la bd bioware, avec les lignes de programme a activé ou desactivé pour que ca bascule sur SQL et pourtant les tables ne se creeent pas etc..etc... je vous remercie d'avance : gdc3869@hotmail.com |
|
24/11/2005, 21h46
|
|
Alpha & Oméga
|
Peut-être utile pour NwN2, je remonte.
|
|
14/12/2006, 16h26
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|