8gabriel8, а не известно заносятся ли они в группу, но есть строгий критерий - нам не интересны крестьянки без бафа и баф выдается только при срабатывании способности - почему бы не заносить их в группу и не избавиться тем самым от кучи лишних действий?
8gabriel8, зачем такой малый период, если принципиальной разницы между проверкой 1 раз в секунду и 10 раз в секунду не будет, а лишняя нагрузка в наличии. Зачем поиск с созданием группы, если мы и так знаем всех юнитов подлежащих проверке и можем хранить их в одной группе без поиска?
Прежде всего, такой баф лучше выдавать через ауру замедления от торнадо, настроенную работать только на себя и с нулевым замедлением. Это позволит избежать ситуаций когда баф может закончиться раньше времени, а также защищает от диспела и похищения бафов.
Что касается детекта полной маны, есть несколько способов, в этой ситуации я бы предложил следующий:
При наложении бафа добавляем юнита в группу.
Периодическим таймером с периодом в одну секунду перебираем всех юнитов в группе и проверяем не полная ли мана.
Если мана полная, то удаляем из группы, забираем баф, обнуляем ману, спавним юнита.
А если бы я это делал сам, то реализация была бы другой - мана использовалась бы исключительно для отображения прогресса и выставлялась бы таймером на основе скрытого счетчика, не зависящего от скорости регенерации маны и любых других способов её ускоренного восстановления. Или, например, воспользовался бы возможностью выдать ограничение времени жизни и в момент "смерти" юнита спавнил бы нового и воскрешал или пересоздавал старого. Но оба эти способа более сложные и требуют дополнительных знаний для правильной реализации.
Так я её и получил, а ты предлагаешь ещё пилить функцию, которая по твоим словам дорогое удовольствие
Итератор позволяет инкапсулировать и повторно использовать общий код для итерации. Кроме мест в которых производительность критически важна, этот лишний вызов функции вполне окупается удобством использования.
Более того, в случае перебора списка юнитов, если так важна производительность перебора - эффективнее будет хранить их в таблице и не дергать нативки вобще. Но, естественно, при однократном переборе результата поиска юнитов нативкой других вариантов кроме перебора группы особо и нет.
NazarPunk, ты сказал что хочешь локальную переменную в цикле - я сказал как её получить. А метод с BlzGroupUnitAt потестить, конечно, тоже стоит. Более того, его тоже можно завернуть в итератор при желании.
NazarPunk, Ну так запили свой итератор и делай это через for... Использование будет выглядеть примерно так:
for target in group_iter(GROUP) do
--actions
end
Где group_iter кастомный итератор принимающий группу и делающий перебор внутри, а переменная target автоматически объявляется как локальная для цикла, если я правильно помню.
Это, естественно, обойдется в лишний вызов функции на каждой итерации, так что в критических для производительности местах придется жертвовать красивостью кода ради скорости.
quq_CCCP, у абилок со снарядом есть большая проблема - они не очень любят когда цель каста перемещается триггерно пока снаряд летит.
Ну и, как уже было сказано выше, любое нестандартное поведение снаряда крайне неудобно делать на дефолте - скилшоты, мультиснаряды, нестандартные типы движения, взаимодействие с рельефом, обработка столкновений между снарядами и так далее.
Перечитайте еще раз как работают таблицы. Lua не умеет в ясновидение и самостоятельно не может догадаться что строка Player0 и номер игрока это одно и то же.
Можно инициализировать Heroes так - Heroes = {nil,nil,nil,nil,nil,nil,nil,nil} и потом обращаться по индексу DATA.Heroes[ID], но тогда и запись в эту таблицу и получение данных из неё будет только по индексу. А для обращения вида DATA.Heroes.Player0 нужно чтобы данные попадали как-то в эту таблицу по строковому ключу, например так DATA.Heroes["Player"..ID], но это крайне медленный способ и лучше все-же обходиться индексами.
PYCCKUI_DedOk, а смысл даже если карту видно, новые функции из более новых патчей никаким магическим образом в варе 1.26 не заработают, даже если карту сохранить в новом редакторе. Ну а JNGP пока превосходит по функционалу любые версии чистого редактора.
редактор все еще дрочит мне мозг тем что якобы уже открыт.
Комп перезагружал? Возможно процесс редактора подвис где-то на стадии открытия или после закрытия. Можно и вручную поискать подвисший процесс, но перезагрузка надежней.
С переходом на луа есть нюансы. Да, можно достаточно легко конвертировать cjass в jass а jass в Lua. Но беда в том, что значительная часть старого кода станет ненужными костылями в новых реалиях и его, соответственно, всеравно придется переписывать заново в более правильном виде.
Красота. Еще бы возможность скрыть и показать фрейм командой и константу для изменения стартового состояния фрейма - чтобы не надо было код убирать когда фрейм не нужен.
ScopteRectuS, в зависимости от кол-ва обращений, конечно. onInit в локалку я завернул больше за компанию, а вот в случае с глобальной таблицей AbilityIndex - да, смысл есть.
ScopteRectuS, Не норм, конечно, потому что лишний цикл.
способность
AbilityIndex = {} -- Переменная для хранения способностей по равкоду
Ability = {} -- Переменная для хранения способностей по имени
do
Ability.DeathCoil = { }
AbilityIndex[FourCC( "A00I" )] = AbilityIndex.DeathCoil
function Ability.DeathCoil.onSpellCast( )
end
function Ability.DeathCoil.onSpellEffect( )
end
function Ability.DeathCoil.onInit( )
-- preload...
end
end
вызов функций
function InitAllAbilities( )
for key, value in pairs( Ability ) do
if type( value ) == "table" then
-- Если у способности нужно что-то инициализировать (прелоад, создание объектов),
-- то нужно в таблице способности создать функцию "onInit".
local onInit = value.onInit
if onInit and type( onInit ) == "function" then onInit( ) end
end
end
local trigger = CreateTrigger( )
TriggerRegisterAnyUnitEventBJ( trigger, EVENT_PLAYER_UNIT_SPELL_EFFECT )
TriggerAddAction( trigger,
function( )
local abilityId = GetSpellAbilityId( )
local spelldata = AbilityIndex[abilityId]
if spelldata and type( spelldata ) == "table" then
local onSpellEffect = spelldata.onSpellEffect
if onSpellEffect and type( onSpellEffect ) == "function" then onSpellEffect ( ) end
end
end
)
end
» WarCraft 3 / Размножение
» WarCraft 3 / Размножение
Ред. prog
» WarCraft 3 / Размножение
» Гильдия «Черамор» / Чародейка Иона
» WarCraft 3 / [lua] Двигаем снаряды
Ред. prog
» WarCraft 3 / [lua] Двигаем снаряды
Более того, в случае перебора списка юнитов, если так важна производительность перебора - эффективнее будет хранить их в таблице и не дергать нативки вобще. Но, естественно, при однократном переборе результата поиска юнитов нативкой других вариантов кроме перебора группы особо и нет.
Ред. prog
» WarCraft 3 / [lua] Двигаем снаряды
Ред. prog
» WarCraft 3 / [lua] Двигаем снаряды
Это, естественно, обойдется в лишний вызов функции на каждой итерации, так что в критических для производительности местах придется жертвовать красивостью кода ради скорости.
» WarCraft 3 / Переименование расы
» WarCraft 3 / [lua] Двигаем снаряды
Ну и, как уже было сказано выше, любое нестандартное поведение снаряда крайне неудобно делать на дефолте - скилшоты, мультиснаряды, нестандартные типы движения, взаимодействие с рельефом, обработка столкновений между снарядами и так далее.
» WarCraft 3 / [Lua] В таблицу не заносятся герои.
Ред. prog
» WarCraft 3 / [Lua] В таблицу не заносятся герои.
» WarCraft 3 / Редактор не подаёт признаков жизни
» WarCraft 3 / Актуальность cJass
» WarCraft 3 / Актуальность cJass
» WarCraft 3 / Вылетает редактор когда дотрагиваюсь до ландшафта.
» WarCraft 3 / Актуальность cJass
» WarCraft 3 / Вылетает редактор когда дотрагиваюсь до ландшафта.
» Администрация XGM / Ссылки на группы XGM
» WarCraft 3 / [lua] Garbage
» WarCraft 3 / [lua] Garbage
» WarCraft 3 / Lua: функции в таблице
» WarCraft 3 / Lua: функции в таблице
» WarCraft 3 / Lua: функции в таблице
» WarCraft 3 / [lua] Двигаем снаряды