sauvegarde des personnages

Répondre
 
Partager Rechercher
Je cherche à faire un script pour un module persistant ou semi-persistant (je ne connais pas la différence) qui sauvegarde toutes les 30 minutes les personnages (et pas le reste). On m'a parlé de la fonction : ExportAllCharacters() mais je ne comprend pas bien comment elle marche (et comment la tester avant de la mettre sur le module).
J'ai pensé en premier la mettre dans un DelayCommand, mais il demande un argument de type action, or ExportAllCharacters retourne void.
Pensez vous que sa puisse fonctionner malgré cela ? Par exemple, dans le OnModuleLoad mettre :
DelayCommand(1800.0 , ExportAllCharacters());

Dans le doute, je me suis rabattu sur le OnHeadBeat, mais vous savez que cela pose des problèmes de ressources pour le serveur. J'ai pensé faire :
Dans le OnModuleload :
SetLocalInt(OBJECT_SELF, "auto_save_PJ", 0);

Dans le OnHeartBeat :
Code PHP:

void main() {
    // Intervale entre chaque sauvegarde en round (1 round = 6 secondes)
    int nTime = 300;
    object oModule = GetModule();
    int nCompteur = GetLocalInt(oModule, "auto_save_PJ") + 1;
    SetLocalInt(oModule, "auto_save_PJ", nCompteur);
    if(nCompteur == nTime) {
        SetLocalInt(oModule, "auto_save_PJ", 0);
        ExportAllCharacters();
    }
} 
D'aprés vous, cela est-il gourmand en ressources ?

Avez-vous d'autres moyens d'utiliser ExportAllCharacters ? Ou une autre fonction similaire ?
Merci pour toute l'aide que vous pourrez m'apporter.
Lien direct vers le message - Vieux 10/04/2003, 22h23
Toute fonction retournant "void" peut-être employée dans un DelayCommand(), fais donc une fonction récursive qui, lancé dans ton OnLoad se rappellera toutes les 30 min et exécutera ExportAllCharacters().
Lien direct vers le message - Vieux 10/04/2003, 22h32
Citation :
Provient du message de Jedaï
Toute fonction retournant "void" peut-être employée dans un DelayCommand(), fais donc une fonction récursive qui, lancé dans ton OnLoad se rappellera toutes les 30 min et exécutera ExportAllCharacters().
Autrement dit, dans le onModuleLoad :

Code PHP:

void sauvegarde(){
    ExportAllCharacters();
    DelayCommand(1800.0, sauvegarde());
}

void main(){
    DelayCommand(1800.0, sauvegarde());
} 
Ou un truc du genre *trop fatigué pour tester now*
Par contre je n'ai aucune idée de ce que fait cette fonction !
Elle sauvegarde quoi exactement des persos ?
Elle fait apparaitre l'écran de sauvegarde ?
Lien direct vers le message - Vieux 10/04/2003, 23h17
A priori, si elle fait ce qu'elle dit, elle exporte les characters ...


C'est a dire que c'est sans interet sur un ServerVault...

A priori. C'est non testé, mais je le vois bien comme ca.
Lien direct vers le message - Vieux 11/04/2003, 10h06
Citation :
Provient du message de Jaha Effect
J'ai testé et c'est en effet sans aucun intérêt sur un serveur vault, il exporte même pas le journal.

Jaha Effect
Ca dépend, les personnages ne sont sauvegardés qu'a la deco. En cas de plantage du serveur, les joueurs se retrouvent avec leurs pj dans l'etat ou il etait a leur dernière deco, ce qui est pas super top s'ils etaient en train de jouer dpeuis 2-3h.
Lien direct vers le message - Vieux 11/04/2003, 13h18
La description précise pourtant cela :
Citation :
// Force all the characters of the players who are currently in the game to
// be exported to their respective directories i.e. LocalVault/ServerVault/ etc.
void ExportAllCharacters()
Lien direct vers le message - Vieux 11/04/2003, 17h04
Oui, gaeriel a raison, il parle du ServerVault dans la description de la sauvegarde.
Le module sur lequel je veux l'implanter est en effet un ServerVault. Et c'est justement pour éviter des sauvegardes de tout le module (ce qui est long) que je voudrais utiliser cette fonction.

Petite question auxiliaire : pendant la sauvegarde normale, le jeu est-il mis en pause ?
Lien direct vers le message - Vieux 11/04/2003, 20h24
Surement du a ta connexion, je n'ai jamais eu de probleme de ce type apres une sauvegarde.

Les deux gros bugs de la sauvegarde serveur sont :
- si ca sauvegarde pendant que tu chargeais une zone, tu gagnes le droit de relancer le jeu
- pas mal de choses sont très mal sauvegardées, notament les rencontres : toutes les rencontres qui étaient inactives au moment de la sauvegarde ne respawneront plus apres chargement
Lien direct vers le message - Vieux 12/04/2003, 16h17
Désolé de déterrer un truc enterré aussi profondément. J'en ai d'ailleurs brisé ma pelle +4 ! (impossible de lancer des recherches s'il y a plus de 800 connectés sur le forum JoL ). Mais ce sujet m'intéresse beaucoup.

La sauvegarde automatisée d'un serveur est pénible au possible.
N'y a-t-il pas un autre système plus pratique et qui ne plante pas les joueurs pendant les passages de zones ?

Quelqu'un utilise sûrement autre chose, non ?

Et cette fonction ExportAllCharacters(), elle ne fait pas ce qu'elle est sensée faire ?
Pourtant, si on se réfère à cette FAQ:
http://nwvault.ign.com/kb/data/Maxim...3tITaNBE.shtml
il semblerait que ce soit ce qu'il est conseillé d'utiliser...

Et celle-ci est peu compréhensible... Enfin, pour moi:
http://nwvault.ign.com/kb/data/BWrig...dXW8V7jx.shtml
Lien direct vers le message - Vieux 05/08/2003, 14h43
Au contraire : elle fait exactement ce qu'elle est censé faire : elle exporte le chara loin du serveur jusqu'a ton local vault. Il ne sera donc pas reutilisable sur le module si celui ci n'accepte pas le serveur vault.


La meilleur solution pour un Monde persistant, c'est de sauvegarder a la main ce qui interesse, en utilisant la BDD de la 1.31 (a venir sous peu en VF)
Lien direct vers le message - Vieux 05/08/2003, 14h47
je profite de ce post pour ......

J'aimerais l'avis de ceux qui s'y connaissent.
Pourrais ton me donner le Pour et le Contre de chaque systèmes de persistances

je sais pas quoi choisir

la 1.30 ?

NWNX2 ?

PUMA ?

autres SPWUM ?

Bien entendus je suis pas un expert en informatique et voudrais quelque chose de simple d'utilisation, mais aussi tant qu'à faire de performant (je sais j'en demande beaucoup )

Merci de vos réponses

Lien direct vers le message - Vieux 05/08/2003, 17h06
Bon avec tout ça moi je n'ai pas bien compris c'est possible ou pas ?

Si je me réfère au module Cendres de Lunen c'est possible, exportation du perso de fais a chaque seconde sur le serveur, comme ça, en cas de plantage, on perd une ou deux secondes de jeu tout au plus.

Quelqu'un aurait le script par hasard ?
Lien direct vers le message - Vieux 06/08/2003, 03h37
Bein, si tu as besoin de sauvegarder des objets, seul la 1.30 le fait. Pour le reste, le PUMA est tres bien, et represente un bon complement de la 1.30, mais n'est plus forcement obligatoire.
Lien direct vers le message - Vieux 06/08/2003, 10h56
Vous connaissez tous mon point de vue sur les differents systemes de svg : NWNX2 forever.

Et en effet, il faut svgd Pts de vie, Or, Journal, location et XPs dans une BDD. Si tu cherches ce genre de truc, va sur le Vault, il en est plein de ces scripts. Pour le passage d'uin mod a un autre, et ben ils utilisent les memes tables pour faire ca qu'ils se partagent. (je crois que seul NWNX2 peut le faire ca, et hop, encore un point pour Papillon son createur!)

Prince Nexus, lu et approuve !
Lien direct vers le message - Vieux 08/08/2003, 15h56
J'ai bien lu le test qu'avait réalisé Jaha en son temps sur la BdD Bioware, mais je n'ai pas bien compris ce qui était possible ou non avec cette base. Personnellement, je n'ai pas encore la version 1.30, d'abord parce que je ne sais pas où la trouver et ensuite, parce que je préfère attendre la version officielle et francisée.
J'ai également lu des articles et interviews sur le travail de Papillon et de ses amis et je connais le système de stockage par tokens (mais il met les serveurs à genou). Il me semblait clair que la solution standard Bioware devait rester privilégiée pour des raisons de développement, de compatibilité et de documentation futurs, MAIS...

Il y a donc, d'après Prince Nexus des choses infaisables avec la BdD de Bioware ? Lesquelles ?


Pour l'instant, ce que j'ai à stocker, je le stocke dans les TAGs d'items spéciaux, (grâce à une idée de Rich Desheimer qui avait fait une étude sur le stockage des skills dans un TAG de livre, trouvée sur le Vault. Je le remercie vivement au passage), et ça semblait suffisant pour mes besoins immédiats, mais je dois avouer que je n'ai pas pensé, à l'origine, au journal et SURTOUT, aux variables locales stockées provisoirement sur le PJ, et un système de coffres permanents me semblerait des plus intéressant aussi.

Mon avis était, avant, que le système qui permettrait de stocker les variables locales serait celui que j'adopterai, mais pour les coffres et autres babioles, c'est nettement insuffisant maintenant.
Donc, le système idéal, à mes yeux, doit offrir des commandes simples permettant de stocker à la volée (et fréquemment, sans surcharge importante du système) les variables locales, les objets avec leur position et leur contenu, le journal complet, et bien sûr, des commandes simples pour restaurer tout ça au bon endroit et au bon moment, le tout accompagné d'une robustesse de code sans faille (FoxPro me semblait éprouvé comme structure, non ?)


Donc pour résumer:

1) Quel système sait stocker à la volée les variables, les objets+contenu+position, le journal ?

2) Quel système a des commandes claires, facilement utilisable ?

3) Quel est le système apparemment le plus robuste ?



Si ceux qui ont éprouvé tel ou tel système pouvaient éclairer nos lanternes un peu plus sur le sujet, sans forcément passionner le débat, je crois que nous y verrions tous plus clair.

Merci par avance.
Lien direct vers le message - Vieux 08/08/2003, 17h01
Hop là, j'arrive pour donner mon avis (après une semaine de vacances, faut bien se remettre dans le bain)

1/ le "stockage à la volée "dont tu parles, ben je pense que ça dépend plus du script que du moyen de sauvegarde; sur ce point là je dirais ex-aequo les 3 systèmes. Par contre, aucun n'est capable de stocker le journal.

2/ là, pas d'hésitations, c'est l'avantage majeur du système de Bioware : au lieu d'utiliser SetLocalMachin, tu utilise SetCampaignMachin et le tour est joué. Il n'y a absolument aucune configuration nécessaire, simplement installer la 1.30
NWNX2 est sûr ce point moins accueillant je crois (à commencer par les histoires de base de donnée), c'est d'ailleurs une des raisons pour lesquelles je n'ai jamais pris la peine de le tester.
Quant au PUMA, ben l'installation se fait le plus simplement du monde, et des fonctions sont tout prêtes; l'utilisation n'est donc pas immédiate mais très simple quand même

3/ Hmm, là j'aurais du mal à donner des détails. A première vue, je dirais que SQL est plus solide que FoxPro, mais honnêtement ce dernier ne m'a jamais posé aucun réel problème. Y'a juste un truc qui me dérange : il faut à chaque fois "packer" la BDD une fois qu'on y supprime des entrées. C'est pas la mort mais je trouve ça un peu archaïque
Par contre NWNX2 affecte moins la rapidité du jeu, puisqu'il tourne en parallèle du jeu.
Le PUMA est lui à 100% fiable je pense, malgré les quelques défauts du launcher Et au niveau des ressources, il bat à plate couture les deux autres systèmes puisqu'il ne fait qu'écrire des lignes dans le log.


Pour conclure, c'est à toi de choisir le système qui te convient le mieux. Je te conseille légèrement le système de Bio, mais il n'est malheureusement pas exempt de défaut , principalement la consommation en ressources et le format de BDD pas très pratique si on veut l'exploiter hors du jeu ou sur plusieurs serveurs.
Lien direct vers le message - Vieux 08/08/2003, 17h37
Je vais essayer de repondre a ces questions, car je crois que bcp me sont indirectement adressees.

En ce qui concerne la BDD Bioware, son defaut, c'est qu'elle est attachee au jeu. Je m'explique, comme le disait Grognon, lorsqu'un joueur debarque sur un module et que tu lui fais des AssignCommand (script OnEnter du module), seules celles qui s'enclenchent apres le chargement complet du joueur pourront etre executer. Tu me diras, j'ai qu'a faire des DelayCommand et ensuite c'est bon. Ca l'est en effet si tu connais exactement le temps de chargement d'un joueur sur ton module sachant qu'il est plein et qu'il peut montrer des defaillances qd au lag....

Deuxieme point contre la BDD Bioware : elle est attachee au jeu (et oui encore !). Et ca ca lui donne une bonne raison en plus de planter : si c'est pas le jeu qui crache, ca peut etre la BDD, dont le crash entraine des gros disfonctionnement du jeu, car toute BDD n'est malheuresement pas infaillible.

Maintenant, revenons a ce qui marche bien : NWNX2. Son gros defaut, c'est qu'il existe encore trop d'irreductibles gaulois qui ne l'ont pas adoptee !
Plus serieusement : elle n'est pas attachee au jeu, donc si elle plante, le jeu peut continuer a marcher et il n'y a pas ces problemes de DelayCommand sur le OnEnter.

Mais surtout, avec MySQL, tu disposes d'une des BDD les plus robustes du monde, qui plus est elle te coutera 0.00Euro. Tu a acces a une bibliotheque de fonctions tout simplement extraordinaires. De celles pour avoir l'heure IRL a des fonctions mathematiques sur le temps plus avancees que Bioware ne te donnera jamais, avec MySQL, rien n'est impossible.

Enfin et surtout, MySQL, c'est les requetes,des requetes croisees entre plusieurs DB. Bioware ne vous donnera jamais une liste de tous les joueurs dont le level est entre 3 et 5 et qui ont plus de 10 points de vie et qui sont dans l'area1 ou l'area2....
Bon c'est vrai que ca peut sembler inutile vu comme ca, mais ceux qui font des modules serieux avec plus d'une dizaine de table ont tres vite compris l'interet de ce truc.

Donc concretement, avec NWNX2 couple avec MySQL et les fichiers de FastFrench pour accelerer les requetes au cas ou tu trouverais que c'est trop lent (!??!), tu peux sauver tout et n'importe quoi, journal (Taern, tu es mal informe), heure d'entree sur le shard, heure de sortie du shard, duree passee sur chaque zone par le joueur, la location, ses points de vie, son inventaire ... Tout sauf un truc : les objets qui ne sont pas definis dans ton module, la y a que Bioware qui peut le faire. Mais bon, ce truc ne concerne que les serveurs qui sont en localvault, donc des modules pas serieux.

Pour terminer, il existe des detracteurs de NWNX2, mais bon c'est tjs les memes : ceux qui parlent sans l'avoir teste. Il a eu des pbs dans le temps, mais comme on dit, Rome ne s'est pas fait en un jour, et maintenant, les defauts ont ete rectifies et ca marche au poil.

A present fais ton choix, si tu construis un module pour 20 personnes et que tu ne connais rien au language SQL, choisis BioWare. Sinon...

Prince Nexus

Edit pour Taern : je me suis trompe de ligne en ecrivant, en fait NWNX permet bien la sauvegarde du journal (un simple int en fait...)

pour RAT: Oui NWNX2 permet la sauvegarde des objets, notant leurs tag et resref dans une table concue specialement pour, alors plus d'hesitation, passons a NWNX2....
Lien direct vers le message - Vieux 11/08/2003, 09h38
Citation :
Provient du message de Prince Nexus
son inventaire (Taern, tu es mal informe)
Euh, pourquoi ça ? Je me doute quand même un peu que NWNX est capable de sauvegarder les resref des objets. Ce qu'il n'a pas, c'est la fonction StockObject, mais comme tu dis c'est pas vraiment utile dans le cas de serveurs persistants en servervault.

Sur le plan des possibilités, de toutes façons NWNX bat à plate couture les autres systèmes. Mais je reste convaincu qu'à moins d'avoir vraiment besoin d'une bdd MySQL, le Puma ou la 1.30 reste les meilleurs choix.
Lien direct vers le message - Vieux 11/08/2003, 12h32
Ba pour ma part, je sais que le NWNx est pas mal du tout sur la gestion de loc.

Par contre, pour la save des objets dans les coffres, il n'est pas au top, comme il ne gère pas les stack, pe qu'avec la v2, il a changé cela .

Sinon, le seul système qui gère les loc et aussi la sauvegarde de tous les items dans un coffre en comptant les stack c'est le PUMA et la bdd bioware, avec le script que j'ai fais sur la bank.

La version pour le puma, gère tous les items excepté ceux qui viennent d'un autre shard, normal comme je récupere le resref.

La version db bioware, v2 fait la mm chose que le puma avec des petits correctifs. Et quand je trouverai enfin le temps à faire ma v2.3, il y aura d'autres correctifs, sauvegarde des objets soit avec le resref soit avec le type object, et le preteur sur gage que j'avais promis il y a fort longtemps à notre jaha national

Voila

Mon avis

PS:Je voudrais juste rappeler que cela serait super simple de faire la gestion de journal autant sur PUMA que sur la db bio mais bon je dis juste ça comme ça . On peut trouver bcp de possibilités avec tous les systèmes, il faut juste 3 choses importantes: l'imagination, ne pas avoir peur de bidouiller, et de la volonté car souvent on peut craquer quand on voit pas le bout.



RAAZ Touch au passage
Lien direct vers le message - Vieux 11/08/2003, 12h44
Citation :
Provient du message de Taern


3/ Hmm, là j'aurais du mal à donner des détails. A première vue, je dirais que SQL est plus solide que FoxPro, mais honnêtement ce dernier ne m'a jamais posé aucun réel problème. Y'a juste un truc qui me dérange : il faut à chaque fois "packer" la BDD une fois qu'on y supprime des entrées. C'est pas la mort mais je trouve ça un peu archaïque
Par contre NWNX2 affecte moins la rapidité du jeu, puisqu'il tourne en parallèle du jeu.
Le PUMA est lui à 100% fiable je pense, malgré les quelques défauts du launcher Et au niveau des ressources, il bat à plate couture les deux autres systèmes puisqu'il ne fait qu'écrire des lignes dans le log.
Bon, et bien nous y voilà...
Sortie de la 1.30 avec commandes DataBase officielles et début de nouvelles questions. Voici un commentaire officiel de la fonction (Note: ils ne se sont pas beaucoup fatigués, c'est le même que celui du Lexicon, m'est avis qu'ils devraient grassement le payer ce gars là ):

Code PHP:

// This will remove ANY campaign variable. Regardless of type.
// Note that by normal database standards, deleting does not actually removed the entry from
// the database, but flags it as deleted. Do not expect the database files to shrink in size
// from this command. If you want to 'pack' the database, you will have to do it externally
// from the game.
void DeleteCampaignVariable(string sCampaignName, string sVarName, object oPlayer=OBJECT_INVALID) 
Ok Ok Ok... Message reçu Bioware. Mais euh... on la "pack" avec quoi cette Database ? FoxPro ça coûte 650€ ! Parce que la base, elle fait quand même dans l'obésité chronique.

Quelqu'un a une recette cachée/secrète ou même publique et gratuite ce qui serait le mieux quand même.
Lien direct vers le message - Vieux 30/08/2003, 11h12
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés
Thème visuel : Fuseau horaire GMT +1. Il est actuellement 10h08.
^^ Haut de page ^^