любое событие имеет колбек, у способностей есть колбеки практически на всё, так и обеспечивается диспел при смерти, например. А тут всё вручную, но это и не для простого тыканья.
по умолчанию отрисовывается только для пары способностей, я взял ракету и заблокировал её использование. это редактирование рид-онли памяти, поэтому крайне желательно иметь восстановление адресов через длл
function GetEvasionOrderIdFunctionData takes nothing returns nothing
local integer a
local integer oldprotection
call UnitAddAbility(SentFountain,'AEev')
set a=GetUnitAbility(SentFountain,'AEev')
if a>0 then
set pEvasionOrderIdFunction=RMem(RMem(a)+0x30C)
if pEvasionOrderIdFunction>GameDLL then
call UnitAddAbility(SentFountain,'A3HQ')
set a=GetUnitAbility(SentFountain,'A3HQ')
if a>0 then
set a=RMem(a)+0x30C
set oldprotection=ChangeOffsetProtection(a,4,0x40)
call WMem(a,pEvasionOrderIdFunction)
call ChangeOffsetProtection(a,4,oldprotection)
endif
call UnitRemoveAbility(SentFountain,'A3HQ')
endif
else
//port value from AEev to Afla to disable icons
endif
call UnitRemoveAbility(SentFountain,'AEev')
endfunction
где SentFountain - любой юнит, которому нужно вручить абилки для их подзагрузки; AEev - уклонение, чтобы взять адрес "нерабочей" кнопки, "A3HQ" - любая абилка на базе ракеты, тоже для получения адреса
Потом - если у ракеты 0 зарядов изначально, счетчик скрывается, поэтому
function FixChargesIndicator takes unit u, integer id returns nothing
//if 0 charges by default indicator is hidden by the flag, need to reset it
set LastConvertedHandle=GetUnitAbility(u,id)
if LastConvertedHandle>0 then
call WMem(LastConvertedHandle+0x20,0)
endif
endfunction
Ну и управление
function RedrawSkillAfterChargeModify takes integer a returns nothing
local integer b=RMem(RMem(a)+0x1C4)
call CallThisCallWith3Args(b,a,0,852290)
endfunction
function AddAbilityCharges takes unit u, integer id, integer c returns nothing
local integer a=GetUnitAbility(u,id)
if a>0 then
call WMem(a+0x124,RMem(a+0x124)+c)
call RedrawSkillAfterChargeModify(a)
endif
endfunction
function AddAbilityChargesByAddr takes integer a, integer d, unit u returns nothing
if a>0 then
call WMem(a+0x124,RMem(a+0x124)+d)
call RedrawSkillAfterChargeModify(a)
endif
endfunction
function SetAbilityChargesByAddr takes integer a, integer d returns nothing
if a>0 then
call WMem(a+0x124,d)
endif
endfunction
function GetAbilityCharges takes unit u, integer id returns integer
local integer a=GetUnitAbility(u,id)
if a>0 then
return RMem(a+0x124)
endif
return 0
endfunction
function GetAbilityChargesByAddr takes integer a returns integer
if a>0 then
return RMem(a+0x124)
endif
return 0
endfunction
высота бара неизвестна и стандартными средствами получить её невозможно, у каждой модели своё
смещение делается аналогично привязыванию к юниту - таймером и перестановкой
функция не триггерит UNIT_ATTACKED т.к. является именно дамажущей, замах генерирует другая функция
она просто выполняет атаку, и все особенности, что есть у юнита и реагируют на удар, сработают.
баш и крит реагируют на замах, пгоэтому их нужно обрабатывать вручную
клив тоже включается на замахе, но при этом всегда еще использует координату атакующего как точку отсчета для клива, а не координату цели, поэтому - придется подвигать на нужную позицию пред атакой
сложностей много, но делать мультиатаку из обычных ничуть не легче - вопросов только больше
строки не текут по определению, они навсегда остаются и их невозможно стереть, при генерации около 50к строк фпс заметно падает, но ничего с этим не сделать
Проверил на 1.26
Списки юнитов остаются на месте, однако их заголовок ломается, якобы освобождая ячейку, ссылки на участников группы считаются стертыми. Получается, можно и не чистить список перед уничтожением. Просто в памяти адрес остается висеть, но может быть затерт, если заголовок гговорит, что тут никого нет (после дестроя именно так).
Вопрос не связан с самим существованием юнитов внутри группы после смерти, они вроде как не удаляются, я точно один раз лечил зависание мертвых иллюзий в списках.
помним, что такое обнуление - это уничтожение ссылки на объект, чтобы этот объект можно было считать неиспользуемым и УДАЛИТЬ. Если объект остается в игре до конца, т.е. не исчезает никак, пока карту не закроешь, его можно не нулить. Это может быть вечный триггер, это все игроки, это юниты, кооторые никогда не уйдут с карты - их обнулять не нужно.
массивы - то же самое, что и обычные любые другие переменные. Увеличение кол-ва ссылок происходит при присвоении значения переменной. И неважно, массив там был или обычная.
Ну разумеется обнуляем массив, иначе будет утечка.
утечка - это ссылка на объект, который больше не нужен. массив нужно обнулять, чтобы эти объекты удалились дальше. неважно, выделена под него память или нет, важно, что будет с объектами. Поэтому хендлы чистить надо
список юнитов остался висеть в памяти после дестроя группы. Не, ну, возможно, к нему сборщик мусора через пару минут заходит, я не ждал. Можешь попробовать группировать бесконечно в новые группы и разрушать их, глянешь, будет память расти или нет
» WarCraft 3 / Подключение новой расы
» WarCraft 3 / Хак на память Warcraft3
» WarCraft 3 / Как опустить подсказку над героем?
» WarCraft 3 / Краш у локального игрока
а можно и просто десинк
» WarCraft 3 / Проблема с морфом
» WarCraft 3 / [Мемхак] Кто нить нашел адрес счетчик способности?
» WarCraft 3 / Опять утечка, может ли утекать переменная типа строка?
» WarCraft 3 / Плавающий текст над героем
смещение делается аналогично привязыванию к юниту - таймером и перестановкой
» WarCraft 3 / 1 скилл пангольера в варкрафте
она просто выполняет атаку, и все особенности, что есть у юнита и реагируют на удар, сработают.
баш и крит реагируют на замах, пгоэтому их нужно обрабатывать вручную
клив тоже включается на замахе, но при этом всегда еще использует координату атакующего как точку отсчета для клива, а не координату цели, поэтому - придется подвигать на нужную позицию пред атакой
сложностей много, но делать мультиатаку из обычных ничуть не легче - вопросов только больше
Ред. DracoL1ch
» WarCraft 3 / 1 скилл пангольера в варкрафте
» WarCraft 3 / Новые нативные функции в 1.29
» WarCraft 3 / Опять утечка, может ли утекать переменная типа строка?
» WarCraft 3 / Ледяные стрелы на войсках ближнего боя
» WarCraft 3 / Скорость передвижения в мем хаке
» WarCraft 3 / Иногда не создаётся плавающий текст
» WarCraft 3 / обнуление локальныйх массивов
Ред. DracoL1ch
» WarCraft 3 / Надо ли очищать группу перед уничтожением
Списки юнитов остаются на месте, однако их заголовок ломается, якобы освобождая ячейку, ссылки на участников группы считаются стертыми. Получается, можно и не чистить список перед уничтожением. Просто в памяти адрес остается висеть, но может быть затерт, если заголовок гговорит, что тут никого нет (после дестроя именно так).
Вопрос не связан с самим существованием юнитов внутри группы после смерти, они вроде как не удаляются, я точно один раз лечил зависание мертвых иллюзий в списках.
» WarCraft 3 / обнуление локальныйх массивов
массивы - то же самое, что и обычные любые другие переменные. Увеличение кол-ва ссылок происходит при присвоении значения переменной. И неважно, массив там был или обычная.
» WarCraft 3 / Новый детект физического урона на мемхаке
» WarCraft 3 / обнуление локальныйх массивов
» WarCraft 3 / Надо ли очищать группу перед уничтожением
» WarCraft 3 / Надо ли очищать группу перед уничтожением
» WarCraft 3 / удаление событий
» WarCraft 3 / Локальный тригер
» WarCraft 3 / Memory Hack: GetUnitAttackSpeed( )