NWN - Maskado

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

Répondre
Partager Rechercher
*sourit dans son coin en repensant à ses débuts en assembleur et soupire*
"Dieu, comme c'est loin !"
Ils vont se déchirer, ça y est

Bon, puisqu'on parle de performances...

Il y a un truc que j'ignore si vous le savez, mais TOUS les jeux en temps réel se basent sur le partage du temps machine pour effectuer des tâches auxquelles sont affectées des priorités. Il n'y a qu'à voir le problème que posent les gros modules avec l'horloge, ou le décrochement de l'AI quand le serveur est surchargé et à rapprocher ça des machines qui les font tourner. Je suppose que ça vous est déjà arrivé à tous si vous jouez un tant soit peu.
D'un coté, plus on charge sa machine, plus les actions secondaires seront oblitérées et passeront à la trappe (je suis conforté là-dessus par MR Georg Zoeller himself). D'où la haine farouche de certains ne sachant pas optimiser envers les OHB, ou les enchaînements de DelayCommand(). Je ne reviendrais pas dessus, mais quand même... Votre histoire de dizaines de milliers de variables me fait froid dans le dos...
Quand on pompe des informations, c'est pour les traiter. Or, à moins de bosser à la météo, nos pauvres ordinateurs, même de la dernière génération, n'ont pas encore d'architecture parallèle et la possibilité de traiter 10000 infos en même temps. Par conséquent, tout sera fait de façon SEQUENTIELLE, ne vous en déplaise !

J'ignore ce qui est prioritaire dans le jeu lui-même par rapport au reste, mais au niveau d'un PC, je le sais:
- les entrées sorties: clavier, souris (ridiculement pas gourmandes, je le concède)
- les entrées-sortie fichier (disque, flux externes -série, parallèle, buffers réseau, etc... Si vous ne me croyez pas, mettez une disquette bien pourrie dans votre lecteur, et interrogez-la, même sous Win2K ou XP, vous serez surpris)
C'est simple, elles INTERROMPENT le microprocesseur dans ses traitements pour demander son intervention pour charger les données en mémoire. Cela dit, plus le PC est puissant, plus la réponse sera rapide, MAIS, il y a les goulets résidant des tuyaux (BUS, largeur des ports, débit du réseau, etc)

Par conséquent, plus vous allez charger ces entrées-sorties, moins vous aurez de temps-machine pour faire faire autre chose à votre machine et ce malgré toutes les astuces développées en terme de "mémoire-tampon" ou de "spooling". Il y a forcément un moment où ça va saturer.
Donc, à moins d'avoir une machine de guerre genre serveur dédié avec RAM-cache sur les contrôleurs de disques durs, carte réseau 1Gb avec RAM-cache, et architecture SCSI (et encore, ce n'est même pas sûr que ça suffise...), traiter des bases de données enchaînant des milliers de données pour un pauvre joueur, j'ai comme l'impression que vous allez vous planter...
Il y a des process d'usine qui traitent moins de volume et qui ne se contentent pas d'un pauvre PC de chez RaqueFour mais qui recourent à des montages en clusters pour essayer de simuler un traitement en parallèle des données et bien sûr le tout sur fibre optique.

C'est sûr qu'en optimisant son code, on va gagner quelques microsecondes par ci, ou par là, mais quid d'interrogations de bases qui demandent à charger, hmmm, mettons... 10000 enregistrements...

Un simple calcul:
en admettant que l'on oublie les protocoles et les flux secondaires liés à la structure des données (encapsulage, protocole TCP/IP, cryptage, etc), que notre ordinateur est seul sur le réseau qui interroge la base distante, et qu'on utilise le volume de données brut, on transférera 10000 entiers codés sur 4 octets sur un réseau à 100Mbits/s en ??? 3,2 secondes (environ) ! et ça, au mieux ! Donc, pendant 3,2 secondes, la machine hyper-optimisée ne va rien glander que de gérer ses entrées sorties et ramer sur tout le reste !
Ca en fait des millions d'instructions, ça, 3,2 secondes... Et ce ne sont que des entiers ! Imaginez des chaînes ou des types "object".
Moi, je rapproche ça des CINQ MINUTES, qu'il m'a fallu pour sauvegarder un inventaire moyen de personnage avec le système Bioware en utilisant la technique de base du StoreCampaignObject()... Alors même en utilisant MyMegaSql et NWFX-Save-plus-vite-que-son-ombre, vous m'excuserez, mais je reste partisan de traiter un petit volume de données en mémoire !
Et qu'on ne vienne pas me dire que les requêtes SQL sont plus rapides qu'un GetLocalInt() !
Sherazade me fait peur quand elle parle de centaines de milliers de données à gérer, on dirait qu'elle parle du processus de fabrication d'une voiture à la chaîne chez Renault.

Hep, les enfants, c'est un jeu, pas un concours de celui qui fera le plus gros module

EDIT: vue la juste rectification apportée plus bas à mes calculs, ma démonstration devient un brin moins spectaculaire mais reste néanmoins vraie... La quantité de donnée étant environ multipliée par 3 si on inclut les protocoles divers et en estimant que toutes les trames arrivent au destinataire en un temps idéal, je ne me suis QUE planté de 250 fois environ. Soit non pas 3,2 secondes mais 13 centièmes de secondes environ. Reste après à les traiter, ces données qui jusque là n'ont fait qu'arriver par les tuyaux.
Ca appelle une réponse .

Je reviens sur le CNR que je connais assez bien maintenant, après m'être battue avec lui durant de longues semaines . Lors du chargement du module, il génère plusieurs dizaines de milliers de variables locales stockées sur l'objet module. Attention, ce ne sont pas toutes des variables provenant de la DB, bien heureusement . Mais le CNR surcharge l'objet module de variables, regardez comment sont codées les fonctions de création de recettes.

L'idée de base du CNR est excellente, voire géniale, mais le code est vraiment mal fichu par endroit. En ce qui me concerne, je pense avoir divisé le nombre de variables par 8, et je pourrais encore le diviser par 2, mais ce que je gagnerais en occupation mémoire, je le perdrais en vitesse. Toujours ce satané compromis vitesse / mémoire qui nous hante depuis des décennies... Mais, l'optimisation n'est pas tant à ce niveau, mais plus au niveau de la répartition des variables sur plusieurs objets. Je ne sais pas comment gère NwN ses tables de hachages, mais mal... très mal. Les performances sont VRAIMENT meilleures en répartissant 10 000 variables sur 10 objets que sans les répartir. Faites de simples tests de générations automatiques de variables locales réparties ou non, vous verrez .

Voilà ce point qui concerne les variables locales.

Passons aux variables stockées dans la DB. Idem, une bonne répartition est la clé de meilleures performances. Surtout ne pas créer une seule table en fourrant tout dedans astucieusement. Il est de loin préférable de créer plusieurs tables moins remplies. Encore une histoire de fouille de données.

Bref, prenons un PW où il est possible aux PC de stocker leurs objets dans des coffres perso. voire de vendre des objets via l'utilisation d'une banque, de coffres, etc... Le calcul n'est pas bien difficile, à raison d'une ligne dans la DB par objet, ajoutez une pincée de lignes par perso. pour stocker différentes données, il est très facile d'arriver à 25/50 ou plus variables par perso. Multipliez par le nombre de perso. et la soupe est prête .

Enfin, bon, ce genre de quantité ne me fait pas vraiment peur, il suffit de bosser un peu en analyse numérique pour se rendre compte que des matrices 10k*10k, c'est pas si grand que ça .
ah bah il est beau le fier CNR lol ^^

Citation :
Je ne sais pas comment gère NwN ses tables de hachages, mais mal... très mal.
bah.... pas spécialement bien, pas spécialement mal, mais de la façon la plus naturelle qui soit en orienté objet, par listes chainées.
Pour une fois je ne vais pas raler sur bioware de ne pas avoir prévu mieux, c'est au scripteur de s'organiser pour faire lui même du tri dans ses variables

Pour ma part, j'ai mis une bonne grosse quantité de waypoints dans une zone, que j'ai mis dans un LocalObject sur le module, et que je récupère par simple appel d'un GetLocalObject, qui contiennent toutes les variables d'un système spécifique, que j'aurais pu mettre dans le module mais que j'ai préféré éviter ^^
je suppose que tu as du faire de même pour les variables du CNR
Ben quand je parlais de machine d'aujourd'hui c parce qu'elles sont de plus en plus puissantes cc lair j'ai pas dit que c'est pour cela qu'il faut pas mal programmer...

Et par experience professionnel, je peux t'assurer qu'aujourd'hui il y a enormement d'applications qui tournent et qui sont ecrits par des ingenieurs qui ne essemblent a rien du tout en term de programation, mais c aps grave t'as le resultat voulu et en un temps records

Quand je donne l'exemple de l'assembleur c simple car c le langage le plus rapide mais plus utilise. Pourquoi? ben parce que pas simple d'utilisation. Il faut donc mettre en balance la simplicite d'utilisation et la rapidite d'execution... et cela on peut se le permettre pourquoi parce que l'ona des machines de plus en plus performantes (ca date pas d'aujourd'hui mais c plus ou moins lie... les prmeirs jeux video etait quasiment fait que en assembleur... c plus trop le cas maintenant)

Maintenant l'usage de la DB ou des variables locales, c quelques choses qui doit rester simple et fonctionnels.
Et la ca dependra des cas.
Par exemple on veut gerer un coffre pour les PJs ou ils peuvent stocker leurs objets et les retrouver quand ils le veulent (un system de banque en gros). La tu as une persistance de tes donnees qui doit perdure apres un arret du serveur. Ben je vois pas comment faire autrement que de les ecrires sur disque a un moment donnees... donc rien de mieux qu'une base de donnees.
Maintenant je gere un casque specifique qui a uneffet donne dans certaine zone a climat extreme. Ben je le gere avec une variable sur l'objet.
Par contre, la zone a climat extreme j'aimerais bien pouvoir la changer comme je veux, sans avoir besoins de passer par un script ou autre... ben le plus simple c aussi a mon avis de stocker d'une façon ou d'une autre en base de données...

Mainteant faut voir que tout ce que tu stocke en base, c soit pour des persitence de donnes, soit pour une modification plus souple, soit aussi pour decharger la memoire de ton module avec des choses dont il a pas forcement besoins a l'instant.
Plus t'as de memoires de libres a un instant T, mieux cela sera...

Pour Azmatiel :
10000 entier de 4 octet = 40000 octet...
un octet c 8 bit donc 40000 * 8 = 3 200 000 bit.
100MegaBit on va simplifier on va prendre le K a 1000 (d'ailleurs je crois bien que c le cas ici et non 1024 )
donc 100Megabit = 100 000 000 bit
donc si on imagines qu'on est dans un mode parfait (ce qui est pas le cas) ca devrait passer un 3/100 de secondes et non 3,2 s...
mais vu la taille de la trame ethernet et celle de TCP ou UDP ca mettras un poil plus de temps mais bon... loin des 3,2 s quand meme
Tu as raison Garrath, je me suis planté, j'ai divisé par 100 000 et pas 100 000 000. N'empêche que ça reste vrai et que ta machine va glander pendant ce temps. Du coup, ça fait 1000 fois moins longtemps, certes.
J'ai ajouté un rectificatif au dessus. Merci d'avoir vérifié mes âneries
Citation :
Quand je donne l'exemple de l'assembleur c simple car c le langage le plus rapide mais plus utilise.
je ne sais pas d'où tu tient tes sources, mais dire que l'assembleur n'est plus utilisé est une belle abbération.

certess, pour la création de jeux, les langages de haut niveau, si possible orienté objets sont bien plus appropriés, mais l'asm reste très utilisé (a juste titre), l'exemple le plus évident est pour la création de drivers materiel, mais il a bien d'auters usages.

Moi même je m'en sert occasionnellement pour coder des fonctions destinée a tourner vite et bien.

Citation :
Et par experience professionnel, je peux t'assurer qu'aujourd'hui il y a enormement d'applications qui tournent et qui sont ecrits par des ingenieurs qui ne essemblent a rien du tout en term de programation, mais c aps grave t'as le resultat voulu et en un temps records
je ne sais pas ce que signifie "essemblent", et je n'en comprend pas trop le terme même dans le contexte.
toujours est il que je n'ai besoin d'aucune experience professionnel pour dire qu'en effet des applications sont créé par des amateurs qui ne font qu'aligner des codes de java ou de machin .net, tellement pratique, mais tellement lent.....
Savoir que la nouvelle os de microsoft sera programmée exclusivement en C# me fait froid dans le dos....
un temp de programmation record, certe, mais je ne paye pas 100€ une OS qui a été programmée en un langage fait pour écrire un programme en un temps record.....
Je prend l'exemple de windows mais ca s'applique a tellement d'autre choses.....

@Kétil Dimzad : l'assembleur est un langage de bas niveau, c'est a dire un langage où tu ne passe par aucune fonction pour arriver a tes fins, tu ne fait que dialoguer avec le processeur lui même, en lui demandant directement ce que tu veux faire, ce qui implique également de gérer toi même la ram, les déplacement de flux, et bien d'autres choses. Il a l'avantage d'être très rapide a l'exécution, puisque tu ne fais rien dans le vide, chaque ligne de code est directement optimisée pour faire avancer le shmlilblik.
Concrètement, programmer un code revient quasiment a (que les puristes me pardonnent ) le programmer directement en binaire.
l'assembleur est le langage dr programmation que les pro s'accordent pour dire qu'il est le plus pret de la machine (ce qui n'est pas 'techniquement' vrai mais bon ..on chipote) ... le probleme c'est que les commandes qui le composent sont TRES primaires (c'est rapide..mais primaire..) donc c'est tres chiant à utiliser quand tu veux programmer vite un gros programme (essaye d'expliquer à quelqu'un comment venir de marseille à paris en ayant droit qu'auc mots "avance', 'recule','droite','gauche','stop'... et tu auras une idée de ce qu'il faut faire pour programmer en assembleur... )

part contre c'est le langage le plus optimisé et rapide qu'il existe...

edit: grmlrmlrmlr grillé par azra
oups dsl Azrael fallait lire 'ressemblent à rien du tout en terme de programmation'

Entierement d'accord avec toi sinon... j'ai commence a travailler en informatique a une epoque ou les gens comptaient quasiement les cycle machine etc... (c'etait facturé à l'utilisation de CPU) ce qui n'est plus le cas actuellemnt

Sinon pour Azmathiel, je suis pas super fort en architecture de processeur mais j'ai des doutes que le processeur d'un PC attendent tranquillement aujourd'hui pendant 3/100 de s, a mon avis il va faire d'autre tache, et si le jeu est bien fait voir meme gerer un autre evenement ailleurs mais bon la je m'avance un peu ...
Et Fortran ... .

Pour revenir au sujet initial, cela dit, je vais le tester ce week-end avec la mémorisation de la position du PC, c'est tout simple, ça ne devrait pas prendre longtemps et je pense qu'en effet ça peut aboutir à un gain de temps conséquent .
'Scusez moi M. Garrath, j'ai zappé involontairement, et sûrement à cause de la fatigue de mes yeux une partie de votre message m'étant destiné.
Voici quelques éclaircissements sur le sujet:

Un microprocesseur est conçu pour traiter des infos en flux continu sur des signaux électriques de commande. Il sait qu'un certain nombre de fils positionnés dans un état électrique donné provoquent telle ou telle opération. Bien... Ce sont généralement des opérations arithmétiques élémentaires. Décalage à gauche, décalage à droite, rotation, échange de registres, empilement, recherche en mémoire, etc... (c'est LE langage machine évoqué dans les réponses sur l'assembleur)
Il y a tout un ensemble de fils qui ont un rôle particulier: les interruptions. Celles-ci ont pour rôle de stopper le microprocesseur dans son travail actuel pour le prévenir qu'on a besoin de lui ailleurs. Ces instructions (qui sont carrément des fils physiques, ou des pattes du microprocesseur pour être plus précis) sont prioritaires sur les autres et ont même une priorité entre elles dont la plus importante est la demande d'accès DMA qui va pomper tout le bus pour accéder à la mémoire (dans le cas des disques durs par exemple. DMA = DIRECT MEMORY ACCESS). Le BUS n'est alors plus à disposition du microprocesseur pour qu'il puisse travailler. Bien sûr, ces requêtes sont gérées par le système d'exploitation, qui, quand il est bien fait, échelonne ces requêtes en fonction de ce qu'il y a à faire (exemple du multitâches). Alors, en effet, il ne restera pas à se tourner les pouces, mais pendant le temps où les données vont arriver, il va être bloqué X fois X millièmes de seconde jusqu'à ce que le flot soit interrompu. Il n'en va pas de même pour les données arrivant du réseau, puisque c'est le processeur qui va se charger de récupérer les données sur le BUS pour les ranger en mémoire. Intel a d'ailleurs essayé de contourner un peu ce problème dans ses déclinaisons du pentium en y rajoutant des "unités de prédiction de branchement", des "pipelines" et de la RAM cache. Glups... Encore des tuyaux en plus...

Alors évidemment, tout ça va très vite maintenant. J'expliquais dans un autre sujet qu'un PC avec une horloge de 2GHz avait 2 milliards de cycles d'horloge par seconde et qu'une instruction moyenne en utilisait 15-20, mais il faut voir ça dans son ensemble. A coté de tous ces traitements de données, tu vas avoir à gérer tout le reste: entrées sorties normales, réponses aux requêtes ping, réponses aux périphériques qui veulent savoir si le microprocesseur est toujours en vie, etc... et bien sûr, le serveur de jeu qui tourne en ce moment même... comme je l'ai dit: plus tu en mets, plus tu satures (oui, c'est une lapalissade, mais il serait de bon aloi de l'avoir à l'esprit si on ne veut pas entendre: "il rame, ton serveur").


J'en profite pour couper l'herbe sous les pieds à ceux qui s'imaginent que de stocker des données dans une table, ça ne consomme pas de mémoire... La base, quelle qu'elle soit, a un format de données. Avant d'envoyer les données sur le disque, il faut les formatter en mémoire, et on alloue en général à chaque "canal" d'entrée/sortie une zone tampon en mémoire. Plus on ouvre de canaux, plus on consomme de mémoire. Si ça ne vous dit rien, rappelez vous les BUFFERS et FILES de MS-DOS. Ne croyez pas que ça a disparu par l'opération du Saint-Esprit grâce à un coup de baguette magique de Redmond.

Avec les systèmes de Microsoft, ce sont toujours des buffers. Il n'y a qu'à ouvrir RegEdit et de faire une recherche sur "buffer" et la nuit est finie en même temps que la recherche. Il y a tellement de buffers sous mon Windows 2000 que je renonce même à les compter...

Chaque buffer représente de la RAM. Oh, trois fois rien... Un octet par ci, un mot par là, une page RAM pour la vidéo, une autre pour le DMA son, quelques petites centaines de kilos pour le buffer du modem, deux mégas pour le CD-ROM... etc..

Là, en ce moment même, j'ai 134 Mo qui sont utilisés par les process qui tournent et mon gestionnaire m'annonce que 231 Mo de RAM sont occupés. On se demande par quoi ! Ben... Des buffers !
Donc, si si, on consomme AUSSI de la ram avec les tables et les bases de données et même énormément. Certes, c'est relativement fixe si on n'ouvre pas une quantité pharaonique de buffers de lecture écriture. Mais n'empêche... Rien à voir avec de pauvres variables locales, qui de toute façon seront utilisées en plus !
Citation :
Donc, si si, on consomme AUSSI de la ram avec les tables et les bases de données et même énormément. Certes, c'est relativement fixe si on n'ouvre pas une quantité pharaonique de buffers de lecture écriture. Mais n'empêche... Rien à voir avec de pauvres variables locales, qui de toute façon seront utilisées en plus !
C'est clair qu'on consomme de la ram, moi je sui spas specialiste MySql par contre je suis assez copain avec Oracle et c'est clair qu'on consomme de la Ram. On en a besoin pour le tri etc... et comme tout logiciel un system de base de donnees a besoin de ram pour travailler... Mais l'avantage c'est que une fois que tes données sont en base tu n'est absolument pas oblige de les laisser sur la meme machine

Non mais de toutes façons comme je l'ai dit plus haut base de donnees ou variables persistantes tout depend de l'usage que l'on veut en faire.
Je suis pour le consensus en regle general et pour une approche terre a terre... Pour moi il n'y a pas de solution qui soit bonne dans l'absolu. Tout depend de l'usage que l'on veut faire des donnees.
C'est d'ailleurs pour cela que sur NWN tu as le moyen de faire les 2. Soit tu utilises la db de bioware soit tu utilises les variables locales. C'est pas le meme usage.
Maintenant perso je prefere utiliser NWNX avec MySql a la place de la db de bioware car a priori c plus rapide et aussi parce que j'ai tout une palanquee d'outils pour visualiser, modifier, creer des donnees dedans (Bon j'aurais prefere utilise Oracle car j'ai plus d'outils sous la main ).

Ex : J'ai un pb actuellement que je suis entrain de resoudre c'est la sauvegarde persistante d'item d'un PJ dans un coffre. Je veux garder cela meme en cas de scratch du serveur. Je ne peux donc pas utiliser de sauvegarde par variables locales ou autres (copy des items dans un coffres ailleurs etc....). Donc la pour mon besoin je suis quasi oblige de passer par une base de données. Maintenant en fonction des test que je ferais j'utiliserais celle qui me conviendras le mieux. Car maintenant le pb que j'ai c'est que grace a HOU on a la possibilite de rajouter sur un objet en jeux des itemproperty... J'ai quasi trouve le moyen de tout recuperer et donc de tout recreer comme je veux mais le hic c'est que pour les recuperer je suis obliges d'acceder aux 2da... et c'est apparemment assez gourmands. Donc soit c pas trop grave et c'est quand meme moins gourmand de lire les 2da et de stocker cela en base de données soit cela sera moins gourmand de stocker cela directement avec la db de bioware car il svg l'objet completement.
=> j'utiliserais l'outils le plus adaptes a mon besoins.
Par contre si derriere je veux avoir un coffre par habitation appartenant aux PJ, et que je veux pouvoir avoir la persistance toujours de mes donnees mais que un voleur de haut niveau puisse voler le contenu du coffre ben peut etre que la db de bioware ne sera pas suffisante ...

A cote de cela j'ai des variables comme je l'ai dit plus haut sur des objets qui me permettent de leur donner des pouvoirs etc...
Ben cette variables est liees a cet objet et le restera. Donc la je me pose meme pas la question...

C'est l'usage que l'on veut qui fait que l'on choisis telle ou telle methode. Et je vais certainement pas tout stocker en base parce que j'ai acces a une base ni tout mettre dans des variables locales parce que j'ai la possibilite de le faire. Mon choix sera dicte par l'usage que je veux avoir de cette donnée et par la persistance que j'en veux. Cela sera un choix murement reflechi

PS :Azmathiel tu peux me tutoyer y a pas de pb
Citation :
'Scusez moi M. Garrath, j'ai zappé involontairement, et sûrement à cause de la fatigue de mes yeux une partie de votre message m'étant destiné.
En plus je te rassure c'est pas la fatigue, j'ai reedite mon message immediatement apres l'avoir poste et tu avais deja repondu
Et je te remerci pour tes explications sur le processeur
Salut à tous,

j'arrive assez tard, je pense que vous tous êtes déjà passé à autre chose.

Je n'ai pas eu le temps de lire toutes les réponses, mais il me semble qu'il n'y avait pas la réponse à la question suivante :

Les variables locales fonctionnent très bien en servervault. En revanche, elles ne marchent pas en localvault lorsque le joueur quitte le jeu et revient par la suite (les variables sont effacées) ! Comment faire que cela fonctionne aussi en localvault en utilisant si possible un système similaire de fonctions simple sans avoir des scripts monstrueux (suis nul en script moa ) ?

Je n'attends pas de réponse magique, un lien vers un autre thread suffirait...

Merci à tous et bon jeu !
TheRack
Je ne sais pas si ça fonctionne ou non en localvault, mais si tu dis que non, je te fais confiance. Donc, à priori, pour te répondre, ce n'est pas un problème de script, mais de stockage de données.

D'ailleurs on peut s'interroger sur l'intérêt de stocker des données au sujet d'un PJ dont on n'est pas sûr qu'il sera pareil quand il sera réutilisé à la reconnexion suivante.
Il ne te reste plus que la solution des tables Bioware ou NWNX. Et encore, si le joueur change le nom du personnage entre temps, ça ne servira à rien non plus.
excellent
J'adore votre jargon, je sais pourquoi j'ai l'impression d'être une petite bit (e) lorsque je me tue a faire un script de base.
Ceci dit, j'aime beaucoup ce débat la, car il est le fruit d'un vrai cocktail de programmeurs pro et de joueurs.

Malgrés la technique ces derniers posts sont très clairs.
merci de ces réflexions.

NB:Avance-Avance-droite-avance-gauche.........Le truc le mieux imagé que j'ai entendu concernant l'assembleur
excellent!!!
__________________
Congnois toy toy mesme. Nulle gloire dans le sang inutile
Je remonte le topic pour une info importante.

Il semblerait que les variables locales DE POSITION enregistrées sur des objets d'inventaires ne survivent pas à un changement de module.

Je m'explique, j'ai un mod de travail, et un mod que je met en ligne. Lorsque je veux mettre à jour mon mod, j'écrase celui que je met en ligne avec mon mod de travail.

Et là, à tous les coups je perds les variables ( je reprécise DE POSITION ) ....

Je me sers principalement d'un objet non dropable pour stocker la position d'un joueur.

Si je reboote le module sans faire de maj, pas de problème, le joueur est renvoyé à la dernière position enregistrée, par contre si je fais une maj que dalle.

Voilà, c'était ma p'tite pierre

A+
C'est curieux, je ne suis pas surprise. J'avais mis de coté ce procédé de sauvegarde en raison de son coté erratique sans en chercher les causes profondes vu que j'avais un système qui fonctionnait très bien sans.

Félicitations pour avoir donc trouvé une / la cause de ce problème .
Répondre

Connectés sur ce fil

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