Если не брать в расчет аддон (версий Mik's Scrolling Battle было много для патча 3.x.x https://mods.curse.c...other-downloads как и опций для настройки), может ли разработчик проверить это по БД клиента/серверной части?

Ребят, вопрос: если на цели 2 бафа одного типа магического эффекта (2 жизнецвета, например) и омоложение, в каком порядке при прохождении диспела должны быть сняты положительные эффекты с цели?

Сообщение отредактировал JetFire: 21 сентября 2016 - 19:21

Автор, а это по твоему что?

Resist! [2 Hits]

Тоже записал видео, что не так?

Автор, а это по твоему что?

2:25 на твоём ролике

но с последним бафом на таргете неверно работает, все-таки 1 раз должен диспел проходить

список таких диспелов с ролика:

Ну хорошо, один случай вижу на 2:59. Все остальные приведённые тобой случаи бесполезны: диспел прошёл, бафов больше нету, вторую попытку диспела проводить просто не на чем, она не может ни срезистится, ни успешно завершиться. Но всё же правка слишком глобальная (и крайне нелогичная), попрошу найти побольше подобных случаев чтобы убедить меня.

Единственная причина такому поведению, которую я могу представить: близзы сделали чтоб диспеллилось не-больше-чем-есть-на-цели-диспеливаемых-аур аур, иными словами min(2, кол-во диспеливаемых аур). Но в таком случае могут потенциально перестать работать всякие системные и ивентовые спеллы, диспелящие по 100, 100000 аур (типа полный диспел). Такие большие цифры там навернека для того, чтобы по несколько раз попытаться сдиспелить с цели ауры, если предыдущие попытки провалилсь из-за резиста. Но эта правка сделает такие спеллы ненадёжными - количество диспелов будет уменьшаться до количества аур на цели и некоторые из них всё же смогут проскользнуть через проверку резиста.

 

Ну хорошо, один случай вижу на 2:59. Все остальные приведённые тобой случаи бесполезны: диспел прошёл, бафов больше нету, вторую попытку диспела проводить просто не на чем, она не может ни срезистится, ни успешно завершиться. Но всё же правка слишком глобальная (и крайне нелогичная), попрошу найти побольше подобных случаев чтобы убедить меня.
 
Единственная причина такому поведению, которую я могу представить: близзы сделали чтоб диспеллилось не-больше-чем-есть-на-цели-диспеливаемых-аур аур, иными словами min(2, кол-во диспеливаемых аур). Но в таком случае могут потенциально перестать работать всякие системные и ивентовые спеллы, диспелящие по 100, 100000 аур (типа полный диспел). Такие большие цифры там навернека для того, чтобы по несколько раз попытаться сдиспелить с цели ауры, если предыдущие попытки провалилсь из-за резиста. Но эта правка сделает такие спеллы ненадёжными - количество диспелов будет уменьшаться до количества аур на цели и некоторые из них всё же смогут проскользнуть через проверку резиста.

шаман:

присты:

И следующей ситуации с последним бафом ни на одном из видео тоже нет:

Почему так было сделано можно понять: противника диспелят во время контроля под ноль и 1 баф после этого было бы слишком легко сдиспелить из-за того, что шанс на него 91%, а не 70%.
 
Видимо необходимо для игроков отдельный диспел реализовывать

Сообщение отредактировал bgggwp: 22 сентября 2016 - 08:31

 

Пруф:

 

http://www.warcraftm...w.php?id=121411

Время 3.17. Внимание , на цели шамана такие бафы в таком порядке:

1) Омоложение (был наложен первый)
2) талант на уменьшение урона в ветке дерева (второй) - затем обновлен 1
3)Жизнецвет (третий) - затем обновлен 2
4) Буйный рост (последний)

Теперь ставим на скорость 0.5х и наблюдаем два резиста по омоложению - то есть он пытается пуржить слева на право (хотя последним был наложен буйный рост) и делает 2 промаха, что вроде как подтверждает 2 подряд диспела.

На 3.19 он диспелит жизнецвет, хотя левее находится омоложение, а правее находится буйный рост и талант на уменьшение урона. И заметьте - нет сообщения о резисте, хотя вроде и не пишет что сдиспелило 2 стака (а там прям перед пуржем - прокнул талант и + дру настакал 2й жизнецвет). Сразу не увязочка : сперва диспелил самый первый баф, а потом самый последний?

В итоге этот случай говорит о том, что :
1) первый наложенный баф находится слева на баре персонажа
2) Диспелит он и последний баф и начиная с первого наложенного ? (не ясно)
2) Если он стакается - на баре не перемещается. (это даже не имеет смысла так как я отслеживал таймеры бафов и там видно, кто наложен последний)

То есть есть скрытый листинг с приоритетами.(первая мысль)

Теперь 3.32 - видно как на друля накладывается талант на снижение урона, затем омоложение...потом заставочка... и третий баф это КД на мгновенный каст.

1) талант на уменьшение урона в ветке дерева
2) Омоложение
3) Мгновенный каст

И смотрим на диспел перед смертью друида:
Если внимательно смотреть, то видно , что на видео разрыва во времени нет (на 4.04 видно при перемотке назад, что таймер бафа от таланта не обновлялся) , хотя возможно что интерфейс не успел обновить прок таланта на уменьшение урона, но!! порядок диспела не соответствует порядку наложения бафов (опять же).

Затем на 4.20 видно, что на ДК первым был наложено Восстановление (логично из-за времени каста), однако первым в очереди бафов оказывается омоложение(что?)

На 4.40 вроде все правильно: последний был талант на уменьшение урона, с него диспелл и начался.

Еще один интересный момент 5.57
1) талант на уменьшение урона несколько стаков (тоесть в списке по диспелу должно быть первее), потому что у него время 8 секунд , тогда , когда у омоложения минимум вроде 15сек. При этом там уже половина оттикала.
2) омоложение
3) жизнецвет
4) залив на ману
5) дубовая кожа

Ииии!!! два резиста по манарегену!!!! хотя последняя была дубовая кожа!

Затем диспелит жизнецвет, хотя манареген все еще висит на цели и дубовая кожа. Не видно сколько стаков было изначально (думаю 2) но резистов нет (значит должно диспелить 2) , но 1 стак остается на друле... смотрим дальше!
6.01 - баф от тала на уменьшение урона сам по себе падает с друля и снова 2 резиста по манарегену!!! (последняя была дубовая кожа!!)
6.03 - два резиста по дубовой коже! (неужели)

7.27 :
1 ) стаканный талант на уменьшение урона (таймер свежий, а в списке первый, значит первый на диспелл)
2) жизнецвет - о стаках трудно сказать
3) свеженькое омоложение
Получаем диспелл 2х стаков таланта на уменьшение урона ( вроде логично - он обновился недавно)
Потом добавляется буйный рост 4)
и!..........!!!! Игнорится буйный рост!!! диспелится омоложение, затем жизнецвет неудачно!
Жизнецвет обновляется, но после этого вешается клиркаст на бесплатный спелл. Однако следующий диспелится жизнецвет и почему-то не пишет х2(хотя может баг аддона)
Буйный рост снова игнорится, первым диспелится клиркаст, а затем буйный рост, который не проходит.
Затем накладывается омоложение и клиркаст! И заметно как в этот момент обновляется талант на уменьшение урона(должен быть в первых рядях). Но! почему-то диспелятся омоложение и клиркаст.
При этом на друле висит жизнецвет (Просто была мысль о том, что только что наложившиеся бафы имеют гкд, который меняет их приоритет на более низкий на некоторое время, но так как жизнецвет висел уже давно - тоже как бы не верно).

В общем просмотрев затем все остальное я понял:
1) В приоритете стаки (тоесть если 3 стака, сначала будут диспелится первые 2, а лишь затем оставшийся 1 и следущий баф)
2) Если первый бросок на резист проходит - резистится сразу весь спелл, а если первый бросок небыл срезищен - второй всеравно имеет вероятность резиста (иначе почему нет в видео моментов, где 1 бросок срезищен, а второй нет, хотя были моменты, когда снимало 2 стака из 2+, а писало что один баф (но это не имеет отношения к резисту, так как там было 2+ бафа))
3) Никаких приоритетов на диспелл нету
4)Никаких скрытых таймеров нету на диспелл
5) Никакого порядка на диспелл нет
6) Такое ощущение, что диспелл работает таким образом:
6.1) Берется список бафов, которые можно сдиспелить
6.2) Рандомно выбирается баф и делается бросок на резист - если небыло резиста - выбирается соседний баф и тоже пробует резиститься. Если соседнего нет (первый был крайний), то берется соседний с другой стороны. Если уже и с другой стороны нет - броски прекращаются.

Хотите верьте, хотите нет, но правда такова , судя по видео С ОФФФААА!!!!!!!
Так что на изенгарде работает неверно, и ТС тоже неверно предоставил пруфы и его догадки тоже неверны.

Однако никто ничего менять не будет, так как начнется вайн на тему: "как теперь жить ДЦ пристам, у которых стаки от хилки спасали от диспела щитков"

Сообщение отредактировал Shadowlike: 21 января 2018 - 03:42

Ненадо делитать ссылку на тему обсуждения проблемы с диспелом,2 и 3 страницы читабельны https://ezwow.org/to...m-chini-server/
Если здесь и в топике описаны разные ошибки, пожалуйста сообщите - создам новый репорт
Спасибо

До скончания времен, помнишь?

Я не пойму , в чем проблема? я по секундам расписал. У кого хоть капля мотивации есть - заметит , что диспел диспелит рандомно+1 со сдвигом в списке заклинаний. (у нас диспелит последние наложенные).
И там прекрасно видно (дай Бог здоровья тому, что выложил и нашел это видео) в бою с друлем, где большая куча бафов как себя ведет диспелл. А именно : от либо резистится на первой попытке сразу на 2 попытки, либо на последней попытке. (На сервере: 1 баф 95% будет сдиспелен за счет двойного диспела по нему).

Почему это так важно? У классов мало бафов в принципе и как бы механика плохо прослеживается. Но вот яркий пример - присты. У них в ДЦ и ШД ветках много проков самобафов(как и у кучи классов - даже тех самых палов). И чтоб с них чето сдиспелить - нужно нонстоп спамить пурж. При этом добраться до щитка трудновато, к примеру вару с Мощный удар щитом. Смысл этой абилки в данном случае впринципе только на Джакартусе, так как в пвп ты максимум что собьешь - это очередной стак +3% к урону или чето типа того.

Рандомизация диспела позволит:
1) иметь шанс не потерять тот же манареген с 1 пуржа после наложения (на видео прекрасно видно как с друля диспелились другие бафы, когда последний был баф на манареген)
2) иметь шанс сбить щиток присту, не пробираясь с 6секундным кд +30% резиста через кучу бафов, обновляющихся почти каждое ГКД.

А кто сказал, что это можно реализовать? Если это вообще правда, а не банальное совпадение?
p.s: разработчика все еще нет на х2, можешь не утруждаться.

https://github.com/T...pellEffects.cpp
Даже на оф репозитории Тринити вот какой код:

Сообщение отредактировал Shadowlike: 22 января 2018 - 23:29

В общем я почитал смежные темы и понял, что вроде у нас и работает как нужно, прям так как я и посмотрел в видео с друлем. Так что поростосту сверте код с оф репо тринити и все на этом. Просто думал, что все наоборот, так как на старых пиратках данный баг просматривается.

Сообщение отредактировал natadru: 21 мая 2019 - 06:50

Сверил, у нас так и работает. Клозаю.