Дмитрий Тюрев:
     ЖЖ вроде не вполне подходящее место для таких вопросов. лушче, имхо, здесь
     Таки есть ли у триггера свои переменные и время жизни?
Тимур:
     может быть, зависит от триггера
     фактически триггер - это просто игровой объект, который сериализован в xml и в xml редактируется редакторами
Дмитрий Тюрев:
     у триггера бывают и время жизни и свои переменные?
     или что-то одно?
Тимур:
     может быть как угодно, это как автор триггера напишет так и будет
     ну грубо говоря есть вот видимый игровой объект - это моб
Дмитрий Тюрев:
     хм. а в редакторе war3 тоже такие триггеры есть?
Тимур:
     моб в редакторе - это некий кусок данных на карте
Дмитрий Тюрев:
     или там триггер только функция?
Тимур:
     а триггер - тоже объект, только отвечает за логику, невидимый
     да, есть
Дмитрий Тюрев:
     если триггеры могут иметь время жизни и локальные перменные,
     значит сразу появляется проблема хранения ссылок/хендлов и прочего менеджмента ресурсов
     верно?
Тимур:
     ну да, это как обычно, но большинство триггеров все таки stateless
     то есть оно теоретически есть конечно, но на практике как то нет таких проблем
Дмитрий Тюрев:
     Вот, если на примере... Скажем, надо создать юнит, а через 5 минут, если юнит ещё жив, направить его на базу.
     При помощи триггера мы создали юнит, но как потом найти его через 5 минут? По идее, для этого надо где-то запомнить хендл юнита.
     Или как?
Тимур:
     да, либо повесить триггер на самого юнита
Дмитрий Тюрев:
     это как?
Тимур:
     триггер такого типа получит во входную функцию ссылку на хозяина
Дмитрий Тюрев:
     и сам активизируется по таймеру через 5 минут?
Тимур:
     ну приаттачить триггер к юниту, это как невидимый буфф
     да, с активацией через пять минут
Дмитрий Тюрев:
     а если запомнить хендл, то куда? в свою локальную память?
Тимур:
     да, в локальную переменную триггера, потом при активации понятно надо будет проверить хендл на валидность
Дмитрий Тюрев:
     а как организовать в триггере ожидание 5 минут?
     у него ведь один набор экшенов, вроде
Тимур:
     это все зависит от триггера
     смотри, штука которая цепляется на существо у нас - это buff
     buff состоит из effects - это элементарные объектики, которые цепляются к существу и влияют на него
     например effect может дать +10 к силе
     effect также может подписаться на таймер и дернуть вложенный в него impact
     а impact - это базовый интерфейс воздействия
     он может сделать все что угодно, это уже фактически активный скрипт, который получает в качестве входного параметра существо хозяина (ему его дал effect) и что-то сделать
     вообще вся техника - это большая сборка из микрообъектов, аггрегация
Дмитрий Тюрев:
     как всё сложно. :) столько сущностей и их взаимодействий
     имхо, по сложности, как полноценное программирование :)
     и ваши дизайнеры всё это делают сами?
Тимур:
     я могу любой игровой пример так расписать, причем это может быть не только триггер, но и целая миниигра
     ну да, и в общем особых проблем нет, вполне себе кодят на этом
Дмитрий Тюрев:
     а если нужен менеджер, который управляет группой объектов.
     как это на триггеры положить?
Тимур:
     не очень понял, нужен пример
Дмитрий Тюрев:
     Пример. Надо создать караван верблюдов и отправить их через пустыню. Если хотя бы на одного верблюда напали, они должны пуститься врассыпную. В ООП реализуем это просто – создаём класс ЦКараван, который создаёт и следит за своими верблюдами. Если хотим, можем запустить 10 караванов. А в триггерах как всё это сделать?
     На триггере понятно, как индивидуальную логику сделать
     А коллективную не понятно
Тимур:
     ну во первых можно просто сделать, что если на верюлюда нападают, он кидает area effect event "караул!", и на всех верблюдах триггер на этот эффект, которые заставляют их разбегаться
     а так можно сделать такой же триггер CCaravan, который управляет всеми верблюдами
     точнее даже не CCaravan, а триггер, который на входе запоминает группу объектов, а потом применяет какие-то воздействия к группе
Дмитрий Тюрев:
     не пойму, как одним триггером можно это сделать
     вроде в war3 триггеры выглядят так:
     События
     Условия
     Действия
     то есть, одна группа действий, которые могут активироваться
     а для управления группой верблюдов нам надо в разные моменты времени в разных ситуациях выполнять разные действия.
     то есть, надо в событиях перечислить все варианты активации:
     - Создание каравана
     - Тик раз в секунду
     - Атака на верблюда
     Затем в экшенах написать кучу условий, чтобы разделить эти случаи:
     - Если триггер активирован по созданию каравана, то
     инициализировать караван
     - Если триггер активирован по тику, то
     сделать что-то
     - Если триггер активирован по атаке верблюда, то
     обратить всех своих верблюдов в бегство
     Получается, как если несколько методов смешались в один.
     Можно сделать для каждого из этих случаев отдельный триггер,
     но тогда придётся как-то обмениваться данными между ними (хендлами верблюдов, например)
     и то, и другое звучит пугающе :) как это сделать нормально?
Тимур:
     ну тикать раз в секунду тут вроде не надо, создание каравана - на это триггер тоже не реагирует, а только сам создается
     соответственно - есть штука, которая этот караван где-то рождает, в нее добавляем триггер, который запоминает хэндлы верблюдов
Дмитрий Тюрев:
     почему на создание не реагирует. ему ведь надо создать верблюдов
Тимур:
     потому что пока каравана нет - триггера еще тоже нет, он создается вместе с ним
Дмитрий Тюрев:
     я предполагал, что триггер сам и создаст верблюдов
     и запомнит хендлы
Тимур:
     не, это разные вещи, он только их пугает
Дмитрий Тюрев:
     можно создать веблюдов где-нибудь извне
     но всё равно надо передать в триггер хендлы
Тимур:
     ну да, вот штука которая создает верблюдов, она триггер и создаст
     и скормит ему верблюдов
     а создать их может какой-нибудь impact, который активируется по квесту
Дмитрий Тюрев:
     предположим у каравана есть несколько фрагментов логики:
     - менять курс при достижении очередной опорной точки пути
     - пугать при нападении
     - проверять достижение конца пути
     В идеале всем этим должен управлять один триггер или несколько (по одному на каждый пункт)?
Тимур:
     несколько
     у нас такие вещи сделаны через контрольные точки в патруле
Дмитрий Тюрев:
     ок. значит какой-то импакт должен при создании каравана активировать три упомянутых выше триггера
     и всем троим скормить список хендлов подотчётных верблюдов. так?
Тимур:
     есть такая штука - патруль - это маршрут с контрольными точками
     по маршруту можно отправить моба
     и в каждой кнотрольной точке указать, какие воздействия применять к этому мобу, когда он туда придет
     ну триггер который пугает, да
     а другие триггеры у нас скорее всего бы встроили в контрольные точки
Дмитрий Тюрев:
     хорошо, но давай пока без патруля :)
     то, что я написал выше - это верно?
Тимур:
     ну да, в принципе, если групповое поведение необязательно, то можно повесить и триггеры на каждого верблюда в отдельности
     ну типа при прибытии в точку A плюнуть
     тогда они будут независимо друг от друга плеваться :)
Дмитрий Тюрев:
     групповое поведение обязательно. иначе всё было бы просто :)
Тимур:
     ну да, тогда триггер на группу, который заставляет плюнуть все подконтрольных верблюдов, если надо, например, чтобы они строго одновременно плюнули
Дмитрий Тюрев:
     в общем, надо создать три триггера и запихнуть в них хендлы
     при достижении конца пути надо эти три хендла грохнуть
     кто это сделает? и откуда он возьмёт хендлы триггеров?
     ~эти три триггера
Тимур:
     да по разному,
     например владелец триггера - караван, тогда они умрут вместе с караваном
     или триггер может сам себя по событию удалить
Дмитрий Тюрев:
     караван в данном случае - это тоже троггер или что?
Тимур:
     караван - да
Дмитрий Тюрев:
     получается, что логика каравана разнесена по нескольким триггерам (текст, которых видимо хранится независимо в общей базе триггеров)
     но не лучше ли всю логику каравана хранить в классе каравана? :) оно ведь компактно. если нужно поменять поведение каравана, сразу
     знаешь куда надо смотреть. чтобы понять ВСЮ логику каравана достаточно просмотреть его класс.
     в случае с триггерами где их искать? и как понять все ли ты триггеры просмотрел или пропустил что-то важное?
Тимур:
     ну это как, можно закодить один мегакласс, который все умеет, а можно разбить его функционал на несколько классов поменьше
Дмитрий Тюрев:
     угу. но один мега триггер закодить куда сложнее, чем мегакласс :)
Тимур:
     тут тоже самое, никто не мешает закодить один литой мегатриггер, который целиком караваном управляет, но лучше, все таки, разбить
     не, это тоже самое, потому что это мы сейчас говорим, мол триггер
     а на самом деле у нас это просто игровые объекты, которые сериализованы и параметризованы в xml
     просто у тебя будет класс Caravan с кучей параметров и уникальный код для этого класса
     либо объект будет декомпозирован на объекты классов поменьше, это все выбор программиста
     я обычно стараюсь выбирать решения со вторым вариантом, а за первый, если увижу, ругаю
Дмитрий Тюрев:
     а как всё-таки найти все триггеры, касающиеся, каравана?
Тимур:
     так они же все находятся в одном файле, который за караван отвечает
     этот файл - это xml представление большого объекта, который собран из кучи мелких деталей, мелких всяких триггеров, предикатов воздействий и так далее
     грубо говоря, все дежит между тэгами
Дмитрий Тюрев:
     имхо, в целом, сложность кодирования логики в варианте с триггерами ничуть не меньше, чем в случае ОО дизайна :)
     то есть, число точек принятия решений будет и там, и там одно и то же. то есть, разница лишь в формате записи.
     не? :)
Тимур:
     не, она очень часто упрощает, как в примере с минами
     ну или те же контрольные точки в маршруте верблюдов
     дизайнер прямо в редакторе рисует линию, а затем в нужные точки засовывает что там надо устроить
Дмитрий Тюрев:
     а что именно упрощается с минами? чтобы использовать триггер мины, надо его закодить (то же самое, что создать класс мины)
Тимур:
     ну ты один раз кодишь триггер, который на вход в некую область умеет дергать impact
     а потом получаешь миллион вариаций из этого кода
     мина, огненная стена которая жжет если зайти, болото которое пачкает и уменьшает скорость ну и в приницпе все что угодно, что надо навесить на вход в область
     просто мина - это же частный случай комбинации area trigger + impact
Дмитрий Тюрев:
     скажи, пожалуйста, а как всё это дебажить? :)
     в отладчике ведь по шагам не пройдёшь
Тимур:
     если честно, то я ни разу сам не дебажил :)
     но дизайнеры как-то делают же свою работу ;)
     а так, я бы конечно, если понадобилось, наверное какие-то логи стал прикручивать, которые протоколируют исполнение всей этой ботвы
     у программистов есть обычный отладчик, в конце концов ведь вся эта система реализована на java, и в любой элемент триггеров можно поставить breakpoint ну и как обычно
     ну да, я так и отлаживал
Дмитрий Тюрев:
     а триггер, когда создаётся, он имеет хендл? можно ли обратиться к конкретному экземпляру триггера?
Тимур:
     depends on, может и не иметь
Дмитрий Тюрев:
     угу. но возможность такая есть, да? запомнить хендл триггера
Тимур:
     если понадобится, можно сделать, но большинство не имеют
     просто у нас у них нет ни общего базового класса, ни даже интерфейса, это просто невидимые игровые объекты, управляющие логикой, самых разных типов
     как его закодят, таким он и будет