RG Live WotLK 3.3.5a

Mit dem Zusatz, dass es tatsächlich (bei MT Announce) auf den MT gehen kann (ging vorher nicht), jedoch nicht muss (trotz MT Announce kann es ebenso wieder Rnd in den Raid gehen).

http://i.imgur.com/xxSiiju.jpg

kämpft man alleine gegen ihn hat man immer eine chance, dass das ganze nicht für den mt annount wird - dafug wo wird denn da überall nach dem target gesucht :o

kp was da kaputt ist bei lokalen tests mit 2 chars trifft es immer den mt und geht nie auf den anderen char, was so ja auch nicht sein sollte, obwohl derjenige threat etc auf dem boss hat

krieg es auch net nachgestellt

eventuell gibt es ein problem mit der range oder anzahl an targets? selbiges hatten wir bei marrowgar. wenn nur einer draußen steht, es also camp + spieler y gibt, charged er immer das am weitest entfernteste ziel vollkommen richtig an, sobald aber mehrere draußen stehen, z.b. hinterm camp, charged er auch munter ins camp rein. eventuell könnte das auch hier zu fehlern führen.

Nach 2.5 Stunden LK HM heute auf dem Live muss man eines feststellen.

Der MT/second Tank können ausgewählt werden. Allerdgins ist zu 90% das Announce von DBM/BW falsch, da es immer den Tank ansagt, der in diesem Moment tankt. Das ist wirklich sehr hinderlich, da man das Defile zu 50% über die Sprechblase spielt, da dies der einzige visuelle Effekt dabei ist, woran sich der Raid orientiert.

Hab grad das Ticket gefunden, das beschreibt das selbe Problem: https://redmine.rising-gods.de/issues/15808

Wenn ihr uns das nicht glaubt, kann ich deinen Videobeweis einreichen, sollte kein Problem darstellen. Ich weiß nicht ob es hilft, aber ich bin mir relativ sicher, das dieser Bug sehr häufig auftritt, seitdem die Tanks in die Defile Selection aufgenommen wurden. Ob das stimmt ist natürlich eine andere Sache...^^

tl;dr:
Es wird zu 95% (fälschlicher Weise) der zZ aktive Tank im Defile announced, was falsch ist. (Video auf Anfrage/DBM Warning über dem Tank - Defile woanders im Raid)

ps: wir konnten das auf dem Masterrealm allerdings auch nicht nachstellen...^^

selbiges passiert auch bei den shadowtraps. egal auf wen sie geht, der mt announced es immer. so halt auch beim defile. stellt also keine ausnahme dar.

problem kommt eventuell daher, dass der lk bei der shadowtrap/defile das target ins ziel nimmt, allerdings in dem moment der aktive tank aggro zieht durch eine attacke und somit in der aggroliste wieder nach oben rutscht. dadurch kommt der announce vermutlich auf dem tank.

vieleicht würde es helfen, die normale aggro liste des lks beim defile/shadowtrap auszuschalten, ihn also immun ggn jegliche aggro zu machen und im anschluss zurück zu seinem vorherigen target kehren zu lassen. da er seinen autohit + movement im moment des castens sowieso aussetzt, besteht hier auch keinerlei gefahr für den anvisierten spieler.

Wenn es auch bei den Shadowtraps passiert, müsste es ja generell an der verwendeten Funktion liegen (wird vermutlich die gleiche sein). Da das Ziel von Defile aber meistens ein nicht-Tank ist, scheint die Zielsuche ja richtig zu arbeiten, das Script somit Bugfrei zu sein (lol). Lediglich die Kommunikation in richtung Addon/Client scheitert.

DBM zieht sowohl das Ziel von Defile, als auch das Ziel von Shadowtrap über
targetname = self:GetBossTarget(36597).
Kann es sein, dass der LK bei uns einfach das Ziel zu schnell wieder auf den Tank wechselt?
Dann würde bei Erkennung des Casts das Ziel schon wieder der Tank sein und die Ausgabe wäre dementsprechend.
Wenn die Verzögerung Client<->Server kurzeitig gering genug ist, oder die Verzögerung im script (kann sich da was verzögern?) kurz höher ist als gewohnt, könnte es dazu kommen, dass der LK bei Registrierung noch das Ziel von Defile/Trap als Ziel hat und die Warnung von DBM würde korrekt ablaufen.
Irgendwo muss da halt ne Verzögerung sein - und wenn es nur so lange ist, wie der PC braucht um die Funktionen von DBM zu verarbeiten.

Das würde auch erklären, warum man im Code keinen Bullshit findet und den Fehler kaum nachstellen kann.
Außerdem hat unser Tank neulich das Ziel korrekt angesagt, weil es bei ihm von dbm korrekt erkannt wurde - beim Rest jedoch nicht. Ich habe auch schonmal zwei unserer Spieler rufen sehn, dass Defile auf ihnen sei - Tank und Ranged (war natürlich aufm Ranged).

Lösungsansatz: Den LK beim wirken eines Spotanzaubers für 500ms (Beispielwert - nicht zwingend sinnvoll) auf das Ziel des Zauber fixieren, ohne dass er da hinrennt, oder andere Aktionen ausführt, die er auf einen Tank ausführen würde (Melee). Quasi ne Art Casttime. Er kann ja theoretisch auch so lange stehenbleiben, wenn er grade gezogen wird. Das macht er aufm Offi glaube ich auch, wenn er son Mist auf nen Spieler wirft... bin mir aber nicht sicher und hab keine Zeit n Vid anzuschaun.

Anmerkung1: Die Dauer der Fixierung muss so gewählt sein, dass sie über dem typischen Delay Client<->Server liegt, aber nicht zu lange ist um größere Auswirkungen auf den vom Tank genommen Schaden zu haben (wobei der LK ja eh gebufft ist, also was solls -.-).
Anmerkung2: Eigentlich müsste man sowas ja bei jedem NPC/Boss einführen, aber das sollte man erst besprechen, ob das blöde Auswirkungen hat.

https://youtu.be/RSeVCw3hVgQ?t=9m15s

Hier sieht man ganz gut, das der LK - solange er castet - Xeno im Target hat (den Priest der das Defile abbekommt). Erst nach vollendetem Cast wird das Target gewechselt.
Edit: Das ist bei uns aber genauso, also muss der Fehler irgendwo anders sein.

Wenn er bei uns das Opfer vom Defile auch tatsächlich als Ziel hat, wieso hat targetname = self:GetBossTarget(36597) dann den Tank als Wert?

Die Frage wollt ich vorm testen mal stellen, weil der hack-shit ja nicht sein muss, wenn man die Ursache für den Bug findet.

Waren eben mit mehreren Leuten auf dem Testserver.

Das Defile wurde korrekt verteilt, inklusive DBM Warning. Haben auf die Schnelle nichts gefunden, was den LK verbuggt/nichtmehr zuschlagen lässt. Zeit bis zum nächsten Angriff war vollkommen passabel.
Ich muss dazu sagen, das ich das Defile Announce Problem leider nicht nachstellen konnte auf dem Testserver(schon vor der Veränderung des reactstates).

Wahrscheinlich kann man das nur "richtig" auf dem Liverealm testen.

Sah heute ganz brauchbar aus.

nice

Bedeutung Live:

Der Bug wurde erfolgreich behoben und befindet sich auf dem Spielserver. Sollte der Fehler weiterhin bestehen sollte ein neues Ticket ( https://redmine.rising-gods.de/projects/live/issues/new ) erstellt werden. Anmerkungen in dem alten abgewiesenen oder live genommenen Ticket werden ignoriert und gelöscht.