//
(с точки зрения кодера) Создание сервер-програмы (или нескольких версий)
==========================================
Планируется, что сервер-програма будет постояно пере-компилироваться
и, в некие анонсированые передышки для профилактики, на сайт будет закачиваться
новая версия сервера, которая совместима со старыми ресурсами и сама выдаст
какие-то новые ресурсы на сторону клиента, если новые материалы были добавлены.
// ---
Предпологается, что клас "Игровое поле клеток" будет фундаментом.
Мир игры состоит из больших квадратов местности. Каждый квадрат может включать
в себя несколько экзэмпляров класа "Игровое поле клеток". Тоесть некоторые локации
будут много-этажными.
Можно использовать любое смещение для этажей - тоесть при большом жэлании можно
делать "свободные локации" с любым размером, где "этажи" могут быть соседями сбоку.
Например, так можно изголяться в категории локаций Пати-спец и Соло-спец.
// ---
Про систему тригеров..
// названия свойств кое-какие.
1. Есть инэр-тригеры для зданий в стратегических локациях - тригер как деталь здания.
У этой версии своя мини-реализация.
Важны свойства.. pParent(юнит-здание), waitFull, waitNow, Baner, parentSig(сигнал юниту).
2. Простой само-стоятельный тригер. // не чья-то деталь.
Он добавляется в локацыю, ему отключают активность и указывают основной линк на фигуру.
Когда ему любым способом включат активность (обычно, другим тригером активируем этот),
то он полезет в свою процедуру обновы и там попытается Активировать ешё какую-то фигуру.
Если у тригера не будет ueWaitFull, то он само-отлючит себе Активность.
3. Капкан (точ-филд).
Добавляется в локацыю и должэн быть активен, чтобы пытаться кого-то поймать в свои габариты.
Капкан посылает на орбиту своего геометрического представителя через процу UpdSelf_TrigerToOrbit,
если у капкана пусто в свойстве P_TrigFrom. И через некие выяснения орбита может заполнить P_TrigFrom,
адресом фигуры, которая попала в особые приметы и геометрию капкана. Некоторые капканы пытаются
поймать лиш главного героя - если в приметах фигуры нет отметки "главный герой", то она не сможет
попасть в свойство P_TrigFrom, и капкан на неё не обратит внимания.
Если P_TrigFrom не ноль, то капкан пытается провести обычную реакцию для само-стоятельных тригеров
через процедуру ProcTriger(trigRunCase) и, сразу после этого, P_TrigFrom, обычно, обнуляют.
4. Следитель (сэнсор). // отрицательный trigRunCase
Добавляется в локацыю и должэн быть активен, чтобы в процедуре обновы заходить в свой
особый кейс trigRunCase и усматривать кондицыю (совпадение любых нужных переменок).
Если кондицыя случается, то тут-же кейс предусматривает какую-то явную реакцию и может
свободно изменить свойства самого тригера - например, дать ему отдых на несколько секунд.
// ---
Микс-варианты, которые можно получить из само-стоятельного тригера, за счёт важных свойств.
= pF->trigDamba. (+) //только положытельное, включяя ноль
Обычно, это ноль, но чтобы блокировать включение НЕ-активного тригера, сюда можно поставить
число этих блокирований. Это свойство перехватывает сигнал активацыи прямо в корне pF->ActiveOn();
Тоесть, с этим свойством, фигура тригера вобше не становится активной даже на миг.
Смысл дамбы простой..
По квэсту надо собрать три коробки, которые при факте своего "забирания" выдают сигнал
активации на не-активный тригер "Успех" с дамбой в 2 единицы. Два первых сигнала уйдут в дамбу и
тригер "Успех" останется не-активным, хотя дамбы больше нет. И вот сигнал от третьей коробки
активирует "Успех" и выдаётся подарок - сам тригер "Успех" активирует заранее готовый предмет,
который стоял не-активным, поэтому его раньшэ не было видно и нельзя было взять, а теперь можно.
Свойство Дамба автоматически не востанавливается. Если нужно повторно 2 единицы поставить, то
можно назначить изначально trigRunCase, в котором можно что хочеш с тригером сделать.
= pF->waitNow. (+) Это ожидание. // pF->waitFull помогает для возможного контроля и визуализацыи.
Обычно, это ноль. Если здесь больше ноля, то сначала нужно сточить это к нолю, а потом будет реакция.
Можно назначать waitNow (и waitFull) как угодно, но есть два свойства, которые автоматически
пытаются востанавливать это "ожидание реакции"..
= pF->ueWaitNow. (+) Это задержка реакции. (перед).
= pF->ueWaitFull. (+) Это отдых после реакции. (после).
Свойство ueWaitNow может принимать отрицательный вид, чтобы не использовать лишних флажков и
показывать факт "в свойстве waitNow сейчас пре-задержка, а не отдых".
Свойство ueWaitFull может быть Нолём и, тогда простой тригер авто-отключается после своей реакции.
Смысл "ожиданий" таков..
Создаём тригер, у которого реакция (trigRunCase) не будет отрицательным кейсом.
8000 v pF->waitNow v pF->waitFull; //в редакторе, назначим 8 секунд и оставим тригер активным.
Локацыя загрузится и получится Авто-тригер, потому-что он начал работу с момента загрузки локацыи,
но вынужден подождать 8 секунд, а потом сработать и само-отключиться (pF->ueWaitFull ноль-умолчанка).
А теперь, допустим, что pF->ueWaitNow в редакторе получил 2000.
Тогда локацыя загрузится, и через 8 секунд наш тригер захочет сработать,
но ему придётся ешё 2 секунды подождать, и только потом сработать и само-отключиться.
Наконец, к пре-идушему тригеру добавим, чтобы pF->ueWaitFull получил в редакторе 5000.
Локацыя загрузилась и через 10 секунд произошла реакцыя. После, вместо само-отключения, тригеру было
назначено 5 секунд отдыха. Когда 5 секунд прошли, то пришлось ешё 2 секунды ждать и сработать, а
потом снова получить 5 секунд отдыха. Получилось 10 секунд до первой реакцыи, а потом через
каждые 7 секунд бесконечный повтор реакцыи (если в кейсе реакцыи нет смены свойств).
Вышэ забавный пример, где не обязательно сразу применять "задержку" и "отдых".
Иногда, полезно сделать пре-задержку и этим дать шанс игроку отключить "задержаный тригер",
а если игрок не успевает, то тригер срабатывает.
Часто авто-тригерам (есть ожидание и тригер сразу активен) назначают огромные ожидания,
которые стачиваются несколько минут, а может и часов.
Например, авто-тригер, который заканчивает игру и говорит "игрок не уложился в даное ему время".
Получается, что такой авто-тригер определяет весь отрезок игры, если его не подламывать.
= pF->trigOff_AfterWait. (+) // авто-отключение после ожидания отдыха тригера.
Это флажок со значениями 0, 1, 2. //двойка только для технических целей (в редакторе ставим лиш 0 или 1).
Он требуется для нормальной имитации абилок - тригер отключён и получает активацию - срабатывает
и получает отдых - в это время может рисовать спад отдыха - потом само-отключается и готов активироваться.
Если этот флажок Ноль, то всегда остаётся нолём и не мешает тригеру работать.
А если там единица, то мы не мешаем Задержке и дожидаемся, когда тригер сработает и здесь
ставим Двойку вместо единицы - нам уже не важно, будет отдых или нет - как-только мы
попадём в следуший раз близко к срабатыванию тригера, то мы само-отключимся.
Если trigRunCase отрицательный, то ноль в ueWaitFull не отключает тригер, зато trigOff_AfterWait
это сделает, но смысла мало - отрицательный кейс не надо отключать.
= pF->trigRunKlv. (+)
Это суровое количество срабатываний тригера. Ноль, означает Бесконечность срабатывания.
Если поставить значение 3, то сразу после третьего срабатывания, тригер само-уничтожается.
Тоесть, такого тригера больше не будет.
Тема в архиве.