Добрый день.
Пытаюсь вот сделать одну способность и, для нее мне потребовалось узнать, сколько маны тратится на какую-либо способность.
То есть герой кастует спелл, а триггер должен узнать, сколько маны он потратил. Работать должно для любой способности.
Заранее благодарю)

Юнит приводит способность в действие
>> Взять количество текущей маны <<
>> Запустить таймер на 0.0, привязанный к игроку или герою <<
В другом триггере, где таймер истекает - отнимаем от переменной текущую ману и получаем потраченную.
Минус - если заклинание имеет время подготовки то фигня получится. Но можно запускать таймер не на 0 сек для конкретных заклинаний с временем подготовки.

Способ 2
Юнит начинает направлять способность
>> Взять количество текущей маны <<
Присвоить X[юнита] = нет
Ждать до условия "X[юнита] = да"
отнимаем от переменной текущую ману и получаем потраченную.
X[юнита] = да становится в другом триггере с событием "Юнит приводит способность в действие"
этот способ более практичен КАЗАЛОСЬ БЫ, но если юниту например выжгут ману, пока он подготавливает заклинание - то будет дезинфа. Да и нарегенить он успеет прилично, если время подготовки заклинания секунд 5 например.
`
ОЖИДАНИЕ РЕКЛАМЫ...
24
Юнит приводит способность в действие
>> Взять количество текущей маны <<
>> Запустить таймер на 0.0, привязанный к игроку или герою <<
В другом триггере, где таймер истекает - отнимаем от переменной текущую ману и получаем потраченную.
Минус - если заклинание имеет время подготовки то фигня получится. Но можно запускать таймер не на 0 сек для конкретных заклинаний с временем подготовки.

Способ 2
Юнит начинает направлять способность
>> Взять количество текущей маны <<
Присвоить X[юнита] = нет
Ждать до условия "X[юнита] = да"
отнимаем от переменной текущую ману и получаем потраченную.
X[юнита] = да становится в другом триггере с событием "Юнит приводит способность в действие"
этот способ более практичен КАЗАЛОСЬ БЫ, но если юниту например выжгут ману, пока он подготавливает заклинание - то будет дезинфа. Да и нарегенить он успеет прилично, если время подготовки заклинания секунд 5 например.
Принятый ответ
24
Melissa, и оба способа дают только приблизительный результат. Например, для героя с высокой скоростью регенерации погрешность будет тем выше, чем быстрее он регенерирует ману. А если еще и совпадет так, что на героя в этот момент наложили какой-то эффект восстановления моны, то "потраченная" мана и вовсе в отрицательные значения уйти может.
24
prog, нет. 1 способ даёт точный результат, проверено мной лично, я добавлял Soul Ring в свои CM WARS. Время подготовки оговорено
9
Melissa:
Юнит начинает направлять способность
>> Взять количество текущей маны <<
>> Запустить таймер на 0.0, привязанный к игроку или герою <<
В другом триггере, где таймер истекает - отнимаем от переменной текущую ману и получаем потраченную.
Минус - если заклинание имеет время подготовки то фигня получится. Но можно запускать таймер не на 0 сек для конкретных заклинаний с временем подготовки.

Способ 2
Юнит начинает направлять способность
>> Взять количество текущей маны <<
Присвоить X[юнита] = нет
Ждать до условия "X[юнита] = да"
отнимаем от переменной текущую ману и получаем потраченную.
X[юнита] = да становится в другом триггере с событием "Юнит приводит способность в действие"
этот способ более практичен КАЗАЛОСЬ БЫ, но если юниту например выжгут ману, пока он подготавливает заклинание - то будет дезинфа. Да и нарегенить он успеет прилично, если время подготовки заклинания секунд 5 например.
А можно описать первый способ более подробно "для тупых"?
24
Melissa, он дает точный результат с погрешностью на любые изменения, которые успеют произойти с героем за это время. Это не так просто воспроизвести т.к. нужен идеально точный тайминг, но я сам пользовался таким триггером в свое время и сильно страдал от того, что игроки приловчились читерить и получать отрицательные значения.
24
Короче вот, у меня же наработка есть, причём муишная, ахах.
Показывает затраченную ману любого юнита
Здесь много ненужного текста про Soul Ring
Так стоп.
Вот что значит не заглядывать давно в редактор.
Событие стоит не начинает направлять, а приводит в действие, у меня в карте.
А это значит что багов вообще не будет. Вот скрины короче.
Во второй триггер добавляются события "Таймер истёк"
Я ещё думал, пока первый пост писал - из-за события "начинает направляет" немало таки багов может вырисоваться в разных ситуациях, как так у меня до сих пор всё идеально было?
Делай как на скринах и будет тебе счастье
Хотя подожди тебе соул ринг необязательно, те же просто узнать сколько мп затратилось, ща переделаю...
prog, хз каким ты там пользовался, но попробуй-ка найти изъян в этом способе.
Загруженные файлы
24
Melissa, я бы поискал, но уже много лет как вар у меня на машине не стоит. Скажу только, что целенаправленно поймать момент когда активировался триггер и в него всадить изменение маны довольно сложно, а вот в долгосрочной перспективе это довольно неприятный баг, если на этой мехинике завязано что-то более заметное, чем сама шкала маны.
24
prog, ну вообщем мгновенные, временные и сделанные на основе канала спеллы - всё работает отлично
Вот те скрин с наработки для демонстрации. Замедление - 50 маны, божественный щит - 25, дух воды - 125
Melissa:
Минус - если заклинание имеет время подготовки то фигня получится. Но можно запускать таймер не на 0 сек для конкретных заклинаний с временем подготовки.
Забыл удалить. Минусов нет. Способ идеален. Ну почти.
Загруженные файлы
24
Melissa, поставь двух юнитов - одного постоянно кастовать какой-то спел с заранее известной стоимостью и другого - кастовать массовое восстановление маны. При хорошо подобраных интервалах рано или поздно восстановление влетит в момент срабатывания триггера и все поломает. А что касается естественной регенерации - тут я мог напутать, это очень давно было.
24
охспди, поверить не могу, что со мной ещё кто-то спорит :D
Вот пожалуйста, 3 паладина одновременный щит
Загруженные файлы
24
prog, ты не одновременный каст имел в виду? Я не представляю тогда, что там по твоему может запороть вычисление
А, погоди
24
Melissa, я описал какой у мебя был испытательный стенд, когда я с подобной системой баг ловил.
стоит два юнита
первый кастует по кулдауну какое-то заклинание (любое, главное чтобы ману тратило)
второй кастует массовое восстановление маны, тоже постоянно, так чтобы накрывало первого
считается только стоимость заклинаний первого юнита - второй чисто вспомогательный
все это запускается на пару часов, каждый отличающийся от номинального результат работы системы записывается и счетчик выводится по команде чтобы можно было узнать результат перед тем как закрывать карту
можно увеличить количество подопытных и повесить их на разные таймеры, тогда количество ошибок в час получается больше
у меня получалось от пары штук до нескольких десятков ошибок в час при различных параметрах способностей и на алгоритме разной степени доработанности.
24
Так ну я поставил все параметры каста на 0.00 и триггерно приказал одновременно юзнуть щит и восстановление маны.
В этом случае действительно будет огрех, но честно говоря я не думаю, что точнее сделать можно. Да и вероятность что так идеально всё совпадёт - крайне мала. В реальной игре у юнитов разные скорости каста и подсчитать 1.67 у какой-нибудь джайны под 0.5 какой-нить статуи - если твои игроки и правда навострились такое проворачивать, то просто забей, им не в карты варика играть надо

prog, жажажа. Я уже ответил)
Бтв, если ты ставил синхронный каст в РО своим героям - то просто сделай его различным, хотя бы на 0.01 сек. Всё-таки нажать одновременно кнопку не так сложно, а вот подсчитать разницу и нажать своевременно - почти нечеловечески. Только триггерно.
(анимация точки обратного хода, анимация точка броска - эти параметры не должны быть одинаковыми у разных героев, если ты решил бороться с одновременным нажатием)
24
Melissa, ну я не зря двухчасовые тесты гонял вместо того чтобы просто время каста в 0 выдать - это была симуляция "случайного" совпадения.
24
prog, Ну и зачем? Подумаешь совпадёт 1-2 раза за 30-минутную катку, МОЖЕТ БЫТЬ.

Если люди играют в карты чтобы там форсить выявление каких-то недоделок, то у меня для них печальные новости.
Обычный игрок игнорит даже довольно частые баги, если только они не крашат геймплей, не то что там с точностью до 0.00 всё выявляет.

И да, тем не менее - самой функции взятия потраченной маны нет, разве что с магической вспышкой лесных дракончиков похимичить. Так что точнее чем такой вот таймер на 0.00 сек ты пожалуй не сделаешь
24
У меня на этом была очень важная игровая механика завязана, так что даже одного случайного совпадения было достаточно чтобы ход игры поменять, но я сперва тоже подумал что фиг с ним, пусть будет секретной фишкой. Вот только когда игроки навострились это абузить с успешностью срабатывания раз в пять-шесть попыток, начался кромешный ад и мне пришлось вмешаться.
24
prog, ну что я тут могу ответить, это печально
Кстати, что за карта-то?
24
Нашли это совершенно случайно, но когда нашли - начали активно абузить т.к. это был верный путь к легкой победе.
Melissa:
Кстати, что за карта-то?
Да не важно, небольшая карта для личного пользования в узком кругу.
24
Попробуй химию с дракончиками, они же наносят урон по количеству потраченной маны. наверняка конкретно для твоей карты это можно использовать чтобы покончить с читаками.
prog:
Да не важно
Ну хоть суть скажи), вдруг кто из читающих тему тоже подобное делает
24
И да, тем не менее - самой функции взятия потраченной маны нет, разве что с магической вспышкой лесных дракончиков похимичить. Так что точнее чем такой вот таймер на 0.00 сек ты пожалуй не сделаешь
Есть надежный способ - взять что-то вроде моей утилиты FlaDataProcessor (не завершена и требует хорошего понимания происходящего чтобы использовать) и запилить автоматическое заполнение базы данных в коде на основе данных РО. А дальше дело техники - по айди заклинания и его уровню достать из базы стоимость по мане.
24
А ну то есть обрабатывать каждый объект "вручную" (БД или ловля). Что ж, это тоже патриотизм вариант.
24
Попробуй химию с дракончиками, они же наносят урон по количеству потраченной маны. наверняка конкретно для твоей карты это можно использовать чтобы покончить с читаками.
В своей карте я покончил с ними описанным выше способом.
Суть карты была в батле магов, проходящем по специфическим правилам, а именно - есть фиксированный запас маны, от которого отнимается стоимость каждого использованного игроком заклинания, при этом мана героя не привязана к этому запасу. Запас общий на несколько раундов. Кто потратит всю ману из запаса - проигрывает. Восстановление маны героя не повышает скрытый запас маны, а только позволяет использовать больше заклинаний за еденицу времени. Естественно, если умудриться получить отрицательную стоимость заклинания, то можно восстановить максимум, а если делать это на дешевых заклинаниях, то выигрыш получался больше, чем было затрачено на неудачные попытки.

А ну то есть обрабатывать каждый объект "вручную". Что ж, это тоже патриотизм вариант.
почему вручную то? FlyDataProcessor в момент сохранения карты дописывает в код карты нужные данные. Сам. Автоматически. Без участия пользователя. Нужно только один раз написать шаблон для заполнения базы, очень обобщенный шаблон, без указания конкретных id вручную.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.