Riws

Je ne suis pas convaincu par les 'énormes avancées'. D'un point de vue technique, c'est sans doute vrai mais j'ai tendance à croire qu'une infime minorité, a créé un système ou plagié son concept, qu'elle a ensuite partagé ou vendu. Ce qui pousse l'émulation vers le haut certes mais la majorité me paraît toujours attentiste et surtout totalement dépendante de quelques autres. Peut-être suis-je dans l'erreur et mal influencé par ce qui se passait ici-même il y a quelques années. Mais si un magasin hors-ligne c'est le grand minimum en 2021, combien de serveurs sont en capacité de créer le leur de toute pièce ? Combien l'ont juste download & install en un clic ? Je suis peut-être même encore trop bon : combien ont juste téléchargé des files avec le système pré-installé dessus ? La digression s'arrête là. Ce que font les autres, ça les regardent après tout. Je me suis mis au python dernièrement, le client est toujours en 2.x ?

Bonjour à vous, je rejoins Galet, il y a toujours des défis, des opportunités et des choses excitantes. Je dirais même qu'il y a matière à l'épanouissement et c'est pourquoi il y aura toujours des irréductibles. Cela concerne tout aussi bien l'émulation que les claquettes. A titre personnel, 2010-2015 a été une période euphorique. Metin2 ne m'attire plus mais il a été un formidable tremplin. Il en reste une passion dévorante pour la programmation et toutes les réflexions méta-physico-philosophique qui peuvent en découler. J'ai de quoi m'extasier pour les 3 prochains millénaires. Merci. Je suis également en accord avec ton idée K3nshi. Les connaissances acquises en lien avec metin2 ne se limitent pas à metin2. Elles peuvent nourrir des projets aussi divers que variés. Mais pour le moment cela ne reste que des mots, quelle forme lui donner ?

Rien ne sert de se perdre dans un temps qui est révolu. Dans l'instant, le système ne fonctionne pas comme désiré, il te faut tester unitairement les conditions pour savoir laquelle permet le renvoi de cette erreur. Une fois cela fait, la communauté pourra t'aider plus avant. A bientôt

Forcément, si c'est moi qui regarde mal... Autant pour moi, je regarde tes fichiers de plus près et te tiens au courant. edit : si le message d'erreur 'CHANGE_LOOK_NEED_ITEM' s'affiche pour les armes c'est que l'erreur vient d'un peu plus haut : if (!item0 || !item1 || ch->SameItem(item0, item1)) { ch->ChatPacket(CHAT_TYPE_INFO, LC_TEXT("CHANGE_LOOK_NEED_ITEM.")); return; } Soit, il n'y a pas deux objets et dans ce cas, le problème vient certainement du client. Soit, c'est la fonction SameItem qui pose problème. Essaye donc de faire des tests sur cette condition pour déterminer quelle partie pose problème. Personnellement, je pense plus pour une erreur client.

Bonjour ShadowMt2, peux-tu me confirmer que tout fonctionne parfaitement bien sans la quête ?

Bonjour Link, as-tu pensé à compter les parenthèses ?

Bonjour, hé bien le message est clair : slotIndex n'est pas défini. Etant donné qu'il est appelé dans la fonction initiale, c'est assez inhabituel. Peux-tu nous partager la fonction dans sa totalité ?

En effet, il s'agit de la partie inférieure de l'inventaire. Il se peut que l'interface utilise un dossier réservé à celui-ci. Tu peux essayer d'autres mots-clés et/ou étendre tes recherches mais il est difficile de t'aider sans plus d'informations. Tu peux également partir de l'image de l'inventaire (certainement un .dds) qui doit être appelé par un fichier .sub, lui-même appelé dans un fichier .py, ce dernier réclamera toute ton attention.

Bonjour Saejin, le fichier uiinventorywindow.py que tu as fournis doit correspondre à la version officielle (et très vieille) de l'inventaire, cette interface doit avoir un fichier.py qui lui est propre. En faisant des recherches de mot-clé dans tous les fichiers du pack uiscript grâce à Notepad++ (à moins que l'interface soit dans un pack qui lui est propre ?) tu devrais pouvoir réduire rapidement les recherches. Cherche donc INVENTORY_PAGE_BUTTON_TOOLTIP_1 ou EQUIPMENT_START_INDEX ou encore "text" : "IV" Le fichier que tu recherches les possédera certainement.

Bonjour Saejin, c'est grosso-modo ce que j'ai tenté de faire à travers les différentes solutions proposées. 1/ Enlever la target à la connexion du joueur pour éventuellement la rajouter ensuite. 2/ Enlever la target à la déconnexion du joueur pour éventuellement la rajouter ensuite. Il faut comprendre qu'une téléportation est une déconnexion du joueur d'une map suivi d'une connexion du joueur dans la nouvelle. Ton idée est donc très proche de la 1/. Je t'encourage tout de même à essayer, tu pourrais bien trouver ce que je n'ai su voir. Et puis c'est une merveilleuse façon d'apprendre.

Bien. Je m'excuse de t'avoir demandé quelque chose de si... trivial. Le but était d'invalider les dernières théories imaginées. Comme je l'ai écris dans un message précédent, le problème semble profond et aucune retouche de quête ne semble pouvoir compenser cela (mise à part le retrait pur et simple des targets). Je m'excuse mais je ne pense pas pouvoir t'aider plus avant.

Hé bien... Peux-tu effectuer un test ? J'aimerai que tu mettes la ligne target.delete("__TARGET__") en commentaire puis que tu accomplisses la quête, enfin que tu téléportes dans la map orc juste après de façon traditionnelle. Pour finir tu te confectionneras un sandwich au beurre que tu rouleras dans la pâte à tartiner de ton choix et... Par traditionnelle, je veux dire sans utiliser de commandes gm mais en passant par le téléporteur, comme le ferai un joueur. La target de la quête est-elle toujours active ? Si oui, persiste-t-elle après une déconnexion/reconnexion ?

Je te remercie, j'ai visiblement survolé trop vite la quête. C'est donc target.delete("__TARGET__"). J'entrevois deux façons de procéder, j'ai un doute sur les deux car j'ignore s'il nous est permis de supprimer une cible sans qu'elle soit préalablement sélectionnée par un évènement. Il est possible de cumuler les deux façons, elles n'ont pas exactement le même effet. À toi de tester les bouts de code ci-dessous et si l'un d'entre eux s'avère fonctionnel, de décider la solution qui te parait la plus cohérente pour ton serveur. Je te rappelle qu'une seule target devrait disparaître. Solution n°1 : supprimer la target lorsque le joueur se connecte. Avant d'éventuellement la relancer. when letter begin target.delete("__TARGET__") local v=find_npc_by_vnum(20354) if v!=0 then target.vid("__TARGET__", v, mob_name(20354)) end end Solution n°2 : supprimer automatiquement la target à la déconnexion du joueur, à insérer où tu le souhaites dans le 'state gotoinfomation' when logout begin target.delete("__TARGET__") end

Très bien, merci pour le retour, cela permet d'explorer d'autres pistes. En regardant les screenshots de plus près, nous pouvons voir que ce problème est récurrent sur toutes les quêtes ce qui indique un problème profond. Donc tu ne peux t'attendre à voir toutes les target s'évaporer d'un coup de baguette. Mais si une seule venait à disparaître, c'est que la méthode fonctionne mais qu'il est nécessaire de l'appliquer sur toutes les quêtes concernées, une par une. J'exclus ma première hypothèse qui était que la fonction target.vid arrive à détecter le pnj sur une autre map. Le problème pourrait venir du fait que la fonction target.vid persiste d'une map à l'autre malgré la téléportation du joueur. Dans ce cas-là, plutôt qu'essayer d'appeler la fonction target.vid dans les maps concernées, nous pouvons envisager le problème sous l'angle inverse : retirer l'effet de la fonction target.vid dans les maps non concernées. Notamment, si je ne me trompe pas, grâce à la fonction target.remove. Mais je ne me souviens plus quel paramètre elle attend : target.remove("__TARGET__") ou target.remove(v) ?

re-Bonjour Saejin, il semblerait que le problème vienne bien du fichier introcreate.py, plus précisément de la fonction __SelectGender. Lors de la création d'un personnage, la variable CHARTYPE est fixée à 1, elle correspond au guerrier. Puis elle est incrémentée de 1 lorsque l'on se déplace sur le Ninja, encore une fois pour le Sura puis... elle est mise à 0 pour le Shaman pour ensuite être à nouveau incrémentée pour le Guerrier... Or dans la fonction __SelectGender, le cas où CHARTYPE == 0 n'est pas géré. Elle considère que le Shaman possède un CHARTYPE égal à 4, ce qui n'arrive jamais donc il se passe... rien du tout. Je te conseille donc de corriger les deux conditions erronées de cette fonction en remplaçant elif CHARTYPE == 4: par elif CHARTYPE == 0: comme ci-dessous : def __SelectGender(self, gender): global CHARTYPE for button in self.genderButtonList: button.SetUp() self.genderButtonList[gender].Down() self.gender = gender if gender == MAN: if CHARTYPE == 1: self.SelectWarriorM() elif CHARTYPE == 2: self.SelectAssassinM() elif CHARTYPE == 3: self.SelectSuraM() elif CHARTYPE == 0: self.SelectShamanM() else: if CHARTYPE == 1: self.SelectWarriorF() elif CHARTYPE == 2: self.SelectAssassinF() elif CHARTYPE == 3: self.SelectSuraF() elif CHARTYPE == 0: self.SelectShamanF()