Перехватывать smart на могилу, выдавать канал и приказывать кастовать его. При сбивании каста забирать канал у героя. Прогресс отображать через хп могилы, которое таймером повышается пропорционально кол-ву активных кастов канала.
PT153, в этом нет большого смысла на уровне компилятора, ведь это можно реализовать силами самого Lua
Например у меня есть такой файл, main.lua
function InjectMain()
local alpha_main = main
return function()
local alpha_init = RunInitializationTriggers
RunInitializationTriggers = function() end
alpha_main()
InitLibraries()
alpha_init()
end
end
main = InjectMain()
Работает за счет того, что в отличии от WE, мой компилятор добавляет код из файлов после кода сгенерированого WE.
Единственный недостаток - если нужно полностью заменить main или config, а не дополнить их, то старый код этих функций останется в коде карты мертвым грузом.
Таким образом можно сделать привязку к другим камням. А потом можно умереть вместо телепортации))
Герой покупает специальный предмет (или юнита) в точке воскрешения. В момент покупки купленый предмет удаляется, а герой привязывается к точке где купил предмет - никакого способа привязаться к точке не находясь в радиусе действия её магазина.
Чтобы разбавить критику конструктивом - расскажу свой способ воскрешения.
Это вариация воскрешения у камней, но с нюансами. Главное отличие - триггер привязки камня реализован через покупку предмета в магазине, а не через вход в радиус. Это позволяет ходить возле "камня" не боясь случайно перепривязаться в неудобном месте и заодно позволяет добавить стоимость к процессу привязки камня. А в моем случае я использую еще и перезарядку продажи, чтобы несколько игроков не могли без задержки привязаться к одному камню.
NazarPunk, я понимаю где еще это используется, но между экономией лишних десяти строк кода или экономией долей миллисекунды выполнения кода я выберу второе ;)
Ну и да, воскрешение у ближайшего камня не всегда хорошая идея - если, например, ближайший камень находится в каком-то секретном или временно непроходимом месте и у игрока еще нет активного камня, то результат будет плачевным - я скорее принудительно выдавал бы игроку какой-то камень на старте и не парился обработкой кейса "камня нет", а в таком случае и поиск ближайшего камня в коде не появляется и можно смело "экономить на спичках" т.к. нет реюза функции поиска ближайшего камня ;)
Использовать поиск ближайшего камня в триггере входа в радиус это немного оверкил - я бы скорее хранил координаты всех камней в списке и перебирал его простой проверкой на нахождение точки в прямоугольнике - мы ведь гарантированно находимся на определенном расстоянии от камня в момент когда происходит эта проверка и нам нет необходимости реально искать ближайший камень, достаточно определить возле какого мы находимся - минус лишняя математика вычисления расстояния и минус лишние итерации в цикле если наш камень не последний в массиве.
Пошел проверил. В Lua режиме строка print(_ENV["GetUnitGoldCost"](GetUnitTypeId(u))) исправно вывела мне стоимость юнита. Стучу через _ENV потому как лень распарсить ai нативки.
Судя по скринам - этот диалог больше нигде не используется, только в этой системе перемещения - какой смысл пересоздавать каждый раз все кнопки, если их можно создать один раз?
Я про syntax check в самом VSCode. Я сказал "ПЕРЕД" для того, чтобы в алгоритме по удалению пробелов можно было засечь ошибку, да и всяко лучше запускать чекер после всех препроцессорных махинаций.
У меня немного другая идеология, которая заключается в том, что валидный код до препроцессора всегда должен выдавать валидный код после препроцессора и наоборот, не валидный код до препроцессора может выдать только не валидный код после препроцессора. Это немного сужает допустимый функционал препроцессора, но избавляет от огромного количества головной боли и хорошо интегрируется с существующими инструментами для работы с Lua.
PT153, напоминаю, что этот компилятор рассчитан на работу с кодом в VSCode, а WE остается только GUI и все что с кодом не связано. Поэтому, например, не имеет смысла что-то чудить с пробелами перед синтакс чеком т.к. синтакс чек из WE просто не будет вызываться в 99% случаев.
Что касается синтаксиса макросов - я не случайно пошел путем аннотаций к переменным вместо кода в комментах - в моем варианте с этим более-менее прилично работает обычный синтакс-чекер для Lua и мне не нужно писать кастомный.
За счет этого, например, наведя мышку на константу я могу увидеть её значение.
А в результирующем коде от скрина выше останется только print("CONST_VAL")
Аналогично с макросом RAW - он принимает только значения в одинарных кавычках и имена констант чтобы проходить стандартный синтакс-чек. Более того, используется еще и объявление глобальной переменной RAW=FourCC, чтобы если что-то пошло не так с макросом, был шанс на срабатывание стандартного конвертера, ну и строгий синтакс-чек без этого не пройти.
alexprey, пока в коде плагина слишком много остатков от стороннего плагина warcraft-vscode чтобы лить в маркетплейс, поэтому первая бета будет все-же на ручной установке, когда до этого дойдет дело, а потом таки сяду причешу код и начну разбираться с маркетплейсом.
Автокомплит по API вара - через сторонний плагин sumneko-lua, это и ланг сервер и эмми-луа аннотации и другие полезные фичи. Для него в комплекте будут идти конфиги и дефинишны API, чтобы достаточно было поставить и можно было пользоваться, но сам sumneko-lua используется оригинальный.
Автокомплит по API компилятора - мне очень хотелось бы, но я понятия не имею как он будет работать параллельно с ланг-сервером, да и не факт что я найду время его запилить - все-же запил плагинов к вскоду это немного далековато от моего базового набора скилов.
Автокомплит по равкодам - интересная мысль, можно попробовать, но те-же проблемы, что и в предыдущем пункте.
честно сворованный из warcraft-vscode упаковщик карты
запиленый на основе warcraft-vscode плагин к VSCode, вызывающий компилятор и упаковщик, а также запускающий игру и редактор
План на ближайшее будущее - предварительный релиз с ручной установкой и подготовка к релизу полноценному, через маркетплейс плагинов к вскоду.
В связи с тем что редактор показал возможность подхватывать abilitydata.slk из карты-папки, в список запланированных на ближайшее время фич добавляется игнор-лист для упаковщика карты, чтобы можно было указать ему "это файлы только для редактора, не надо совать их в запакованую карту". А в запланированные на будущее фичи - инжект плагином пофикшеного abilitydata.slk в карту для отображения скрытых способностей.
8gabriel8, разве? давно последний раз кого-то на паузу ставил, почему-то мне казалось что и получение урона блокируется, видимо с москитами спутал или еще с чем xD
Я больше по фрилансу, так что офисных историй меня нет особо, а вот на фрилансе бывали безумные ситуации после которых я переставал брать заказы у постоянных клиентов.
Одна из историй привела не только к отказу работать с заказчиком, но и стала последней каплей после которой я практически перестал брать заказы в своем регионе. Как то раз уезжая на отдых один из моих постоянных клиентов в городе повесил на меня собаку. Буквально - его задавила жаба платить за питомник, а у меня какраз была черная полоса в финансах и отказаться от заказа только из-за дополнительной собаки было проблематично.
Поскольку не достаточно подробно прописаны условия вопроса - дам альтернативный ответ - поставить всех на паузу. Добыча и строительство гарантированно будут заблокированы. Правда будет заблокировано и все остальное - передвижение, нанесение и получение урона и так далее.
function GlobalTimerCallbackOverUnit(unit)
local u = unit -- переменная привязаная к каллбеку
return function() print(u) end -- код каллбека
end
...
local unit = GetSomeUnit()
TimerStart(...,GlobalTimerCallbackOverUnit(unit))
Троеточиями заменены не важные участки кода, которые были опущены для наглядности.
Код не проверен на реальной луа машине, но вроде должно работать, если я все правильно помню.
Преимущество над анонимными функциями в чистом виде - контролируемый кложур, содержащий только нужные нам данные. Минус - более медленный старт за счет дополнительного вызова функции создающей каллбек.
Можно и дополнительной проверкой маны, конечно, но через способность-пустышку надежнее - исключает возможность того что мана два раза попадет в этот интервал или перескочит его полностью за одну итерацию таймера.
» WarCraft 3 / [lua] Воскрешаем героя
Ред. prog
» Эксперименты в Пустоте / Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
Например у меня есть такой файл, main.lua
Единственный недостаток - если нужно полностью заменить main или config, а не дополнить их, то старый код этих функций останется в коде карты мертвым грузом.
» WarCraft 3 / [lua] Воскрешаем героя
» WarCraft 3 / [lua] Воскрешаем героя
Ред. prog
» WarCraft 3 / [lua] Воскрешаем героя
Это вариация воскрешения у камней, но с нюансами. Главное отличие - триггер привязки камня реализован через покупку предмета в магазине, а не через вход в радиус. Это позволяет ходить возле "камня" не боясь случайно перепривязаться в неудобном месте и заодно позволяет добавить стоимость к процессу привязки камня. А в моем случае я использую еще и перезарядку продажи, чтобы несколько игроков не могли без задержки привязаться к одному камню.
» WarCraft 3 / [lua] Воскрешаем героя
Ну и да, воскрешение у ближайшего камня не всегда хорошая идея - если, например, ближайший камень находится в каком-то секретном или временно непроходимом месте и у игрока еще нет активного камня, то результат будет плачевным - я скорее принудительно выдавал бы игроку какой-то камень на старте и не парился обработкой кейса "камня нет", а в таком случае и поиск ближайшего камня в коде не появляется и можно смело "экономить на спичках" т.к. нет реюза функции поиска ближайшего камня ;)
Ред. prog
» WarCraft 3 / [lua] Воскрешаем героя
» WarCraft 3 / Применение способности триггером
» WarCraft 3 / Продажа юнитов
Ред. prog
» WarCraft 3 / [lua] Подсветка кода во внешнем редакторе
SuicidePlayer
SuicidePlayerUnits
CaptainInCombat
GetUnitCountEx
TownCountEx
BasicExpansion
StartUnit
SingleMeleeAttack
code - нигде не обьявлен
null в 12288 строке
integer - дублирование класса
code - нигде не обьявлен
» WarCraft 3 / Продажа юнитов
Ред. prog
» WarCraft 3 / Продажа юнитов
» WarCraft 3 / Диалоговые кнопки
» WarCraft 3 / Диалоговые кнопки
» Эксперименты в Пустоте / Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
Ред. prog
» Эксперименты в Пустоте / Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
» Эксперименты в Пустоте / Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
Ред. prog
» Эксперименты в Пустоте / Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
Автокомплит по API компилятора - мне очень хотелось бы, но я понятия не имею как он будет работать параллельно с ланг-сервером, да и не факт что я найду время его запилить - все-же запил плагинов к вскоду это немного далековато от моего базового набора скилов.
Автокомплит по равкодам - интересная мысль, можно попробовать, но те-же проблемы, что и в предыдущем пункте.
» Эксперименты в Пустоте / Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
» WarCraft 3 / Как временно заблокировать добычу золото, дерево и строительство
» Лучший блог / Существенная причина для ухода с работы
» WarCraft 3 / Как временно заблокировать добычу золото, дерево и строительство
» WarCraft 3 / [lua] Все споcобы перебрать группу юнитов
Код не проверен на реальной луа машине, но вроде должно работать, если я все правильно помню.
Преимущество над анонимными функциями в чистом виде - контролируемый кложур, содержащий только нужные нам данные. Минус - более медленный старт за счет дополнительного вызова функции создающей каллбек.
» WarCraft 3 / Вопрос по карте!
» WarCraft 3 / Условие в цикле на ГУИ и возможно ли это?