[Sherazade]

Citation :

Provient du message de Azrael07
Le seul et unique cas où je pourrais te donner raison, c'est dans un cas de quantité de données colossale, associée avec une gestion sql de main de maitre, pour des enregistrements de logs ou stats par exemple, mais qui dans touts les cas sont sensés resté en bdd et n'ont aucun interet a finir dans la ram.

Il s'agit en effet de données nombreuses, de l'ordre de centaines de milliers de variables... oui oui, ça sent le CNR... il s'agit de FF qui a fait ce genre de test. Je suis comme toi, dubitative. Mais connaissant les compétences de la personne, je peux difficilement croire qu'il ait pu se fourvoyer. Cela dit, je suis perplexe quand même, et ça ne m'empêche pas d'utiliser les Get/SetLocal nettement plus souvent que les Get/SetPersistent de NWNX .

Je ferais des tests un de ses jours avec le point que soulève Azmathiel, ça me titille ce truc .

['Az]

Citation :

et la version open, on peut espérer la voir ?

pffff... je commencais a me réjouir que personne ne me le demande :P

je verrais ce que je peux faire, mais faut pas s'attendre a ce que ca soit imminant

[Azmathiel]

D'abord, fallait pas le proposer

Ensuite, j'ai toujours le même genre de réponse depuis qu'on me tannait avec de l'aide sur la création de tables pour le système de sauvegarde par base de données:

un système de persistance est PERSONNEL. Il n'y a pas deux serveurs utilisant les mêmes données. Or, si quelqu'un attend qu'on lui développe un système complet, c'est qu'il ne sait pas le faire. Ce qui veut dire qu'il ne saura pas l'adapter à ses besoins. Par conséquent, je ne vois pas l'intérêt de mettre ce genre de système à disposition de chacun. Surtout qu'avec ces outils là, c'est à la portée d'un scripteur même médiocre comme moi.

['Az]

Azmathiel, je ne te suis pas vraiment sur ce point.

Les systèmes de persistances sont tout de même une part énorme d'un module, et la façon dont sera stoquée les données sera toujours plus ou moins identique, la finalité reste la même quelle que soit le module.

Ensuite, programmer un système de persistance n'est pas forcément facile, loin de la. Pourquoi devoir nécessairement repartir a zéro et réinventer la roue a chaque fois, si des systèmes déjà existant vont dans le même sens que ce a quoi on veut arriver ?

Ensuite, ne pas savoir faire un système de lecture de fichiers .bic comme celui que je propose n'est pas une honte, loins de la.
Tu admet toi même ne pas savoir, dans l'immédiat, comment s'y prendre, est ce que c'est parce qu'on ne sait pas faire qu'on ne peut pas utiliser ?


Bon, ensuite cela dit, j'espère que celui qui a réclamer sait réellement de quoi il s'agit ?
ca n'est en rien un nouveau système de persistance, c'est une méthode détournée pour avoir accès au fichier .bic de l'utilisateur afin de le modifier plus ou moins dynamiquement, permettant ainsi de violer certains des systèmes de règles de neverwinter nights, et optionnellement, un moyen d'exporter les information contenue dans un fichier .bic, y compris les variables qui y sont contenues, mais ca, un nwnx peut le faire sans problèmes
En gros, aucun interet, si ce n'est dans des cas très particulier

tient au fait :

Citation :

Il reste aussi en suspens le problème de la structure de certaines données sur lesquelles nous n'avons aucune documentation fiable (comme la structure exacte du type "object", ou la structure d'une variable type "location"). J'ai bien quelques supputations qui me viennent de l'observation des données dans les tables Bioware, mais rien de concret à cette heure.

http://nwn.bioware.com/developers/

[Sherazade]

Quelles sont / seront les fonctionnalités de ton outil par rapport à LETO ?

['Az]

qu'il est (sera) dynamique, ou disons semi-dynamique, et peut être dirigé a partir de fonctions nwscript.

Semi dynamique car il necessitera une reconnection du personnage joueur avant que les modifications soient prise en compte.
Je compte l'utiliser pour personnaliser le passage de niveau, et considère pouvoir me permettre de demander aux joueurs une reconnection a chaque passage de niveau.

par ailleur, il faut que je me penche un peu sur le code source de nwnx, en le réutilisant je peux peut être plutot créer un plugin a nwnx qui aurait l'aventage de ne pas necessiter de reconnection, mais la je ne peux rien affirmer

[Sherazade]

Intéressant tout ça, tu peux me compter parmi les personnes intéressées .

Tu utilises quelle méthode pour le diriger par les scripts NwN ? Via NWNX ? Une autre méthode ?

Pour le moment, j'effectue en effet du bricolage via LETO pour modifier les .bic, mais pouvoir le faire semi-dynamiquement de manière automatique permettrait de gérer le résultat de quêtes spéciales (pour des ailes ) sans avoir à faire ce bricolage .

['Az]

dans un premier temp les logs, après on verra par la suite ^^

[Azmathiel]

Merci pour le lien, Azrael
J'étudierai ça un jour...

J'explique ce que j'ai dit plus haut, au sujet de la mise à disposition publique, un peu mieux. D'abord, j'avais compris que tu parlais d'un système de persistance basé sur ces variables (ça y est, le mien tourne, j'y ai passé la nuit, ce fut long mais bon ).

Je veux bien comprendre qu'avant, quand il fallait bricoler des string pour permettre une sauvegarde plus rapide, on pouvait penser rendre publique sa création et que ça aiderait pas mal de monde, mais là, que faire de plus simple qu'un SetLocalInt( oObjetDePersistance, "xxxxxx", 1) au lieu d'un SetLocalInt(oPersonnage, "xxxxxx", 1) ?
Proposer un tel truc, ça ne tient pas debout voyons !

Maintenant, si tout le monde pensait que je parlais d'un système de récupération et de bidouille des fichiers .bic, je me suis mal fait comprendre. Je ne pensais pas du tout à ça.

['Az]

mais où voulait tu en venir avec le petit pavé que j'ai déjà cité bien plus haut ?

Citation :

Personnellement, je n'en suis pas à ce stade là de la recherche des fonctionnalités possibles. Mais si on arrive à accéder au fichier du personnage, on arrive.......

je vois pas trop en quoi intéragir avec le fichier .bic peut faire avancer les choses en matière de persistance O_o

[Malicene]

Citation :

Provient du message de Azmathiel
un système de persistance est PERSONNEL. Il n'y a pas deux serveurs utilisant les mêmes données. Or, si quelqu'un attend qu'on lui développe un système complet, c'est qu'il ne sait pas le faire. Ce qui veut dire qu'il ne saura pas l'adapter à ses besoins. Par conséquent, je ne vois pas l'intérêt de mettre ce genre de système à disposition de chacun. Surtout qu'avec ces outils là, c'est à la portée d'un scripteur même médiocre comme moi.

D'accord sur le principe, rien n'est réutilisé tel quel, mais pour un scripteur encore plus médiocre que toi , avoir une structure et un système qui fonctionne... ça aide beaucoup

[Azmathiel]

@azrael: c'était en réponse à la question de savoir si on pouvait accéder à ces données (de Rhyghar, je crois). On postait tellement vite hier qu'on avait du mal à suivre le fil. Ca tirait de tous cotés.

@Malicène: certes, mais ça va être dur de structurer quoi que ce soit, vu qu'on utilisera exclusivement des fonctions de base pour soutenir un système de persistance. Personnellement, j'ai travaillé à adapter mon système existant toute la nuit et j'ai remplacé mes fonctions d'accès aux tables (SetCampaignXXXX) par des fonctions d'accès à des variables locales sur un objet (SetLocalXXXX). Rien de très recherché. Juste un travail de fourmi.

[Garrath]

Euh j'ai juste une petite question sur un point qui est apparu au debut du thread.
Les variables definies en locale sur un objet d'inventaire disparaisse quand l'objet est vendu a un marchand.
Euh c vrai ca?
Ce qui veut dire que les variables que l'on defini a la creation d'un objet sous aurora disparaissent aussi lorsque l'objet est mis sur un marchand!?!?

[Mastokk]

Citation :

Provient du message de Garrath

Ce qui veut dire que les variables que l'on defini a la creation d'un objet sous aurora disparaissent aussi lorsque l'objet est mis sur un marchand!?!?

Oulà non, c'est différent, tes propriétés que tu définies à la création d'une arme y restent quand tu vends cette arme, ne t'inquiètes pas. Là on parle de variables locales posées sur un objet d'inventaire (arme, armure, objets en tout genre) qui d'après ce qui a été dit disparaissent lors de la vente de l'objet, on ne parlait pas des propriétés d'un objet crées sous aurora .

[eMRaistlin]

Citation :

Provient du message de Mastokk
Oulà non, c'est différent, tes propriétés que tu définies à la création d'une arme y restent quand tu vends cette arme, ne t'inquiètes pas. Là on parle de variables locales posées sur un objet d'inventaire (arme, armure, objets en tout genre) qui d'après ce qui a été dit disparaissent lors de la vente de l'objet, on ne parlait pas des propriétés d'un objet crées sous aurora .

On peut maintenant attacher des variable directemetn dans le toolset. Il ne parlais vraisemenblablement pas des propriétés (enfin, je ne pense pas).


Et a mon avis, variable tollset ou variable fonction, c'est même combat... (mais sans un test pour confirmer, je m'en voudrait de dire oui ou non de façon catégorique...)

[Mastokk]

Citation :

Provient du message de eMRaistlin
On peut maintenant attacher des variable directemetn dans le toolset. Il ne parlais vraisemenblablement pas des propriétés (enfin, je ne pense pas).


Et a mon avis, variable tollset ou variable fonction, c'est même combat... (mais sans un test pour confirmer, je m'en voudrait de dire oui ou non de façon catégorique...)

rhaaa ok ^^. Encore un truc que je savais pas .

[Le grognon]

ouep..les variables toolset et ingame, c'est kif kif...

pour ce qui est de lire ce type des variables sur un fichier .bic il me semble que la toute derniere version de LETO le fait ..mais à verifier...(j'ai vu un vague message sur les forums bio section develloper)

[Garrath]

Oui je parlais des varaibles que l'on peut definir au travers du toolset et que l'on utilise exactement comme des variables locals...

Bon je vais tester tout de suite ce truc du marchand car sinon la, j'ai des trucs qui ne marcherons plus

[Garrath]

Bon apres test avec un marchand les variables crees a partir de Aurora ne sont pas supprimees...

[Twist]

Oui, mais attention, (je m'y suis fait prendre) le problème se pose sous Aurora si vous tentez de placer des items avec variables dans un contenant, tel qu'un coffre. Elles ne sont pas prises en compte, méfiez-vous ! C'est certainement parce-que l'item placé est considéré comme une instance. Ce n'est pas pratique du tout.

Par contre, pas de souci en jeu, on peut déposer un item avec variables éditeur dans un coffre et le récupérer sans perdre les valeurs, heureusement.

Ceci dit, je suis un peu étonné en lisant ce fil que l'enregistrement des variables locales dans les .BIC soit passé si discrètement. Je me permet de vous renvoyer sur un des premiers posts du forum Bioware dans lequel on découvre et on discute de de ces variables locales "permanentes" (ça date de début décembre 03). Il y a des remarques plutôt pertinentes, et des idées intéressantes (notez celles de Papillon en page 2, qui défend son système, NWNX). C'est ici !

Comme l'a si bien dit Azmathiel plus haut, je ne pense pas qu'il y ait une solution de permanence idéale tant les modules ont des objectifs et des fonctionnements différents. En ce qui me concerne et au jour d'aujourd'hui, je ne m'oriente pas sur l'utilisation des seules variables locales sur BIC, NWNX offrant tout de même une flexibilité dans la gestion globale des données qui me semble incontournable. En tout cas, il n'y a que l'embarras du choix à présent, et il suffit de définir clairement le fonctionnement de son module pour choisir le système de permanence le plus adapté, non ?

[Azmathiel]

Je n'avais, pour ma part, pas connaissance de ce sujet, ni d'ailleurs de développements allant dans ce sens. Je reste aussi content d'avoir mis le doigt dessus par moi-même.
Toutefois, je constate en lisant ce fil sur le forum Bioware que le monde reste peuplé de sceptiques
Là-bas, c'est l'excellent Rich Dersheimer, le papa du système de persistance par Tag, qui a mis tout le monde d'accord grâce à ses petits tests à deux sous, et ça ne m'étonne pas. Il est normal qu'en suivant des pistes de systèmes simples, il ait poussé dans ce sens.
Ce décalage de plus de 6 mois entre le monde anglophone et le reste du monde est toujours aussi pathétique. Mais ça prouve une chose, on est pas plus con qu'eux

Pour revenir aux systèmes de persistance:
Il n'y a maintenant vraiment que l'embarras du choix. Le plus simple étant ce système-ci, mais pour ceux qui veulent aller plus loin et gérer pléthore de choses, les bases offrent des moyens incontournables même si personnellement, je ne vois pas ce qu'on peut faire de plusieurs paquets de 10000 variables
J'en sauvegarde une quinzaine, tout au plus, pour chaque personnage, pour un système parfaitement persistant, plus quelques unes ayant trait à des quêtes que je souhaite traçables également.
J'ai fait des tests sur les fichiers .bic dont il est notamment question dans le fil du forum Bioware, ils ne prennent pas d'embonpoint démesuré avec l'utilisation d'un objet d'inventaire supportant des variables. Un fichier de personnage de référence sans l'objet faisant environ 5,02ko, celui contenant l'objet, pour le même personnage, en fait 10,5 et 60,5ko, mais ça semble dépendant de l'endroit où il se trouve plutôt que des variables. Il passe en effet par 60,5ko pour retomber ensuite à 10,5. (cf ma quinzaine de variables type "int" et "location". L'inventaire de la référence ne change pas pendant les tests). Un personnage avec un inventaire bien garni, et le même objet supportant les variables a un fichier .bic atteignant les 98ko. Ce n'est pas la mort surtout par rapport au gain de temps obtenu en n'ayant pas les accès permanents aux tables que j'avais avant malgré les ruses de sioux employées (codification sur une chaîne de caractères, accès non massifs et lors de moments non cruciaux etc).

On pourrait résumer en disant: "Faites vos jeux ! Rien ne va plus comme avant !"

[Garrath]

Je dois dire que perso je me suis absolument pas pose la question sur la persistence de variables que je posais sur un Item avant de lire ce thread (ouf ca marchait tout seul ).
Ca marchait directement sans avoir a me poser le pb (j'ai attendu d'avoir la 1.62 pour commencer a m'y mettre )

Perso je trouve qu'il y a des choses à prendre et a garder dans les 2 systemes.
Des choses plus facile a faire avec l'un et d'autre avec l'autre mais bon...
Quand au temps a la rapidite d'execution etc... je dois dire que ca doit etre mis en balance avec la facilite d'utilisation, les modifications dynamique etc...
Les bases de donnees non pas ete faite pour etre plus rapide que des donnes en memoires . Mais pour faicliter la recherche de donnees, pour que les donnees soient facilement modifiables sans etre obligees de passer par le prg... (je suis entrain de penser a rentrer certain dialoques direct en base pour pouvoir les modifier sans etre oblige de recompiler le module etc... a gerer des zones a climat tres froid etc... que jepourrais modifier en ligne etc...) ce que tu perds en rapidite tu le gagnes en flexibilites

Bon apres faut voir aussi que plus t'as de memoires de libre mieux ca peut etre aussi ...

Enfin c pas le debat.

Bon par contre je remarque que l'on peut pas svg comme cela un objet (style item) en tout cas d'apres ce que j'ai lu sur le SetLocalObject. Ca c dommage... Donc je peux pas me passer de NWNX pour ce cas la...

['Az]

Citation :

Quand au temps a la rapidite d'execution etc... je dois dire que ca doit etre mis en balance avec la facilite d'utilisation, les modifications dynamique etc...

euh.... tout dépend pour quoi

quand il s'agit de gérer des grosses quantités de ressources dans de gros modules, c'est tout de même un paramètre non négligable (et je dirais même primordial)

[Garrath]

ben tu sais je pense que avec les machines qu'on a aujourd'hui c pas la chose primordiale... en plus a priori moins t'as de choses en memoires mieux c... on n'est pas a un pouilleme prets
tant que l'on fait pas d'acces sur plein de donnes sur NWNX sur le onheartbeat ca doit pas etre trop genant

A mon avis y a des choses qui au niveau de la programmation sont cent fois plus gourmands et qui pourtant ne choque personne...
Type l'appel d'une meme fonction avec les memes parametres plusieurs fois dans le code etc...
Meme le compilateur de NWN fait des choses pas super optimises (Torlak va falloir sortir la version HOU de ton compilateur )

Et puis un autre avantage de NWNX c que t'as base n'est pas forcement sur le meme poste (bon d'accord faut etre un peu plus riche ) Donc du coup moins de ressource memoire utilise que si t'as base est sur le meme PC, acces plus rapide sur la base si un PC bine configure et uniquement configure pour faire cela... perte d'un peu de temps pour la transmission reseau (mais bon relativmeent negligeable si les 2 PC sont au meme endroit physiquement sans avoir a passer par 15000 routeurs etc...)

Et faut toujours mettre en balance la rapidite d'execution et la facilite a maintenir, modifier sans avoir besoins de recompiler je peux t'assurer que c'est super top
Sinon on en serait encore a coder en assembleur

Moi par deformation professionnelle, j'aime bien pouvoir changer les comportements de mes codes sans avoir a modifier le code et a recompiler le tout
Mais apres tout depends comme d'habitude de l'usage qu'on en fait...
Sur un thread qui date un peu qui parlait de l'utilisation d'objet avec d'autre j'avais donne une methode qui permetait de pouvoir faire quasi ce qu'on voulait hautement parametrable... Cette methode que moi je trouvais bonne car je pouvais ajouter des items en enlever etc comme je voulais direct online n'etais pas forcement bonne pour la personne qui posait ca question vu que pour lui il voulait gerer qu'un seul item comme cela...comme avait signale je sais plus qui (dsl pas la memoire des noms) c'etait prendre une enclume pour ecraser une mouche

Donc tout depends de l'usage que l'on veut avoir... ce que l'on veut faire etc...
Et du coup je rejoins je sais plus qui qui disait que le systeme de persistance est qqchose de personnel à un module...

Y a des choses que moi je mettrais en base et que d'autre mettrons en local et vice versa

['Az]

Citation :

ben tu sais je pense que avec les machines qu'on a aujourd'hui c pas la chose primordiale... en plus a priori moins t'as de choses en memoires mieux c... on n'est pas a un pouilleme prets

ah bah voyons bien sur, on a des gros processeurs alors a t'en faire, ca va vite on va en profiter pour écrire de sales codes pour assouvir notre flemmardise. De toutes facon, tout le monde prend plaisir à se payer une nouvelle machine tout les ans afin de pouvoir suivre l'évolution, et ainsi financer des programmeurs qui fondent leur boulot sur cette philosophie.

Pourquoi windows 3.1 tournait il aussi bien sur les 486 de l'époque que windows XP tourne sur une bete de guerre actuelle ?

Personnelement je suis heureux de pouvoir faire de la bureautique sur mon vieux celeron 400 aussi bien que pourrait le faire une machine de guerre de la génération actuelle, il est malheureux que ca ne soit pas ainsi partout ailleur.....

Citation :

A mon avis y a des choses qui au niveau de la programmation sont cent fois plus gourmands et qui pourtant ne choque personne...
Type l'appel d'une meme fonction avec les memes parametres plusieurs fois dans le code etc...

venant d'un débutant, ca se comprend et c'est pardonnable.
venant d'un programmeur experimenté et/ou professionnel, c'est une honte.

Citation :

Sinon on en serait encore a coder en assembleur

oui d'ailleur il y a des personnes qui devrait se rappeler que l'assembleur s'utilise toujours, et fonctionne toujours très bien

ce message n'avait rien de particulier contre toi, c'est juste que j'en ai un peu par dessus la tête de cette idée que l'évolution doit être mis au profil des programmeurs plutot que des utilisateurs....
si tu veux en parler plus longement, j'accepterais avec joie une petite discution sur msn ou irc