[HOTU 1.62] Les systèmes actuels de persistance ont vécu !

Azmathiel · 10/05/2004, 17h08

Je viens de pousser mes tests sur les variables locales. Bioware a fait TRES fort !

Les variables sur les objets d'inventaire sont sauvegardées avec le personnage. Ce test a été réalisé sur un personnage de servervault et sur des variables de type affectable sous Aurora: string, int et float.

Ce qui implique pour moi que je laisse tomber les développements tournant autour de la Database Bioware pour me pencher plus avant sur un système de type nouveau basé sur ces variables: ultra rapide, et sans gestion lourde.
Pourquoi faire compliqué quand on peut faire archi simple ?

Mastokk · 10/05/2004, 17h19

Qu'est ce que tu entends par variable locale sur objet d'inventaire ?

Azmathiel · 10/05/2004, 17h27

Un objet d'inventaire est un objet quelconque qu'on peut mettre dans l'inventaire du PJ. Genre épée, armure, divers...

Sur ces objets, on peut affecter une variable locale comme sur les objets plaçables ou les personnages.
Or, ces objets sont sauvegardés en même temps que le personnage. Et je viens de le tester, les variables des types précités le sont aussi. Joli, non ?

Mastokk · 10/05/2004, 17h36

Ha ça c'est clairement super en effet

. En plus tu m'apprends un truc, j'avais jamais mis de variable sur un objet d'inventaire, ça pourra me servir

.

puchiko · 10/05/2004, 17h44

parce que ca pompe de la RAM et que lorsqu'un objet passe chez le marchand, il perd ses variables ..

bref, c'est 'sympathique' pour les objets non vendables, et sur les variables souvent accédées ..

'Az · 10/05/2004, 19h27

Vivi ca fait parties des trucs pour lequells j'attendais HotU (ou plutot le patch qui l'accompagne).

Adieux les systèmes de persistances compliqués et prise de tête, bienvenue a la simplicité

Azmathiel · 10/05/2004, 19h36

Citation :

Provient du message de Azrael07

Adieux les systèmes de persistances compliqués et prise de tête, bienvenue a la simplicité

Enfin quelqu'un qui me comprend !

B L I N G ! · 10/05/2004, 20h03

auriez vous un exemple en tête concret ?

je me doute que ce système doit apporter pas mal d'améliorations.

mais ne reste-il le même problème lors d'un reboot du module les variable affecter aux objets reprendront leurs valeurs par défaut non ?

Rhyghar · 10/05/2004, 20h52

Peut-on acceder a la variable d'un pj quand celui ci n'est pas connecté ?

'Az · 10/05/2004, 21h46

Citation :

mais ne reste-il le même problème lors d'un reboot du module les variable affecter aux objets reprendront leurs valeurs par défaut non ?

bien justemenet, les variables affectées aux personnages joueurs seront conservée après leur déconnection, et même après un reboot du serveur. D'où tout l'interet ^^

Citation :

Peut-on acceder a la variable d'un pj quand celui ci n'est pas connecté ?

bien avec une base de donnée oui, mais pas si tu utilise simplement ce système tout seul

Azmathiel · 10/05/2004, 21h51

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 forcément à accéder à ces données, puisqu'elles s'y trouvent.
Reste à développer les outils pour le faire. Mais ça, ce n'est pas mon rayon. Je ne suis qu'un amateur qui n'a aucune envie de s'aventurer sur les techniques de décorticage des fichiers pour l'instant. Pour le faire, il faudrait étudier la structure des fichiers .bic et retrouver dans ces fichiers des données type stockées exprès pour faire les recherches. 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.
Cela dit, ça ne fait pas partie de mes priorités immédiates car je pense recourir à une table pour gérer la seule chose externe au jeu qui m'intéresse: afficher les joueurs connectés sur un site web.

'Az · 10/05/2004, 21h57

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 forcément à accéder à ces données, puisqu'elles s'y trouvent.
Reste à développer les outils pour le faire. Mais ça, ce n'est pas mon rayon. Je ne suis qu'un amateur qui n'a aucune envie de s'aventurer sur les techniques de décorticage des fichiers pour l'instant. Pour le faire, il faudrait étudier la structure des fichiers .bic et retrouver dans ces fichiers des données type stockées exprès pour faire les recherches. 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.
Cela dit, ça ne fait pas partie de mes priorités immédiates car je pense recourir à une table pour gérer la seule chose externe au jeu qui m'intéresse: afficher les joueurs connectés sur un site web.

euh... je suis en train de bosser la dessus.
j'avais pas vraiment prévu d'en faire une version publiée, mais si ca interesse quelqu'un, qu'il me le fasse savoir, je pourrais essayer de trouver un moment pour en faire une version open

la prise en compte des variables locales enregistrée dans les fichiers .bic n'est pas vraiment prévue, mais pour une version superieure peut être

Rhyghar · 10/05/2004, 22h04

Citation :

Provient du message de Azrael07
(snip)
bien avec une base de donnée oui.
(snip)

Hmm...

Kétil Dimzad · 10/05/2004, 22h11

*pioup*

J'appui sur "pause" un moment histoire d'avoir bien compris.

Vous êtes entrain de nous dire que les variables locales ( LocalInt LocalFloat LocalString etc... ) stockées sur un objet d'inventaire d'un joueur ne s'effacent QUE si un script les effacent ( avec DelelteLocalXXX )??? C'est bien ça ? Et que les reboots du module et déco du joueur ni changeront jamais rien ?

)))))))))))))

Donc en clair ça remplace les LocalCampaign ?

Parce que a priori, on pourrait créer un objet de la taille d'une case d'inventaire dans l'inventaire du joueur lors de la première connexion, faire de cet objet qu'il soit indropable et indéplaçable et ainsi stocker tout ce que l'on veut là dessus comme par exemple :

La persistance de localisation du Pj lorsqu'il quitte et rejoins le module ?

Les pts de vies ?

etc....

En clair, remplacer complètement la BDD de bio et les autres trucs hyper compliqués ?

Dites moi si je me gourre mais c'est génial ce truc oO

Azmathiel · 10/05/2004, 22h14

Oui Ketil, c'est exactement ça. J'ai testé sur d'autres types de variables depuis et ça fonctionne !

Kétil Dimzad · 10/05/2004, 22h16

C'est.....

MORTEL

'Az · 10/05/2004, 22h21

bah voila c'est justement ce qu'on disait

Sherazade · 10/05/2004, 22h26

Très intéressant

.

Tu as bien fait tous tes tests en fermant le serveur et en le ré-ouvrant, ça parait trivial mais je demande quand même à tout hasard. En effet, tant que le serveur n'est pas fermé toutes les variables locales au personnage, et à ses objets in extenso, sont conservées. Par contre, je ne savais pas que les Localxxx étaient conservés directement dans les .bic.

Si c'est bien le cas, c'est excellent

.

Un bémol quand même : ne pas stocker trop de données sur un même objet, les fonctions de hachage de NwN sont très mauvaises. J'avais fait des tests sur dix milles données locales et leur accès est plus lent que les accès MySQL via NWNX.

Terremer · 10/05/2004, 22h31

Citation :

En clair, remplacer complètement la BDD de bio et les autres trucs hyper compliqués ?

Heu ?
La gestion de la BDD est si mauvaise que cela ?

Une question:
Il me semble qu'un système similaire (avec des objets d'inventaire était utilisé) avant Sou. et la BDD
Donc c'est un peu un retour en arrière là non ?

Rhyghar · 10/05/2004, 22h35

Bon...
Je n'ai pas testé alors je peux me tromper mais je doute que l'inventaire d'un pj soit sauvé lors d'un crash serveur (un reboot normal oui, mais pas un crash). Pour avoir eut pendant longtemps un serveur qui tournait sur un pc portable, j'avais régulierement des gens qui perdaient des niveaux qu'ils avaient gagnés dans la partie précédant le crash.

De plus, Azrael m'a répondu qu'il fallait utiliser une base de donnée pour acceder à une variable stocké dans l'inventaire d'un pj qui n'est pas connecté (on utilise une DB pour acceder au remplaçant de la DB !).

Je pense donc que ce systeme ne sera utilisé que pour des taches bien précise où la rapidité est nécéssaire (et les données pas trop cruciales). Mais de toute facon, acceder a ces données sera toujours plus compliqué que de faire un SetCampainXXX.

'Az · 10/05/2004, 22h49

Citation :

Un bémol quand même : ne pas stocker trop de données sur un même objet, les fonctions de hachage de NwN sont très mauvaises. J'avais fait des tests sur dix milles données locales et leur accès est plus lent que les accès MySQL via NWNX.

alors tu propose quoi ? effacer toutes les variabels locales a la déco ?

le format GFF n'a rien a voir avec le format de base de donnée. Quoi que tu fasse, elle seront mise en ram au chargement du joueur, et leur mise en ram ne prendra pas plus de temps que n'importe quel transfert de ressource

et si après ca nwnx est encore plus rapide, bah autant rayer de la liste de tes fonctions les Set/GetLocal* pasqu'elles iront pas plus vite

Citation :

Je n'ai pas testé alors je peux me tromper mais je doute que l'inventaire d'un pj soit sauvé lors d'un crash serveur (un reboot normal oui, mais pas un crash). Pour avoir eut pendant longtemps un serveur qui tournait sur un pc portable, j'avais régulierement des gens qui perdaient des niveaux qu'ils avaient gagnés dans la partie précédant le crash.

je suppose qu'il y a des sauvegardes régulières des personnages.
c'est facile a vérifier : est ce qu'un passage de niveau est pris en compte après un crash server ? les variables en questions sont soumises aux même règles

Azmathiel · 10/05/2004, 22h53

Il existait deux systèmes majeurs:
ceux basés sur les tokens (billes de fronde et autres objets d'inventaire). L'incovénient de celui-là, c'est qu'un roublard pouvait tirer les billes avec sa fronde

L'autre reposait sur les Tags des objets de l'excellent Rich Dersheimer et de son "Rich_Dersheimer1045629153263Persist". Son inconvénient venait de la limitation à 32 caractères.

Là, on s'affranchit de toutes ces limitations.

Je suis sûr que dans pas longtemps, on va avoir des outils pour explorer les .bic et en extraire ce qu'il faut pour ceux que ça intéressera.

@Sherazade: oui oui, rassure-toi

.
Et ça marche même en utilisant un personnage du servervault dans une partie sans serveur lancée en autonome.
Donc, on peut même tester en autonome, à condition de prendre un personnage du servervault, bien sûr, ou encore un autre (local) si on le sauvegarde avant de quitter

Sherazade · 10/05/2004, 22h58

Citation :

Provient du message de Azrael07
alors tu propose quoi ? effacer toutes les variabels locales a la déco ?

Non, mais pour ma part, je les disperse à plusieurs endroits

. Mieux mettre 1000 variables sur 10 objets que 10000 variables sur un seul objet. La différence de traitement est vraiment très sensible.

Citation :

et si après ca nwnx est encore plus rapide, bah autant rayer de la liste de tes fonctions les Set/GetLocal* pasqu'elles iront pas plus vite

Oui, c'est ce qui se fait sur un serveur bien connu à ce que j'ai pu comprendre de mes discussions avec son principal administrateur. Reset des Get/SetLocal et uniquement des Get/SetPersistent dès que les données sont nombreuses.

'Az · 10/05/2004, 23h16

Citation :

Non, mais pour ma part, je les disperse à plusieurs endroits . Mieux mettre 1000 variables sur 10 objets que 10000 variables sur un seul objet. La différence de traitement est vraiment très sensible.

voui tout a fait, mais ca m'étonnerais que t'ais 10000 variabels a enregistrer sur ton joueur

Citation :

Oui, c'est ce qui se fait sur un serveur bien connu à ce que j'ai pu comprendre de mes discussions avec son principal administrateur. Reset des Get/SetLocal et uniquement des Get/SetPersistent dès que les données sont nombreuses.

euh..... la y'a des limites. Je veux bien croire que le nwnx soit plus rapide que la dbase bioware, ok, mais que des données destinées a entrer dans une base de donnée a format complexe surpasse la vitesse de transfert de données indiquées en ram et liées par des listes chaines d'une vitesse redoutable, la c'est pas la peine d'essayer de me convaincre

j'ai étudié le format .gff en détail, je sais parfaitement comment il est exploitable, et comment il est exploité, et je sais pertinemment comment fonctionne une base de donnée sql.

Je ne prend aucun risque en affirmant que ton administrateur se trompe. Les benchs qu'il a fait, ou prétendu avoir fait, sont basée sur des données corrompues ou totalement innapropriées a des tests nwn.

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.

Outre cela, je suis catégorique, ou alors je ne sais plus programmer

Malicene · 10/05/2004, 23h21

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

Mastokk Alpha & Oméga	Qu'est ce que tu entends par variable locale sur objet d'inventaire ?
10/05/2004, 17h19

Azmathiel Alpha & Oméga	Un objet d'inventaire est un objet quelconque qu'on peut mettre dans l'inventaire du PJ. Genre épée, armure, divers... Sur ces objets, on peut affecter une variable locale comme sur les objets plaçables ou les personnages. Or, ces objets sont sauvegardés en même temps que le personnage. Et je viens de le tester, les variables des types précités le sont aussi. Joli, non ?
10/05/2004, 17h27

Mastokk Alpha & Oméga	Ha ça c'est clairement super en effet . En plus tu m'apprends un truc, j'avais jamais mis de variable sur un objet d'inventaire, ça pourra me servir .
10/05/2004, 17h36

puchiko [A-M]	parce que ca pompe de la RAM et que lorsqu'un objet passe chez le marchand, il perd ses variables .. bref, c'est 'sympathique' pour les objets non vendables, et sur les variables souvent accédées ..
10/05/2004, 17h44

'Az [P.H.] Alpha & Oméga	Vivi ca fait parties des trucs pour lequells j'attendais HotU (ou plutot le patch qui l'accompagne). Adieux les systèmes de persistances compliqués et prise de tête, bienvenue a la simplicité
10/05/2004, 19h27

Azmathiel Alpha & Oméga	Citation : Provient du message de Azrael07 Adieux les systèmes de persistances compliqués et prise de tête, bienvenue a la simplicité Enfin quelqu'un qui me comprend !
10/05/2004, 19h36

B L I N G ! Prophète	auriez vous un exemple en tête concret ? je me doute que ce système doit apporter pas mal d'améliorations. mais ne reste-il le même problème lors d'un reboot du module les variable affecter aux objets reprendront leurs valeurs par défaut non ?
10/05/2004, 20h03

Rhyghar Prophétesse	Peut-on acceder a la variable d'un pj quand celui ci n'est pas connecté ? __________________ ..::Heavenlynet le net paradisiaque ::..
10/05/2004, 20h52

Rhyghar Prophétesse	Citation : Provient du message de Azrael07 (snip) bien avec une base de donnée oui. (snip) Hmm... __________________ ..::Heavenlynet le net paradisiaque ::..
10/05/2004, 22h04

Azmathiel Alpha & Oméga	Oui Ketil, c'est exactement ça. J'ai testé sur d'autres types de variables depuis et ça fonctionne !
10/05/2004, 22h14

'Az [P.H.] Alpha & Oméga	bah voila c'est justement ce qu'on disait
10/05/2004, 22h21

Terremer Alpha & Oméga	Citation : En clair, remplacer complètement la BDD de bio et les autres trucs hyper compliqués ? Heu ? La gestion de la BDD est si mauvaise que cela ? Une question: Il me semble qu'un système similaire (avec des objets d'inventaire était utilisé) avant Sou. et la BDD Donc c'est un peu un retour en arrière là non ?
10/05/2004, 22h31

Malicene Légende	et la version open, on peut espérer la voir ?
10/05/2004, 23h21

[HOTU 1.62] Les systèmes actuels de persistance ont vécu !

Connectés sur ce fil