Снятие аур 96 и 111 по прокфлагам
 

Сабж. У них для этого есть все необходимые атрибуты, ничего хакать не надо. К тому же достаточно сильно неверный выбор доступных целей для перенаправления.
https://github.com/mangosR2/mangos/c...ddd15ca1bf9f30
Часть коммита в spell.cpp и метод определения доступных спеллов для перенаправления - дискуссионны, возможно требуют дополнительной корректировки (не предлагается к принятию в текущем виде).

может все таки по типам целей ?
targets.getUnitTarget не ок?
у аур всегда есть холдер
омфг хак, потому что в прок системе есть уже нормальное снятие зарядов
-
https://github.com/mangos/mangos/com...c3b6637b2fd995 альтернатива

возможно, я же написал не предлагаются.
а вот тут уж хрен, извиняюсь. прекращайте жить в однопоточном мире. блокированные холдеры в коде удаляются на 2 строчки выше аур - при нагруженном сервере с многопоточными картами имеем пачки крашей с холдер=NULL и аура !=NULL. могу переслать.
кстати, как к их автору, меня вообще удивляет название. раз уж делать холдер - так холдер (двухуровневый курсор с подсчетом ссылок), а тут громким именем назван обычный объект с обычными ссылками... блокировки надо изобретать :(
теперь - есть. на дату патча внимание обратите... тогда ничего не снималось. кроме того, аура 111 пока так и висит в воздухе.

Ауры обрабатываются в контексте потока карты и соответствеено не может быть в _нормальной_ реализации каких-то конкурирующих потоков для одной карты. Мы все-таки говорим о мангосе в даном случае и мы давно приняли решение о поддерживаемой модели многопоточности и менять ее не собираемся.

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

я извиняюсь что встреваю, но можно поинтересоваться зачем?
т.е. в каких сценариях?

я - думаю... я - думаю... я - ничего опять не придумаю (с)

игрок кинул дот (или много еще чего) на другого и портнулся на другую карту. дот на втором игроке (в одной карте) считает SP кастера (или проки), находящегося на другой карте, включая перебор его думмиаур... таких сценариев больше десятка.

я чувствую себя дурачком =) я не знаю всех этих геймерских сокращений =( SP - это что? мне подсказывают что это возможно Spell Power?

в любом случае, что бы там не было, какой то странный дизайн.
у меня создается объект типа TAura, в котором все эти параметры заданы. и он работает сам себе независимо ни от чего. как отработает - снимается. он даже не линкуется к юниту. точнее у юнита нет линка на объект ауры. у ауры конечно же есть.

т.е. при создании ауры я кеширую все необходимые параметры для ее работы в данный экземпляр. кастер больше не нужен.

у вас же получается, что на каждый периодик эффект ауры код лезет в объект кастера и берет у него текущие на данный момент данные. по моему это неправильно по трем причинам:
1. расчеты данной ауры ведуться от значений на момент наложения этой ауры. по крайней мере мне казалось это логичным и косьвенно подтверждалось данными из снифов.
2. ваш HLD приводит к колизиям, что собственно отражено в данном топике.
3. трудности доставки данных на распределенной/кластерной архитектуре.

да кто бы блин спорил... в мангосе объект aura входит в ссылочный бокс-объект spellauraholder, а оба эти объекта (независимо!) прямо прилинкованы к цели и косвенно - к кастеру. конечно она не лезет на каждый периодикэффект (из-за п.1), но вот при наложении и снятии, прокам дополнительных эффектов, связанных аур - лезет. коллизий - ... (причем ауры - это еще не самый вредный источник коллизий в текущей архитектуре).
кластеризация мангоса вообще отдельная песня... в общем прототип выделенного БГ-реалма я сделал, но если кому покажу - уржетесь. самому смешно... :)

Нормальным решением проблемы должно быть не возращение для играков кастера с другой карты. И разрешение проблем с этим связанных.

так часть крашей происходит (ну у меня уже -ла) именно из-за невозвращения юнита с другой карты... впрочем и это, и наоборот глобализация списка юнитов, и блокировки и (что я сейчас в основном делаю) кэширование структур - это все костыли разной степени кривости.

У аур всегда есть холдер _by design_. Ауры никак не могут создаться раньше холдера, следовательно он не может быть null. Если у вас не так - это не что иное, как про*б ваших кастомных пачтей на мультитрединг.

rsa прав в том что мы можем получить на _неправильном_ коде обращения к аурам проблему доступа к ауре на игроке находящимся на дуругой карте.
Решения проблемы я выше изложил - запретить доступ к кастеру ауры находящемуся на другой карте.

Невозвращение - как раз не костыль - при карте на другом сервер у вас нет объекта кастера как такового. Ранее это не работало для аур потому что Done/Taken части урона/лечения не были разделены. Сейчас этой проблемы благодаря Laise нету. Возможно где-то сохранились зависимости работы от наличия кастера ауры, но их не должно быть много и фатально неисправимых вариантов.

но мы же вроде стремимся к максимальному оффлайку? тогда этот путь пролетает, ибо не будем говорить где все эффекты полностью дощелкивают до конца, независимо от смены карты целью. если вы собираетесь кэшировать данные кастера для таких случаев (это то что я делаю сейчас) - то это тоже кривой и ненадежный костыль. другие варианты (кроме расстановки блокировок) есть?
PS дыра с _removeAttacker(this) при мультитрединге кстати гораздо существеннее и я пока не вижу варианта ее решить кроме полной смены дизайна...

Добавлено через 2 минуты
не такие уж они и кастомные, других вариантов все равно пока нету. ауры не могут создаваться раньше холдера, но вот холдер удаляться раньше аур - запросто. я вполне достаточно проковырялся с отладчиком чтобы это утверждать.

Может вы просто приведете пример где кастер с другой карты в ауре нужен?

unstable affliction, immolate. вообще большинство спеллов, где основной эффект дот и дополнительный - по снятии.
PS залез в код чистого, сразу попались: fear, SW:P, freezing trap. можно и по остальным углам кода еще накопать, но эти прямо на поверхности...

Упс, теперь понял. но там должно идти originalcasterGuid.
Возможно требуется более ограниченое получение указателя на кастера
по данному guid - получит ли игрок на другой карте экспу если дополнительный спел убьет от его дота?

там и идет по originalCasterGuid (вроде почти везде). в текущей ситуации мы в 50% случаев обламываемся (безопасно) а в 10% обламываемся (опасно). 40% на нормальное получение ссылки.
по ограничению - это к игрокам вопрос, меня такие тонкости всегда в тупик ставили :)

Не уверен насчёт экспы, но честь дают. Даже если игрока пару раз ударил и портанулся в шторм, и игрок когда-то потом умирает - в чат придёт сообщение "получено очков чести 3 шт"