NWN - Maskado

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

Répondre
Partager Rechercher
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 ?
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 ?
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 ..
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é
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 ?
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
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.
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
*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
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.
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 ?
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.
__________________
..::Heavenlynet le net paradisiaque ::..
http://gw.heaven-ly.net/images/stories/divers/sigfg042.gif
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
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
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.
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
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés