Recherche Quêtes Journalières PvP

[Cobalt 1]

Bonjour.

 

Je post cette "demande d'aide" pour demander si quelqu'un aurait la quête journalière ou qu'il pourrait me la codé pour mon serveur. C'est une quête journalière PvP.

 

 

Je m'exprime : 

 

Qu'elle quêtes je recherche ?

 

 

 

Je cherche une quête qui permet d'avoir trois joueurs aléatoire à tué, les trois joueurs à tué doivent être si possible level max (150)

 

 

 

Si c'est 3 joueurs sont tué une récompense défini sera donnée automatiquement.

 

 

 

 

 

Si c'est trois joueurs aléatoire ne sont pas tué, les cibles changent automatiquement au bout d'un certains temps.

 

 

 

 

 

Si c'est 3 joueurs sont tué, d'autres cibles au bout d'un certains temps se remette en chasse. ( Je ne sais pas si vous m'avez compris )

 

 

 

 

 

Avec cette quête j'aimerai avoir un système pour trier les non actifs pour éviter de tomber sur des personnes qui ne sont pas actifs et surtout tombé sur des personnes de level max.

 

 

 

Si quelqu'un de bien gentil qui pourrais sois me la partager sois me la codé serait génial de sa part

.

 

Mes sincères salutations.

Cobalt.

 

Au plaisir mon cher Calypso  

[Doberman 19]

C'est une quête assez complexe (ça dépend pour qui) à coder ça m'étonnerait que quelqu'un te la fasse comme ça gratuitement pour le plaisir mais bonne chance.

 

Quand je dis complexe c'est plutôt dans le check de l'activité du joueur: si les 3 joueurs choisis ne sont plus actifs c'est problématique.

[Cobalt 1]

Je sais pour sa que je demande ..

[Cobalt 1]

Oui voilà

[Cobalt 1]

J'ai oublier de préciser, si possible les trois cibles à tué sont marquer via une fenêtre de quête

[Ioio 75]

http://www.elitepvpers.com/forum/metin2-pserver-guides-strategies/1804045-release-pvp-quest-v1.html

http://just4metin.ro/quest-uri/quest-pvp-omoara-player-primesti-exp-t34451.html

[Cobalt 1]

Je regarde sa

[Cobalt 1]

Après un traduction des deux quêtes aucune ne correspond a ce que je recherche les deux consiste a recevoir une récompense après avoir effectué 100 kill

[Sparks 197]

Yo,

c'est pas le genre de quête que l'on peut coder sur un coin de table, encore moins dans une shoutbox.

La base est simple, même sans aucune requête MySQL.

Mais le code est long et les cas particuliers sont nombreux (et dépendent beaucoup du serveur). Il faut gérer les cas (parmi tant d'autres) où le joueur change d'empire ou de nom, ce qui signifie mettre à jour les autres quêtes, on quitte rapidement le concept limité de quête pour se retrouver avec un système à part entière. Donc impossible à coder à l'aveuglette... À ce niveau-là ce n'est plus une demande d'aide mais une recherche de services.

Mais sache que c'est largement réalisable avec le suivi d'une personne compétente.

Désolé de ne pas pouvoir en faire plus pour le moment. Bonne chance.

[Doberman 19]

Exactement Sparks, je voulais être simple pour lui faire comprendre mais maintenant que tu as détaillé tout ça il pourra comprendre la difficulté de sa demande. Néanmoins je suis pas d'accord sur un point : le système va obligatoirement nécessiter des requêtes MySQL.

 

Comme l'a dit Sparks le code est réalisable par un codeur de quêtes compétent mais ça nécessite pas mal de boulot, boulot qui sera fait par une personne qui te demandera sûrement de l'argent.

 

N'ayant pas le temps, que ce soit payé ou gratuit, je laisse ma place sur celle-ci

[Hystos 14]

Il y a 2 ans de ça j'avais écris précisément ce système. Je pense pas pouvoir te le retrouver, j'ai fais un nettoyage de printemps il y a quelques mois, mais ça te prouve que c'est largement faisable. En plus, à l'époque, je pouvais pas toucher aux sources donc ça se faisait à coup de requêtes SQL relativement coûteuses !

Dans une quête de ce type, il y a deux parties principales : la gestion des kills et la gestion de la temporalité.

Tu peux déjà commencer par réfléchir à la manière dont sont gérés les kills en PvP sur ton serveur (module intégré au game serveur, quête, rien du tout ?). La plupart des systèmes téléchargeables directement sur des sites comme epvp étaient il y a quelques mois des quêtes bourrées de requêtes SQL dégueulasses (désolé du terme). Si tu manipules un peu les sources, utilises les et code le système proprement. Tu gagneras ENORMEMENT en rapidité, en stabilité et en fonctionnalités.

Une fois que tu auras ton implémentation, ça ne devient plus très difficile. Il faut générer la liste des cibles potentielles, avec quelques restrictions. Globalement, cette fonctionnalité ci passera parfaitement dans une fonction que tu pourras écrire en C++ facilement et qui correspond simplement à l'application d'une requête SQL avec quelques paramètres (level, dernière connexion récente, empire particulier ?).

Ensuite, pour l'aspect "Journalier", moi je l'avais écris dans une quête avec les fonctions en lua qui permettent de gérer la temporalité. Tu peux certainement là encore faire mieux en passant par les sources.

 

Si tu as la motivation et quelques connaissances basiques, je te conseille vraiment d'essayer de le faire par toi même en passant par les sources. Tu pourras ainsi approfondir la gestion des kills dans les sources (ce qui est crois moi très enrichissant et peut te permettre de vraiment différencier ton serveur des autres) et raisonner comme un vrai développeur sur metin2 (et pas bidouiller une quête qui te fera la même chose en moins bien et beaucoup plus coûteux).

[Cobalt 1]

Waouh merci Hystos pour toute ses informations, je vais me renseigner et essayer de faire sa car je la recherche.

 

Je ne sais pas trop quoi te dire d'autre mais en tout cas je vais tout faire pour qu'elle fonctionne et que je le fasse

 

Cobalt.

[Sparks 197]

Sérieux... Vos conseils sont bons mais vous vous tuez à faire un système pourtant simple.

Oui on peut faire un système avec des tas de requêtes abusées, oui on peut modifier les files pour quelque chose de beaucoup plus propre mais franchement...

On veut quoi ? Une restriction de niveau, une méthode pour savoir si un joueur est connecté ? Vous voulez faire des requêtes pour ça ? C'est disproportionné.

 

Vous voulez une méthode simple, efficace et pas gourmande ?

when login with pc.get_level() <= 150 begin
 table.insert(locale.table_joueur[pc.empire], pc.name)
end

 

Voila. C'est tout. On a la restriction de niveau qu'on veut. Et si le joueur se connecte c'est qu'il est actif. Terminé.

Après on déclare cette table dans le fichier locale, un truc du genre :

locale.table_joueur = {{},{},{}}

 

Avec ça on a la liste des joueurs qui respectent les conditions de niveau que l'on veut et qui se sont co au moins une fois depuis le dernier reboot.

On peut rajouter un logout avec un table.remove si on veut que des joueurs connectés. Mais on est même pas obligé.

Après on peaufine : les gm ne sont pas ajoutés, ceux qui levelup 151 sont automatiquement enlevés, ceux qui changent d'empire sont viré d'une table pour être rajouter dans l'autre.

etc etc

 

Le week-end prochain je me penche dessus pour vous montrer que ce ne sont pas que des mots.

[Doberman 19]

Sparks le "when login" s'exécute à chaque changement de map d'un personnage, donc à moins que tu rajoutes quelque chose pour que le table.insert ne s'exécute qu'une seule fois par personnage, quand est-ce que tu vas "débloquer" la situation ? C'est à dire remettre ce quelque chose à zéro. Ca peut être un setqf getqf, etc.

 

Parce que sinon tu vas avoir des centaines de fois le même pseudonyme dans ta table et c'est tout sauf bon

 

Pareille pour le "when logout", quand tu es à la page de chargement lors d'un changement de map le jeu te considère comme déconnecté, et quand tu arrives dans la map tu es reconsidéré comme connecté.

 

Tu peux bidouiller après bien sûr c'est faisable mais ça reviendrait à se casser la tête juste pour ne pas utiliser une seule requête SQL.

[Sparks 197]

Évidemment d'autres problèmes se posent par la suite. Mais même tarif pour la requête.

Une seule ne suffirait pas (l'empire n'est pas contenu dans la table player) ou la gestion des gm (grâce au nom tu vas me dire) ? Chaque solution amène son lot de problème.

 

Peut-être que je me trompe, je verrai.

J'ai plus l'habitude de bosser sans requête, peut-être qu'une personne habituée avec arriverai à faire une quête plus efficace que la mienne ? Si tu veux, on teste chacun à sa façon

[Doberman 19]

Tu peux récupérer la liste des joueurs en une seule requête, quel que soit leur empire.

Ensuite, si tu veux les stocker dans 3 tables différentes il faudra 3 requêtes.

 

Et non je bosse sans requêtes SQL aussi je les utilise rarement mais parfois elles sont les seules solutions viables. Peut-être pas les seules solutions possibles dans certains cas mais dans celui-ci si on veut éviter des table.insert, des setqf, et j'en passe, elles sont nécessaires.

[Sparks 197]

Le stockage selon l'empire est utile qu'avec ma technique, avec une requête on en a plus besoin (le tri est automatique si tu parametre correctement la requête). Donc si ce tu dis est vrai, une requête suffirait. Ça pourrait le faire.

Code mon gars, je veux voir ta théorie à l'œuvre

[Hystos 14]

Je reviens juste sur quelques points cités plus haut, mais je réponds pas au problème posé, désolé

 

Selon moi, la meilleure façon d'implémenter un nouveau système est atteinte quand on peut difficilement voir la différence entre ce dernier et les systèmes déjà présents de base. En gros, ça veut dire utiliser les outils qu'utilise le jeu de base sans chercher à bidouiller pour rien.

 

Dans l'exemple de ton tableau de personnages, Sparks, c'est simplement de la duplication d'information. Tous tes personnages sont déjà stockés dans une table SQL facilement accessible, et n'étant pas forcément coûteuse si on passe par les sources (et surtout pas par un pseudo module implanté pour jouer avec des requêtes dans les .quest). Ce n'est pas logique de créer un nouveau tableau avec les noms de tous les personnages du jeu (en se faisant chier avec des trucs pas évidents à gérer : plusieurs login => pas de duplication, le logout pas forcément envoyé comme on le veut...).

De plus, beaucoup de gens sous estiment la puissance du langage SQL. Les requêtes "basiques" que vous trouvez un peu partout avec un SELECT, un WHERE, un ORDER BY, etc... c'est que la partie immergée de l'iceberg ! Toute sa puissance repose dans ses groupements, ses jointures, ses sous-requêtes, ... En utilisant au mieux de ses capacités le SQL, on peut vraiment faire des miracles qui auraient nécessité plusieurs requêtes "basiques" avec des boucles imbriquées (cf empires).

 

Ainsi, selon moi, la meilleure façon d'écrire ce genre de système est de passer intégralement par les sources, et de transmettre quelques fonctions aux quêtes pour l'affichage. A l'intérieur des fonctions codées en C++, il faudra utiliser les éléments de base mis à disposition (les tables SQL, les contenus pré-chargés lors du lancement du serveur, les tableaux dynamiques présents et remplis en cours de fonctionnement). C'est comme ça que fonctionnent le reste des éléments du jeu (guildes, batiments de guilde, shops, ...).

En plus, il y a de nombreuses alternatives possibles qui deviennent faciles à faire. Les joueurs actuellement connectés sont par exemple déjà stockés dans un "tableau" en C++ qu'il suffit d'utiliser au besoin.

 

PS : C'est un peu ironique pour moi de dire ça car il y a quelques années j'étais "Monsieur qui fait tout avec les quêtes" ! Je gérais les drops, les kills, les events, les systèmes de ce genre et énormément d'autres uniquement avec des quêtes. J'avais pas le choix, mais ça montre que c'est possible. Avec plus de recul et d'expérience, et surtout la publication des sources, on se rend bien compte qu'on peut faire beaucoup mieux !

[antok 62]

Il y a également un problème avec les tableaux, c'est qu'ils sont dépendants des cores, c'est à dire que si un joueur se connecte sur le core 3, il ne sera ajouté uniquement sur le tableau du core 3

[Sparks 197]

Owned le Sparks

 

Dommage qu'on te voit si peu Hystos.

[Doberman 19]

Exactement Hystos, je ne l'avais pas précisé parce que ça me semblait cohérent : maintenant qu'on a les sources, faire les requêtes directement dessus (en C++) en créant une nouvelle fonction est beaucoup mieux que faire les requêtes par quêtes (mieux que ce soit dans la consommation, la rapidité, etc. vu que la base de données est directement reliée)

 

On t'apprendra sparks

[Sparks 197]

Inutile, l'époque où les quêtes étaient reines est révolu... Et mon temps avec.

Fini les commandes gm codées en lua, fini les up du forgeron en .quest, fini la gestion des magasins, de la pêche, de l'empereur, de l'ox, des pierres, des potions, des parchemins de bénédiction, des teintures d'armure, des bonus, des sacoches de potions, des ajouts/changement de bonus codés en lua, et j'en oublie beaucoup.

Les files 2012 resteront les meilleurs !

Maintenant il n'y a plus de challenge ! Plus de place pour la bidouille. On se fait chier !

[Doberman 19]

C'est vrai oui la bonne vieille époque

 

"de l'empereur" si tu parles du monarch il y a aussi besoin des sources pour le régler

[Sparks 197]

Je ne parle pas du systeme de 2004 que personne n'a jamais utilisé (d'ailleurs aujourd'hui qui connait les fonctions oh. ?)

Mais d'un système recodé de A à Z en lua (comme tout le reste) avec 3 fonctions et beaucoup d'imagination.

Ça c'était du sport !

 

Je t'apprendrai x)

[Gurgarath 414]

Bonjour,

 

Je t'avais apporté une part de réponse sur Skype mais j'avais utilisé les tableaux afin de montrer un exemple, autrement, c'est bien plus simple et compact d'utiliser des requêtes SQL et tu as tout à disposition pour faire les vérifications adéquates !

 

Premièrement tu as la table player, qui peut ceste être engorgée si tu as un gros serveur, mais qui contient (presque) tout ce dont tu as besoin ! Tu peux parfaitement imaginer faire une requête qui va chercher tous les joueurs ACTIFS (à lier avec le last_play qui est exact à quelques minutes d'intervalle, je peux publier un fix pour l'actualiser en temps réel si vous voulez) entre le niveau 50 et 100 par exemple et qui va stocker ça dans une autre table du genre player.daily_pvp. Après si tu fais une bonne requête, tu auras le pid des joueurs, le pseudo, l'empire et même la race et le sexe si tu as envie, avec la certitude qu'ils ont été connectés il y a peu (et entre le niveau 50 et 100, en général c'est une fourchette de joueurs actifs). Après tu auras juste une requête à créer qui ira chercher dans cette table des joueurs du même niveau que celui qui reçoit la quête... Ou pas ! Après tu pourras décider si tu veux que le système fasse chasser des joueurs de l'autre empire ou pas, de la même race ou pas etc...

De plus tu peux même optimiser ça avec le DirectQuery : Dans les sources, au moment du changement d'empire, tu rajoutes une simple Query changeant aussi l'empire dans la table player.daily_pvp, pour avoir une table à jour (cependant après faut pas renommer la table sinon ça marchera pas).

Et si tu veux automatiser ce système, tu fais une crontab qui vide la table chaque semaine (ou chaque jours) et qui la recrée avec les joueurs actifs au moment de la recréation (normalement faisable mais j'ai un très léger doute) !