t1aro
alZarif
Dr.Schmeisser
KhanBagatur
gurvinek2005
Crusader556
Haktar
Mady
Valyrian_Legionnaire
DinarMayor
Corrector
kosak4
Farin Frostgeir
Гарнизонный скрипт – дополнительное усиление гарнизона ИИ, призванное улучшить обороноспособность фракций под управлением компьютера. В движке эта функция отсутствует, это полностью придуманная и внедренная мододелами функция.
Целесообразность ее использования дискутабельна, тесты ИИ показывают, что при правильно составленном ai_label - ИИ самостоятельно собирает неслабые гарнизоны в поселениях. Но и при этом бывает, что в ключевых провинциях в зоне активных действий действительно отсутствует крупный гарнизон. Использоваться может как при нападении игрока на поселение ИИ, так и при нападении ИИ на ИИ.
На сегодняшний момент есть три основных рабочих варианта прописи гарнизонного скрипта, оптимизированные для того, чтобы не ронять производительность процессора и не влиять на время перехода хода.
Первый вариант срабатывания – в момент, когда поселение только что выбрано для осады и стек осаждающего войска начинает путь к нему.
monitor_event Transgression TransgressionName = TC_INSTIGATE_SIEGE
В этом случае гарнизонные юниты появляются еще до того, как поселение получит изображение осажденного на страткарте. Юниты гарнизона будут видны во время осады и число солдат в добавленных юнитах будет уменьшаться, как и у прочих отрядов в осажденном поселении. При этом, если скрипт написан и для случаев ИИ против ИИ, атакующая фракция ИИ будет видеть эти юниты и учитывать их наличие при планировании штурма.
Более распространенный вариант прописи – срабатывание в момент, когда поселение уже осаждено и атакующая сторона выбирает действие «атаковать».
monitor_event GeneralAssaultsResidence CharacterIsLocal
В этом случае для пользователя открывается меню атаки поселения, где можно выбрать "автобой", "бой на карте", либо "продолжение осады". И в этот момент в поселении появляется гарнизон. Доступны ли такие варианты выбора в случае ИИ против ИИ – наверняка неизвестно, но с учетом третьего (см. ниже) механизма гарнизонного скрипта – видимо нет. Таким образом, ИИ не сможет отозвать штурм и продолжить осаду, если появление гарнизона меняет соотношение сил не в пользу атакующих, как это может сделать игрок, увидев появившийся гарнизон. Что делает крайне сомнительным применение варианта "ИИ против ИИ".
В модах вы можете встретить боле детальный вариант данной прописи, когда учитывается случай нападения на осаждающую армию извне
monitor_event GeneralAssaultsGeneral not CharacterIsLocal
and TargetFactionIsLocal
В данном случае армия ИИ пытается деблокировать свое поселение, осажденное игроком.
Также есть вариант вылазки гарнизона против осаждающих
monitor_event UngarrisonedSettlement SettlementName Paris
and I_SettlementUnderSiege Paris
В целом, подобная детализация строго на любителя.
Третий вариант прописи скрипта – появление юнитов в гарнизоне в момент, когда игрок выбирает в меню атаки осажденного поселения вариант «штурмовать, бой на тактической карте»,
monitor_event ButtonPressed ButtonPressed siege_assault_button
либо «продолжение осады» -
monitor_event ButtonPressed ButtonPressed siege_maintain_button
Этот вариант работает только для случая «игрок осаждает ИИ», потому что ИИ при осаде (да и вообще) никаких «кнопок меню» нигде не нажимает. В случае если игрок выбрал продолжение осады, то гарнизонные юниты остаются в поселении и несут потери от осады.
Все перечисленные варианты мониторов возможны для прописи в оптимизированном виде, т.е. с одним монитором для всех необходимых поселений. При нерациональной прописи скрипта его срабатывание возможно каждый раз, когда игрок кликает на осажденное поселение, это следует иметь в виду.
Вторым необходимым условием для работы гарнизонного скрипта является наличие специально выделенного «гарнизонного юнита/юнитов». Это нужно для того, чтобы после окончания осады осажденная сторона не получала дополнительное подкрепление в виде гарнизонных отрядов, переживших осаду. И тем более, чтобы гарнизонные отряды не накапливались у фракции в случае, если не было штурма и осада просто снята. Для того, чтобы автоматически распускать «гарнизонные юниты» после осады, требуется отдельная запись для них в файле export_descr_unit.txt. Принципиальным отличием гарнизонного юнита от других является атрибут, который позволит движку игры избирательно применить к нему команду destroy_units. Движок игры позволяет использовать любые придуманные атрибуты. Как правило, используется слово garrison, но вы можете выбрать что угодно для себя (если атрибут из двух и более слов, используется нижнее подчеркивание – garrison_unit, например).
Способов, когда именно удалять гарнизонные юниты, много. Это зависит от вашего видения, как именно должен работать этот скрипт. Для любого варианта прописи возможны оговорки.
В первом и третьем вариантах скрипта команда destroy_units может применяться после штурма и в случае снятия осады. Во втором – после штурма, при снятии осады, а также при отмене штурма и продолжении осады. Если вы хотите получить один набор юнитов, который будет находиться в поселении до конца осады, то никаких «промежуточных» удалений не потребуется. Если вы хотите, чтобы каждый раз при появлении меню штурма состав гарнизона менялся, а также чтобы он не нес потери от пребывания в осажденном поселении, придется распускать его в конце каждого хода.
Решение в какие поселения включать гарнизонный скрипт вы принимаете сами. Вариантов масса – только столицы фракций, либо только крупные города, либо все поселения на карте.
Подробно разберем первый вариант. Лично мне он кажется наиболее логичным.
Во втором мониторе на момент окончания хода ребелов (когда все остальные фракции сделали свой ход) проверяем, есть ли у фракции осажденные поселения, и если таковых нет, то распускаем гарнизонные юниты. Команда на роспуск юнитов действует на все юниты фракции, имеющие данный атрибут, то есть избирательно убрать гарнизон в одном поселении и оставить в другом не получится. При данной прописи может выйти, что если у фракции больше одного поселения осаждено, то гарнизонные юниты, оставшиеся в поселении, будут доступны для использования еще некоторое время. В целом, с точки зрения жизненной логики, это даже в чем-то объяснимо – фракция находится на военном положении и гарнизон поставлен в готовность.
В случае повторной осады поселения, где еще не убран предыдущий гарнизон, новые отряды также появятся, т.к. счетчик осажденного поселения обнулился во втором мониторе по условию not I_SettlementUnderSiege. Для предотвращения подобной ситуации возможно введение дополнительного счетчика в первом мониторе, который позволит гарнизону появляться в поселении только через определенное число ходов. Чтобы не усложнять материал для понимания, я не привожу здесь этот способ, при необходимости могу написать дополнительно.
Также при необходимости могу подробно расписать второй и третий варианты прописи скрипта.
Надеюсь, в нынешнем виде информация о написании гарнизонного скрипта стала доступнее.
Целесообразность ее использования дискутабельна, тесты ИИ показывают, что при правильно составленном ai_label - ИИ самостоятельно собирает неслабые гарнизоны в поселениях. Но и при этом бывает, что в ключевых провинциях в зоне активных действий действительно отсутствует крупный гарнизон. Использоваться может как при нападении игрока на поселение ИИ, так и при нападении ИИ на ИИ.
На сегодняшний момент есть три основных рабочих варианта прописи гарнизонного скрипта, оптимизированные для того, чтобы не ронять производительность процессора и не влиять на время перехода хода.
Первый вариант срабатывания – в момент, когда поселение только что выбрано для осады и стек осаждающего войска начинает путь к нему.
monitor_event Transgression TransgressionName = TC_INSTIGATE_SIEGE
В этом случае гарнизонные юниты появляются еще до того, как поселение получит изображение осажденного на страткарте. Юниты гарнизона будут видны во время осады и число солдат в добавленных юнитах будет уменьшаться, как и у прочих отрядов в осажденном поселении. При этом, если скрипт написан и для случаев ИИ против ИИ, атакующая фракция ИИ будет видеть эти юниты и учитывать их наличие при планировании штурма.
Более распространенный вариант прописи – срабатывание в момент, когда поселение уже осаждено и атакующая сторона выбирает действие «атаковать».
monitor_event GeneralAssaultsResidence CharacterIsLocal
В этом случае для пользователя открывается меню атаки поселения, где можно выбрать "автобой", "бой на карте", либо "продолжение осады". И в этот момент в поселении появляется гарнизон. Доступны ли такие варианты выбора в случае ИИ против ИИ – наверняка неизвестно, но с учетом третьего (см. ниже) механизма гарнизонного скрипта – видимо нет. Таким образом, ИИ не сможет отозвать штурм и продолжить осаду, если появление гарнизона меняет соотношение сил не в пользу атакующих, как это может сделать игрок, увидев появившийся гарнизон. Что делает крайне сомнительным применение варианта "ИИ против ИИ".
В модах вы можете встретить боле детальный вариант данной прописи, когда учитывается случай нападения на осаждающую армию извне
monitor_event GeneralAssaultsGeneral not CharacterIsLocal
and TargetFactionIsLocal
В данном случае армия ИИ пытается деблокировать свое поселение, осажденное игроком.
Также есть вариант вылазки гарнизона против осаждающих
monitor_event UngarrisonedSettlement SettlementName Paris
and I_SettlementUnderSiege Paris
В целом, подобная детализация строго на любителя.
Третий вариант прописи скрипта – появление юнитов в гарнизоне в момент, когда игрок выбирает в меню атаки осажденного поселения вариант «штурмовать, бой на тактической карте»,
monitor_event ButtonPressed ButtonPressed siege_assault_button
либо «продолжение осады» -
monitor_event ButtonPressed ButtonPressed siege_maintain_button
Этот вариант работает только для случая «игрок осаждает ИИ», потому что ИИ при осаде (да и вообще) никаких «кнопок меню» нигде не нажимает. В случае если игрок выбрал продолжение осады, то гарнизонные юниты остаются в поселении и несут потери от осады.
Все перечисленные варианты мониторов возможны для прописи в оптимизированном виде, т.е. с одним монитором для всех необходимых поселений. При нерациональной прописи скрипта его срабатывание возможно каждый раз, когда игрок кликает на осажденное поселение, это следует иметь в виду.
Вторым необходимым условием для работы гарнизонного скрипта является наличие специально выделенного «гарнизонного юнита/юнитов». Это нужно для того, чтобы после окончания осады осажденная сторона не получала дополнительное подкрепление в виде гарнизонных отрядов, переживших осаду. И тем более, чтобы гарнизонные отряды не накапливались у фракции в случае, если не было штурма и осада просто снята. Для того, чтобы автоматически распускать «гарнизонные юниты» после осады, требуется отдельная запись для них в файле export_descr_unit.txt. Принципиальным отличием гарнизонного юнита от других является атрибут, который позволит движку игры избирательно применить к нему команду destroy_units. Движок игры позволяет использовать любые придуманные атрибуты. Как правило, используется слово garrison, но вы можете выбрать что угодно для себя (если атрибут из двух и более слов, используется нижнее подчеркивание – garrison_unit, например).
Способов, когда именно удалять гарнизонные юниты, много. Это зависит от вашего видения, как именно должен работать этот скрипт. Для любого варианта прописи возможны оговорки.
В первом и третьем вариантах скрипта команда destroy_units может применяться после штурма и в случае снятия осады. Во втором – после штурма, при снятии осады, а также при отмене штурма и продолжении осады. Если вы хотите получить один набор юнитов, который будет находиться в поселении до конца осады, то никаких «промежуточных» удалений не потребуется. Если вы хотите, чтобы каждый раз при появлении меню штурма состав гарнизона менялся, а также чтобы он не нес потери от пребывания в осажденном поселении, придется распускать его в конце каждого хода.
Решение в какие поселения включать гарнизонный скрипт вы принимаете сами. Вариантов масса – только столицы фракций, либо только крупные города, либо все поселения на карте.
Подробно разберем первый вариант. Лично мне он кажется наиболее логичным.
monitor_event Transgression TransgressionName = TC_INSTIGATE_SIEGE and FactionIsLocal and not TargetFactionIsLocal campaign_wait 0.1 if I_SettlementUnderSiege Paris and I_EventCounter paris_v_osade = 0 проверка, если игрок напал на ИИ, и счетчик гарнизона нулевой – то есть при данной осаде гарнизон еще не появлялся, спаунится гарнизон set_event_counter paris_v_osade 1 - все, счетчик сработал, больше ничего не будет спауниться, пока эта осада не завершится create_unit Paris, Garrison Spearmen, num 3, exp 3, arm 0, wep 0 create_unit Paris, Garrison Cavalry, num 2, exp 3, arm 0, wep 0 create_unit Paris, Garrison Swordsmen, num 1, exp 3, arm 0, wep 0 if RandomPercent > 66 create_unit Paris, Garrison Swordsmen, num 1, exp 3, arm 0, wep 0 – подобным образом вы можете задать случайное появление отряда в гарнизоне end_if end_if if I_SettlementUnderSiege London - то же самое для другого поселения and I_EventCounter london_v_osade = 0 - название счетчика для каждого поселения свое, не забываем переименовывать set_event_counter london_v_osade 1 - мы меняем значение счетчика до спауна армии, чтобы в случае, если в поселении больше нет места для новых отрядов (в этом случае в логе будет ошибка, что невозможно создать отряд в поселении), скрипт не сбился и счетчик не остался нулевым create_unit London, Garrison Spearmen, num 1, exp 0, arm 3, wep 0 - обратите внимание, что прописано разное число и параметры юнитов в зависимости от поселения, кому сильнее, кому слабее самостоятельно выбираете create_unit London, Garrison Cavalry, num 1, exp 0, arm 3, wep 0 create_unit London, Garrison Swordsmen, num 1, exp 0, arm 3, wep 0 end_if .... - дальше также размножаете для всех нужных поселений end_monitor
monitor_event FactionTurnEnd FactionType slave if I_IsFactionAIControlled france and not I_FactionBesieged france destroy_units france garrison_unit end_if if I_IsFactionAIControlled england and not I_FactionBesieged england destroy_units england garrison_unit end_if ..... и так для всех фракций if not I_SettlementUnderSiege Paris set_event_counter paris_v_osade 0 end_if if not I_SettlementUnderSiege London set_event_counter london_v_osade 0 end_if .... и так для всех поселений end_monitor
Во втором мониторе на момент окончания хода ребелов (когда все остальные фракции сделали свой ход) проверяем, есть ли у фракции осажденные поселения, и если таковых нет, то распускаем гарнизонные юниты. Команда на роспуск юнитов действует на все юниты фракции, имеющие данный атрибут, то есть избирательно убрать гарнизон в одном поселении и оставить в другом не получится. При данной прописи может выйти, что если у фракции больше одного поселения осаждено, то гарнизонные юниты, оставшиеся в поселении, будут доступны для использования еще некоторое время. В целом, с точки зрения жизненной логики, это даже в чем-то объяснимо – фракция находится на военном положении и гарнизон поставлен в готовность.
В случае повторной осады поселения, где еще не убран предыдущий гарнизон, новые отряды также появятся, т.к. счетчик осажденного поселения обнулился во втором мониторе по условию not I_SettlementUnderSiege. Для предотвращения подобной ситуации возможно введение дополнительного счетчика в первом мониторе, который позволит гарнизону появляться в поселении только через определенное число ходов. Чтобы не усложнять материал для понимания, я не привожу здесь этот способ, при необходимости могу написать дополнительно.
Также при необходимости могу подробно расписать второй и третий варианты прописи скрипта.
Надеюсь, в нынешнем виде информация о написании гарнизонного скрипта стала доступнее.
