|
⚠ Archive en lecture seule —
Retour sur GeekServers.gg
39 messages
• Page 1 sur 1
Bonjour TGC,
Tout d'abord sachez que ce post est loin d'être désinteressé. En effet il y a, hélas, une vraie solution a trouver pour le problème de crash suite au down d'un boss AVANT que les items puissent être attrib. (Pour notre part, nous avons perdu 2 des meilleurs trinket en 2sem, le crâne, et la folie sans avoir été capable de les récupérer.) Je sais que personne n'est exempté vis à vis de genre d'aléas, que ce soit les guildes T6 ou T5 (tout le monde est touché par cela vraiment). Après evidemment ce problème (dont j'essaie de trouver une solution) ne concerne que les PVE boy (même si les crash sont handicapants pour les PVP boy (arene intensive, bg long etc) Il faut savoir que, contrairement à la politique passée de récupération de loot du serveur Nostalgeek (Ceci est légitime vu la quantité de travail que demande un crash pour les membres du staff), il n'est pas possible sur TGC de récupérer un item non attribuer avant un rollback (même à l'aide d'un screen car celui-ci peut être aisément trafiquer via psd). Bien sur le staff est conscient de cela et quand il le peut il cherche des solutions à ces problèmes. Pourtant je pense que c'est a nous aussi d'apporter des solutions possibles au sein de ce poste (réalisables, censées, et équitables) 1) Voici la première suggéré par Darcknaruto : Permettre au Leader d'un raid de récupérer et de garder les items 5min afin de pouvoir les prendre après la mort du boss, de .save et d'ensuite les répartir. (Bien sur cela rentre en contradiction avec le débat de possibilité d'échange d'items LQR au sein d'un même raid comme à WOTLK). Il peut aussi permettre l'abus de certains RL dans certains groupe Pick up, c'est pourquoi des conditions doivent être mise (25 joueurs d'une même guilde par exemple, serais une des conditions). Cela pourrait être une solution, même si cela enlève le côté Blizzlike comme me l'a dis Ceyl hier en PM. D'autre part l'idée de pouvoir trade un item LQR a été abandonné pour des raisons de blizzlike (chose que je cautionne aussi, même si dans ce cas précis, ce n'est pas 2H d'échange, mais 5min et que seul le RL puisse en profiter) 2) Suggestion de Totow : Désigner quelqu'un dans le raid qui fraps durant le raid et qui si un crash a lieu après un down, il y aura une preuve tangible et très difficilement trafiquable, que tel ou tel loot est tombé sans avoir été attrib. Cette idée est interessante mais elle oblige chaque raid a avoir qqn qui fraps (C'est plus une solution joueur que serveur) 3) Suggestion de Lionolol : Créer une filet de sécurité ou une dérogation spéciale pour certains boss dont les loots sont des Best in slot pour beaucoup et ceux sur le pallier T6 ainsi que T6.5 (Comme Gruul, Karathress, Vashj, Illidan, Archimonde, Leotheras, Conseil...). Cela permettrais d'éviter ce genre de perte colossale pour l'optimisation d'une guilde dont l'objectif est very hl. (Comme le sextant, le tsunami, la robe de vashj, ou autre.) En effet, ce genre d'objet est très rare et prisé par beaucoup de monde. Si les crash empêche les joueurs investis d'être récompenser vis à vis d'un item dont il ne se sépareront jamais pour certains (en tout cas sur cette extension), je pense que cela est un frein à l'avancée PVE des guildes (aussi infime soit t'il sur les aspects d'opti et de mathématiques, je peut vous assurez que cela touche beaucoup les gens sur leur volonté d'investissement ainsi que sur l'aspect humain.) Il s'agit d'un pavé désolé, avec pas mal de fautes. J'invite les personnes constructives à participer à ces émissions d'idées afin de trouver, si possible, la meilleure solution pour pallier à ce problème qui touche tout le monde.
A vrai dire, je ne trouve pas que ma solution soit la plus optimale, en revanche ce qui est sûr c'est qu'il y'a une mesure à prendre ici avant que l'irréparable (la warglaive :D) soit commis.
Voir une solution technique avec le staff en parallèle à la communauté me parait être un bon début
Attention, toutes les questions que je pose ne sont pas forcement fondés. Je pense qu'il est bon d'y penser pour pas qu'on fasse n'importe quoi.
1) Si le Raidlead loot, il a 5min pour les réatrib. Mais si il y a un crash? Les 5mins seront certainement écoulés non? Tu suggères que le staff redistribue les loots qui sont dans les sacs du RL? On a la preuve que ces loots sont tombés mais prenons l'exemple d'une WG gauche qui tombe alors que Sharqs n'est pas là. Un tp rapide et paf l'échange? Si on met une limite aux membres du roster. Un crash ne va pas faire bug cette limite? Comment le staff pourra savoir si le joueur était réellement dans le raid? Pour les RL peu scrupuleux en pick up, le problème existe déjà, il peut se les attrib. Je trouve pas nécessaire de mettre des conditions. 2)Je trouve cette solution vraiment horrible pour le staff. Lors d'un crash un dimanche soir s'il doit traiter toutes les vidéos, vérifier le jour et l'heure et les loots pour chaque raid. Il y a de quoi devenir fou. 3) J'ai pas compris la suggestion 3. Elle est indépendante des autres ou sert à les compléter? Pour l'argument blizzlike, il n'existe aucune solution blizzlike puisque cela ne se produisait pas sur offi. Si on veut une solution, elle sera forcement custom. La solution 1 comme la solution 2 sont biens uniquement si elles sont couplés à la solution 3. On peut même réduire à certains loots plutôt qu'à certains boss. L'idée est de ne pas faire perdre des heures au staff pour des loots réguliers ou inutiles. Ca pourrait mener à un refus de la suggestion vu qu'il n'y a personne de confiance à part Lorh et peut être Ceyl qui pourront le faire et qu'ils ont du boulot à côté.
Moi j'ai pas compris comment fonctionnerait la 3) mais la question se pose en effet. A quoi ressemblerait techniquement ce filet de sécurité, cette dérogation spéciale ?
Nous nous efforçons de rendre ce serveur le plus "blizzlike" possible pour un plaisir de jeu authentique.
Le contenu PVE est en version PRE-NERF.
1) Je pense qu'il est possible de faire en sorte que seules les personnes qui étaient sur le down puisse accéder au loot. Si le crash a lieu quand le rl a récupérer les loots, c'était à lui de .save ou alt F4 avant la distribution.
2) Niveau du fraps, quelle est la probabilité qu'il y ai plusieurs guildes raid 25 ayant fraps un down et les loots avant un rollback ayant down un boss en même temps. 3) Concernant l'idée du filet de sécurité, c'est une idée soumise sans exemple technique a mettre en place. Il est sans doute possible de savoir ce qu'a loot le boss avant un rollback même si cela est beaucoup de travail si la mise en application ne se fait que sur 5 boss spécifiques (ceux cités avant) Je ne dis pas que ces idées sont géniales et doivent être mise en application maintenant, il s'agit d'un brainstorming ouvert ou chaque solution sera discutable avec la communauté, c'est déja un pas en avant .
Ce que je ne comprends pas, c'est pourquoi il y a un rollback a chaque crash ? Sur tous les serveurs privés que j'ai fait, NG-TGC sont bien les seuls où un rollback insane, comme il peut y en avoir ici, se produit à chaque crash.
Autrement, il faudrait également trouver une solution pour le courrier envoyé avant un crash et qui est perdu par la suite. (Oui je me suis fait enc*lé 5k po lors d'un crash )': )
N'est il pas possible de loguer les loots importants (WG, crâne, tsunami etc...) au moment du loot ? Genre sous forme "[DateHeure] - Loot de [idItem] par le raid [idRaid]" (l'id visible dans l'interface joueur) afin de ne pas avoir a fournir de "preuve" côté joueur? Car on sait que c'est facilement falsifiable, et à juste titre pas accepté pour rendre un loot.
Après la question se pose toujours de quel loot/boss inclure.
Lahna <Roster Papillons>
Apofix <Roster Papillons> Llonaär <Air>
Pour la 1 j'y ai pensé parce que sur offi, on pouvait sur requête demander qu'un item qui nous avait été attrib par erreur soit attrib à un autre. Le MJ retirait l'item de notre inventaire pour le mettre dans celui de la personne désignée.
Pour la 2 une vidéo reste traffiquable comme un screen malheureusement
Il s agirait de fraps que l ouverture de la fenêtre de loot et non pas du fight entier ! Mais c'est assez relou et contraignant...
Sinon pour le screen il peut être trafiqué mais il faut un certain temps quand même pour truquer une image. On pourrait mettre en place certaines conditions sur ce screen du style une commande à taper genre /Played avant crash et après crash avec une labse de temps de 6 min 38 sec pour envoyer les screen à lorh et tout sa de différents PoV (trafiquer 6 screen en 5 min dure dure..) Sinon la première solution est intéressante !
Screen de minimum 3 (ou plus) personnes dans le raid ?
Rise and rise again until lambs become lions.
3 sa me paraît cool nan ?
Sa permet de vérifier l état du raid, si personne n'a été tp, si y a rien de trafiqué d'un screen à l autre etc..
Trafiquer un screen c'est simplement prédécouper une image d'un loot que l'on veut avec le nom de l'item. On peut le faire avant le boss et préparer comme ça tous les icônes de tous les items. On screen à chaque fois le boss quand on le tombe, et s'il y a crash on ouvre photoshop ou gimp, on ajoute un calque, on importe l'icône, on aplatit, on exporte, on upload et c'est réglé. Ca prend pas plus d'une minute pour quelqu'un qui touche photoshop.
Je plussoies. Il faut rajouter qu'un screen ne peut être valable qu'en donnant un maximum d'informations compliqué a falsifier (Chat sans fond noir mais avec le décors a travers, world actif, horloge...) On peut y rajouter un mot clé. Mais il faut bien comprendre que même si ce système était mis en place, il diminuerait les pertes d'objet dû aux crash, beaucoup de gens en seront heureux, puis 1 ou 2 mois plus tard, les gens réclameront que la restriction soit un peu moins strict en ajoutant tel ou tel objet... Il est difficile de passer l'étape de la mise en place pour plusieurs raisons autres que la difficulté technique (un additem n'est pas compliqué en lui même) Seul Lorh & Ceyl disposent des droits nécessaire a une réattribution d'objet, ne pouvant faire intervenir Lorh toutes les 2minutes en jeu (car a chaque crash ca sera ça avec ce droit) il ne reste que Ceyl qui ne pourra absolument pas se diviser en plusieurs exemplaire pour répondre aux requêtes. De ce fait il n'est possible de mettre en place qu'en mettant une restriction aux objets critique (plutôt qu'aux boss), concrètement un token peut être rare mais il tombe quand même, un tsunami par contre... farm SSC pendant 6 mois j'en ai pas vue un seul. Dans tous les cas seul seront décisionnaire les admin's quand a la possibilité de mettre en oeuvre ceci, je ne fais que donner mon avis, concernant ce dernier, il est mitigé... L'envie de satisfaire la communauté est présente et tend a vouloir soutenir un tel système, de l'autre... Les difficultés que cela pourrait engendrer (notamment a Ceyl car je penses a la machine mine de rien) sont assez grande. Je m'abstiens donc de +1.
Privilégiez google pour vos questions, généralement la réponse survient au bout de 5 minutes.
En tous cas nous suivons avec attention la suggestion côté staff.
Néanmoins, nous partons plus sur une réflexion qui permette une modification côté serveur, et non pas une amélioration côté joueurs. En effet, toutes les ressources provenant des joueurs sont trafiquables, et on connaît la propension à tricher d'un certain genre de joueurs. Du coup, je ne peux que vous encourager à changer vos pistes sur les vidéos ou les screens.
C'est déjà un énorme pas, et pour le coup je suis d'accord avec toi Ballmeyer, on va continuer d'y réfléchir et d'émettre des idées
Personnellement je verrai plus un système qui garde les loots en mémoire une fois la fenêtre ouverte mais dans le client (donc à l'abri d'un RB j'imagine).
Il suffirait de reDL un fichier modifié par Lorh (qu'il aura rendu infalsifiable) et de le mettre dans notre dossier WoW. Après, si RB il y a, on pourrait lui présenter ce fichier où les informations seraient resté en mémoire comme preuve. Je ne sais pas si c'est possible, ni les complications que cela peut engendrer, je propose seulement. :)
Le problème reste inévitablement le même à chaques fois et pour chaques problèmes du serveur, ON NE PEUT PAS GÉRER UN SERVEUR A 2 OU 3
Il faut savoir investir, déléguer.
On a demandé un soutien financier à Liliane Bettencourt mais en ce moment elle est plus très chaude pour prêter de l'argent à ce qu'on m'a dit. Pour la délégation, on attend toujours des candidatures de développeurs. Si t'es motivé, n'hésite pas à proposer un projet de réforme et à le faire passer en force au staff. Par contre y'a pas d'équivalent au 49-3 sur TGC. Sorry. :/
Salut!
, ou même les guildes ayant un niveau inférieur (voir pas de niveau du tout pour les joueurs en phase de pex) car à l'instar de devoir refaire un boss pour les plus équipés, c'est souvent beaucoup de marche à pied/bash à refaire pour les autres à chaque crash du serveur. N'étant pas en accord avec les solutions proposées plus haut, et ce pour des raisons qui ont déjà été évoqué (falsification trop aisée des screenshots, masse de travail énorme à rajouter au boulot des mj dans les traitement de tout les fraps/requêtes) pourquoi ne pas supprimer purement et simplement les boss dont on sait qu'ils présentent le risque de faire crash le serveur?* Cela avait été fait à un moment pour Frankriss (qui envoyait le serveur ad patres à chaque pull) sur NG. Bien entendu, et cela a été très justement précisé dans le premier post de ce topic
mais l'intérêt d'une poignée de joueur doit il passer au détriment de celui des autres? Je rajouterais que tout le temps passé à sortir les joueurs des zones bug/à traiter les requêtes si ce mode de fonctionnement est pris en compte est du temps perdu à corriger le problème à sa source. * Jusqu'à ce qu'une solution ait été trouvée, bien entendu.
Pourquoi ne pas faire un petit addon ?
Tu loot, l'addon récup instant des infos du genre ID de raid/boss/id des items drop/nombres/ect ... ( l'api de Wow le permet des adons utilisés déjà ces "commandes" comme Xloot ) il pourrait être synchronisé entre tous les membres du raid un peu à la manière des addons comme recount et les données envoyées sur la partie "admin" de l'addon que seuls les Mjs auront à disposition Et si certains items ont eu le temps d'être attrib il est aussi possible de récupérer les infos comme qui a loot quoi . Bien entendus les données reçus par les Mjs devront être enregistrés constamment pour pas les perdre après reboot Gros problème par contre trouvez quelqu'un qui a des notions de language LUA . *dsl pour les fautes ma compétence langue francaises est pas up au max*
Nous avons pensé à l'add-on en effet, mais là encore l'add-on est du côté du joueur, et une personne avec des compétences pourrait trafiquer son add-on à son bon vouloir.
L'une des limites actuellement c'est trouver un système qui ne génère pas une quantité monstrueuse de données.
solution 1 : Que le serveur crash plus ! :>
Voilà! je mérite un cookie car j'ai trouvé la solution a cette suggestion :D
Au delà du fait que j'apprécie ton humour toujours au gout du jour, mais je t'avoue que me faire le coup du "vas y passe devant si tu y tiens tant" à moi, c'est vraiment osé, le problème n'est pas le manque de volontaires, mais le manque d'investissement (et on parle pas de finances là) et le manque de confiance. J'aimerais vraiment que les choses changent, c'est juste du gâchis.
Je t'assure que le problème c'est bien le manque de volontaire. En matière de développement, les admins sont prêts à faire confiance, mais il n'y a juste personne qui propose des scripts occasionnels, base de toute candidature de développeur sur NG et TGC, de tout temps.
Pas moyen d'implanter un .save auto après qu'un loot épique ou légendaire atterisse dans les sacs?
bang bang on est les kings du sudoku vs etes dans la jalousie ; merci pr le script parféé
En général quand un joueur a eu son item, il fait immédiatement un alt+f4 (ou un cmd+Q). Je pense que le problème vient surtout des crashs entre la mort d'un boss et la distribution des loots non ?
Et cette idée du .save auto ne pourrait elle pas être appliqué dans le process de fermeture du serveur? comme une sécurité, de sorte qu'il applique une sauvegarde juste avant qu'il ne se ferme, laissant à cette occasion le/les mobs avec leur butins.
My bad je savais pas que les crash étaient assez fréquents pour que ce genre de mésaventures devienne un vrai problème lol
bang bang on est les kings du sudoku vs etes dans la jalousie ; merci pr le script parféé
Un conseil déjà, mettez-vous une macro avec un de vos sorts les plus utilisés et un .save ça permet déjà d'éviter pas mal de RB.
Le .save ne fonctionne pas.
Stryfe a fait ce que tu as écrit, il a eu le même rb que les autres.
apparemment après entretien avec le grand manitou, le .save fonctionne 1 fois toutes les 5min maximum.
Et pourquoi ne pas mettre un pnj invisible a coté de chaque boss ? Je ces pas si c'est possible que ce pnj voient la table des loots
Clean. vous pouvez repartir sur le sujet.
Je pense que le problème sera le même, il sera lui aussi impacté par le Rollback.
Bonjour
J'y connais rien d'un point de vue technique mais j'ai remarqué qu'à chaque crash, si les joueurs ont un roll back et reviennent souvent à l'endroit où ils etaient 10 minutes avant, les mobs du raid qui ont été cleans pendant ces 10 minutes eux restent bien disparus. Comme je l'ai dit je ne sais pas comment c'est sauvegardé mais y'a pas moyen de faire pareil concernant les loots, faire que le serveur "se souvienne" aussi?
Une idée :
- A priori lorsqu'un boss est down, la DB est mise à jour dans une table prévue à cet effet (enregistrer l'avancement sur chaque ID) - On crée une table avec un champ référençant cet ID, et un champ pour les loots - Lorsqu'une table de loot est générée, on demande à mangosd d'accéder à la DB et de faire une insertion de la sérialisation des loots pour l'ID du looter dans la table créée Ainsi on pourrait avoir les derniers loots obtenus pour chaque ID en cours.
Bonjour,
Uniquement en raid, un table des loots alimentée au down d'un boss : id loot, etat (down, distribué, dez, jeté, ...), id joueur qui le reçois, un timestamp. Un commit à chaque manipulation de la table pour éviter le rb de cette table. Chaque enreg a une durée de vie max, pour éviter d'engorger la table, genre max une heure.
39 messages
• Page 1 sur 1
|