[Ergistal]

Скрипторий. Библиотека готовых скриптов МТВ2.

Спойлер (раскрыть)

Скрипто?рий (лат. sсriptorium от scriptor ? писец, переписчик) ? мастерская по переписке рукописей, преимущественно в монастырях. Первые скриптории возникли в VI?VII веках на юге Италии, во Франции, в Ирландии, Испании. Наибольшей славой в эпоху Карла Великого пользовался скрипторий Турского монастыря Святого Мартина, аббатом которого был Алкуин. Вначале книгу (как и во времена поздней античности) писали под диктовку, держа материал для письма на коленях. Столов не было. Затем, вероятно в V веке, в мастерских появились столы. Во всяком случае, именно к этому времени относятся иконографические изображения каллиграфов, сидящих за столами. С VIII?IX веков подобные изображения стали нормой. В XIII веке скриптории приходят в упадок, книжным производством начинают заниматься городские ремесленники.

В этой теме будем собирать готовые скрипты, которые можно непосредственно применить в моде, только подставив свои данные. Предупреждаю сразу, флуд, споры, вопросы будут пресекаться на корню. Обсуждение, предоставленных скриптов можно вести в этой теме:
Для просмотра ссылки Зарегистрируйтесь
Пожалуйста, описывайте подробно назначение скрипта. Очень желательно подробно комментировать текст, чтобы читающим легче было разобраться. Кроме того, старайтесь указывать авторство скрипта или хотя бы мод из которого он взят, если написали его не сами. Все размещённые скрипты проверяйте на работоспособность. Такой вариант: "там кто-то написал вот кидаю сюда скрипт" не принимается во-внимание. Лучшие и проверенные скрипты выносятся в шапку темы.

1. Генерация агента в заданной точке.

Спойлер (раскрыть)

Скрипт генерирует агентов в заданной точке карты. (Скрипт от Камрада Максима Суворова предоставил Vadim) Данный Скрипт прописываеться в начале, или в конце Файла
data\world\maps\campaign\imperial_campaign\ campaign_script.txt

monitor_event FactionTurnStart FactionType mongols;
and I_TurnNumber = 1 ;номер хода
spawn_character mongols random_name, merchant, age 36, x 190, y 7; чтобы получить ещё агента, скопируйте эту строку.
terminate_monitor
end_monitor

mongols - подставляете имя фракции.
mongols random_name имена какой фракции исползовать для агента,
merchant тип созданного агента, также могут быть
Spy, priest, princess, diplomat, assassin
admiral (координаты только на море),
inquisitor, witch, heretic (без специальных условий только за фракцию rebels)
x 190, y 7 задаются координаты точки создания агента.

2. Скрипт по возрождению разгромленной фракции.

Спойлер (раскрыть)

Цитата

declare_counter ozhivlenieireland 0 ;   задаём переменную, которая которая будет проверять, есть ли ещё города у Ирландии.

monitor_event FactionTurnEnd FactionIsLocal
  and I_NumberOfSettlements ireland < 1 ; Проверяем, если у ютов городов меньше 1.
  and I_CompareCounter ozhivlenieireland = 0  ; И если переменная Возрождение Ирландцев  ещё не активирована,
  and RandomPercent > 1 ; шанс на возрождение фракции на этом ходу 10%, сделано для того, каждый ход не появлялось по новому стеку войска
  and RandomPercent < 11
   set_counter ozhivlenieireland 1
end_monitor

monitor_event FactionTurnEnd FactionIsLocal
  and I_CompareCounter ozhivlenieireland > 0
   add_events ; Если переменная Возрождения ютов активна, то содать событие "Ирландия возвращается"
    event emergent_faction ireland
;    region Yuti_Region
    date 0
   end_add_events

   spawn_army ; создать армию Ирландии со случайным командирам по таким-то координатам, со следующим составом войск...
   faction ireland
   character random_name, named character, age 19, x 22, y 51, family
   unit NE Bodyguard    exp 2 armour 0 weapon_lvl 0
   unit Angl horse combatant   exp 1 armour 0 weapon_lvl 0
   unit Angl combatant    exp 1 armour 0 weapon_lvl 0
   unit Yut robber    exp 1 armour 0 weapon_lvl 0
   unit Yut phalanx    exp 0 armour 0 weapon_lvl 0

  end
end_monitor

monitor_event FactionTurnStart FactionIsLocal ; Проверяем в начале хода, если Ирландцы захватили хоть один город, тогда событие "возрождение Ирландии" отключить.
  and I_CompareCounter ozhivlenieireland > 0
   set_counter ozhivlenieireland 0
end_monitor

Скрипт повторять по числу возрождаемых фракций. Изменяя переменную и координаты возрождения.
Единственная слабость этого скрипта - пока Ирландия не захватит хоть один город стеки будут появлятся сплошным потоком, с шансом 10%. И без проверки возможен вылет, если в точке возрождения будет торчать любой другой отряд.

Скрипт взят из исторического мода "Ветер Скандии", Автор скрипта - Гриф. Ссылка на форум:

Спойлер (раскрыть)

Для просмотра ссылки Зарегистрируйтесь

3. скрипт при игре за Папскую область дает 100% вероятность того, что Папа объявит предложенный вами поход.

Спойлер (раскрыть)

Думаю, что многие, кто пытался сделать играбельными Папскую область в ваниле удивлялись тому, что играя за нее приходится просить Папу римского об объявлении крестового похода, как-то нелогично получается, управляя Папой просить у него что-то.

В общем скрипт при игре за Папскую область дает 100% вероятность того, что Папа объявит предложенный вами поход:

monitor_event FactionTurnStart FactionIsLocal
set_faction_standing papal_states papal_states 1.0
end_monitor

ВОПРОС
Можно скриптом прописать, чтобы каждый ход с союзными фракциями отношения улучшались до максимума, а с враждебными падали до минимума. Как это можно сделать с помощью скрипта?

Спойлер (раскрыть)

Сейчас по памяти расскажу.
В файле descr_strat.txt в конце прописываются дипломатические отношения:
например:

Цитата

faction_standings england,  -1.0 france, scotland, denmark, slave

Это означает, что у Англии с францией, Шотландией, Данией и мятежниками - отношения самые плохие. (Цифра меняется от -9,9(самые плохие) до 9,9(отличные) с шагом 0,1)
Плохие отношения не обозначают войну, а скорее её возможность, отношение дипломатов к вашим предложениям.

Идём дальше.
В этом же файле задаются с кем стартовые война, союз или вассалитет.

Цитата

faction_relationships russia, allied_with  poland, england
faction_relationships  england, at_war_with  france, scotland, denmark, slave

Теперь если эти отношения нужно изменить в процессе игры, есть такие команды (Они прописываются в файле campaign_script.txt):
set_faction_standing russia byzantium -9.9 (установить отношения между Россией и Византией -9,9 отвратительные)
console_command diplomatic_stance byzantium england war объявить войну между Византией и Англией.
console_command diplomatic_stance byzantium portugal neutral Установить нейтральные отношения, между Византией и Португалией.
console_command diplomatic_stance byzantium lithuania allied Подружить Византию и Литву


Теперь по существу вопроса, как сделать вечный мир? Каждый ход создавать скрипт, установить дип отношения стран А и Б в "союзные", и отношения повышать до тёплых и тогда они даже если захотят, будут дружить.
То же и с вечной войной.
Подробно расписывать как сделать скрипт не стану, или расписать всё-же?:

Цитата

monitor_event Diplomat_script FactionType slave
and  I_IsFactionAIControlled teutonic_order
set_faction_standing  lithuania teutonic_order -9.9
console_command diplomatic_stance lithuania teutonic_order war
end_monitor

1. Это скрипт выполняется во время перехода хода к Повстанцам (каждый ход).
2. Если Тевтонский орден управляется компьютером (ИИ).
3. Установить дип. отношения -9,9 отвратительные,
4. Объявить войну между Литвой и Тевтонским орденом
5. Конец скрипта.

[bitterhowl]

Итак, оптимизация скриптов нужна главным образом для быстродействия, чтобы не загружать процессор и операционку. Возможно, помимо быстродействия уменьшится и вероятность вылетов заодно. Полезно знать принцип работы программного кода (я не программист, не претендую, пишу только то, что прочел в теме про оптимизацию). Игра разбирает каждый монитор поэтапно, проверяет каждое условие, и если оно верное, то переходит к следующему. На это и тратится время работы процессора, поэтому нужно уметь оптимально подбирать условия скрипта. Пример как это работает.

Спойлер (раскрыть)

monitor_event FactionTurnStart FactionType england
and FactionBuildingExists >= governor_house
and FactionIsLocal

Игра поэтапно проверяет условия, т.е. начало хода фракции, проверяет тип фракции в момент начала хода каждой фракции и если это Англия, то идет дальше. При этом проверка условия наличия у фракции здания "дом губернатора" занимает больше времени, чем проверка условия FactionIsLocal, и при вышеописанном расположении мониторов получается, что если вы играете не за Англию, то игра долго проверяет наличие здания у англичан, а потом обнаруживает что эта фракция ИИ и сбрасывает монитор. В таком случае выходит что процессор выполнил бесполезную работу, затратив время вхолостую. То есть в этом примере как минимум FactionIsLocal должно проверяться до FactionBuildingExists, чтобы не тратить время работы процессора зря. Под этим и понимается рациональное расположение условий.

Вот еще более наглядный пример, с цифрами. Допустим, на карте кампании действует 300 персонажей, из них 15 английских. Например, нужно проверить, если на момент начала хода английского персонажа с определенным уникальным трейтом Англия владеет Парижем - происходит событие. Если Парижем владеет другая фракция, то другое событие. Такой скрипт при этом

Спойлер (раскрыть)

monitor_event CharacterTurnStart FactionType england
and Trait xx_trait > 0
and I_SettlementOwner Paris england ... нужный эффект от англии
end_monitor

monitor_event CharacterTurnStart FactionType england
and Trait xx_trait > 0
and I_SettlementOwner Paris france ... нужный эффект от франции
end_monitor

monitor_event CharacterTurnStart FactionType england
and Trait xx_trait > 0
and I_SettlementOwner Paris hre ... нужный эффект от св римской империи
end_monitor

Таким образом, при проверке этих условий монитор сработает 900 раз (3 монитора на 300 персонажей по условию CharacterTurnStart), из них для Англии сработает 45 мониторов (15 персонажей и 3 монитора), дальше проверка трейта будет проходить 45 раз, из которых эффективными будут 3 (1 персонаж с уникальным трейтом и 3 монитора), и 3 раза проверится принадлежность Парижа.

А вот если запись скрипта будет такой

Спойлер (раскрыть)

monitor_event CharacterTurnStart FactionType england
and Trait xx_trait > 0
if I_SettlementOwner Paris england ... нужный эффект от англии
end_if
if I_SettlementOwner Paris france ... нужный эффект от франции
end_if
if I_SettlementOwner Paris hre ... нужный эффект от св римской империи
end_if
end_monitor

При этом монитор запустится 300 раз (300 персонажей на карте для условия CharacretTurnStart), 15 раз для Англии проверится Trait xx_trait >0 (15 английских персонажей на карте) и 3 раза проверится принадлежность Парижа. Итого на 600 запусков монитора CharacterTurnStart меньше и на 30 проверок трейта для Англии меньше. Процессор занят меньше на 2/3 при том, что на карте произойдет то же самое. Если учесть, что в скрипте бывает несколько тысяч с лишним мониторов и больше 300 персонажей на карте, цифры "холостой" работы процессора при нерациональной прописи скрипта возрастают на порядки.

По длительности загрузки процессора команды распределяются так - if < monitor_event < monitor_conditions < while. То есть проверка условия с if занимает наименьшее время, дальше идет периодическая проверка ивента, проверка условия происходит постоянно в фоновом режиме и постоянно занимает процессор, так же как и проверка условия while. По некоторым сведениям, 70 monitor_conditions снижают скорость игры до 1 fps. В любом случае, чем больше у вас в скрипте monitor_conditions и while, тем больше грузится процессор и тем дольше обсчитывается скрипт. В той теме на твц есть упоминание мода DotS, который использует методику "nesting ifs" (насколько я понимаю, это разветвленное дерево с использованием условия if), где campain_script имеет объем 60 мегабайт, миллион строк кода и при этом 1 monitor_event и 1 monitor_conditions и притормажиает только при ходе ребелов, т.к. исполняет многочисленные консольные команды.

В дополнение темы оптимизации - пишут, что стараются избегать monitor_conditions, как чумы, приводят пример про мод 1648 - добавление/удаление одного монитора monitor_event, содержащего 250 проверок if никак не отражается на производительности игры. Добавление/удаление скрипта "Carl the taxman" (известный экономический), содержащего 600 мониторов monitor_event для всех фракций в игре - меняет производительность на 40 секунд.

Здесь же. Одно из самых вредных условий это CharacterTurnStart/End, потому что как мы теперь понимаем, срабатывает для каждого персонажа на карте, это потом уже движок проверяет принадлежность фракции (и тратит на это процессорное время тоже). Дальше по загрузности идет SettlementTurnStart/End, менее вредное, для каждого поселения проверяется то же самое. Ну и потом FactionTurnStartEnd. Какая альтернатива? Предлагают следующие операторы - CharacterSelected (когда игрок выбрал персонажа), Pre/PostBattle (до или после сражения), EventCounter (значение определенного счетчика событий). По идее эти мониторы срабатывают реже и более адресно, нагрузка на процессор снижается.

Вот еще важный момент из учебника alpaca Порядок загрузки для событий TurnStart и TurnEnd выглядит следующим образом: CharacterTurn[Start/End], SettlementTurn[Start/End],FactionTurn[Start/End]. Почему это важно? Иногда есть взаимосвязанные мониторы в скрипте, но они не работают как вы задумали, т.е. событие происходит в лучшем случае на ход позже, или вообще не происходит. Тогда смотрите очередность мониторов, возможно, к примеру какой-то счетчик меняет нужное вам значение раньше, чем проверяется его значение в другом нужно вам мониторе. Ну и совсем общее - все файлы игра читает сверху вниз, в этом смысле очередность скрпитов и особенно трейтов имеет большое значение.


Да, вот еще уточнение - порядок файлов, которые проверяет игра всегда один, сначала campaign_script, потом export_descr_character_traits, потом export_descr_ancillaries.

Почему это имеет значение лично я убедился на конкретном примере - одно и то же событие, PostBattle, к которому я хотел привязать эффекты в скрипте и трейтах, проверяется с вышеуказанной очередностью и мне пришлось менять скрипт. Я хотел чтобы после битвы в случае появления трейта "Ранен" начинал бы крутиться счетчик в campaign_script. Но получается, что CS проверяет событие PostBattle первым, и в этот момент трейты еще не проверялись и не присваивались и счетчик не сработает никогда, даже если генерала все же ранят. Поэтому пришлось менять условие в CS на менее выгодное CharacterTurnEnd, которое проверяется чаще и больше грузит процессор, ну зато проверяется тогда, когда трейты после битвы уже присвоены.

[DenStark]

Для просмотра ссылки Зарегистрируйтесь - список, расшифровка, примеры использования всех скриптовых условий, ивентов, команд, а также другие важные сведения для мододелов.

[bitterhowl]

Цитата

and event_counter is_the_ai 0 - здание доступно игроку,

оно доступно потому что игра не видит это условие вообще у здания.

Собственно, я не настаиваю, я поделился, как это использовать каждому решать безусловно самому

[Serge de Bouillon]

bitterhowl 04 февраля 2026, 15:08

оно доступно потому что игра не видит это условие вообще у здания.

Я немного не понял. Игра не видит условие со значением "0", но вдруг прозревает и видит его со значением "1"? Как она тогда при значении "0" запрещает его для ИИ и разрешает при значении "1"? У меня в моде три здания с таким условием, для одного я вчера поставил "0", для второго - "1", третье не трогал (оно должно было быть доступно и ИИ, и игроку), проследил за реакцией на стороне игрока и ИИ, - вроде бы совпало по всем трем (первое я увидел, а ИИ его не построил, второе я не увидел, но его построил ИИ, третье построили и я, и ИИ). Может быть совпадение или глюк, - надо будет перепроверить. Как раз начал кампанию с подредактированным условием, скоро увижу, строит ли ИИ то, что ему запрещено (не на одном поселении, как я посмотрел при тестировании вчера, а на всех). Тогда отпишусь.

[Serge de Bouillon]

Докладываю о проведенных экспериментах:
Условия and event_counter is_the_ai 0, and event_counter is_the_ai 1, and not event_counter is_the_ai 0, and not event_counter is_the_ai 1 ставились каждому зданию в файле EDB. Проверялась доступность постройки зданий для фракции игрока, а после двадцати ходов без вмешательства игрока проверялось изменение построек в двух замках и четырех городах , принадлежавших четырем фракциям, которыми управлял ИИ.
Результаты:
and event_counter is_the_ai 0 - все здания доступны игроку и ИИ. Приношу свои извинения камраду bitterhowl за высказанные сомнения.
and event_counter not is_the_ai 0 - все здания доступны игроку и ИИ.
and event_counter is_the_ai 1 - здания не доступны игроку, но доступны ИИ, который строил и апгрейдил как и в предыдущих случаях, в двух городах даже появлялись гильдии.
and event_counter not is_the_ai 1 - здания доступны игроку, но не доступны ИИ. Реально за двадцать ходов - ни одного нового здания, ни одного апгрейда существующих, даже ни одной гильдии!

Условия с нулем игнорируются, оперировать оказалось возможным только условиями с единицей. Переделал свой EDB. Кстати, поменял в нем не только условия для доступности зданий, но и для тех бонусов, которые обусловливались event_counter is_the_ai 0 (с event_counter is_the_ai 1 явно работают). Вполне возможно, что трудности достижения количества населения, необходимого для перехода к следующему уровню поселения, возникали именно из-за того, что полагавшиеся игроку бонусы от построек попросту не попадали в игру.

Спасибо bitterhowl за помощь!

[Serge de Bouillon]

Serge de Bouillon 06 февраля 2026, 20:40

Кстати, поменял в нем не только условия для доступности зданий, но и для тех бонусов, которые обусловливались event_counter not is_the_ai 1 (с event_counter is_the_ai 1 явно работают). Вполне возможно, что трудности достижения количества населения, необходимого для перехода к следующему уровню поселения, возникали именно из-за того, что полагавшиеся игроку бонусы от построек попросту не попадали в игру.

Получил вылет из-за единицы в условиях для бонусов (замена на ноль ничего не меняет). То ли event_counter is_the_ai 0 в них все-таки работает, то ли event_counter not is_the_ai в этих условиях работает без цифрового параметра. Проверить будет довольно геморно.

[alexPN]

Для проверки можно добавить перестановку event_counter-ра по действию в UI. Как-то так для установки в 1 по закрытию свитка справки(F1) и в 0 по закрытию свитка статистики фракций: в campaign_script.txt где-нибудь не в мониторе:

Спойлер (раскрыть)

        set_event_counter my_best_counter 0
	monitor_event ScrollClosed ScrollClosed help_scroll
		set_event_counter my_best_counter 1
	end_monitor
	
	monitor_event ScrollClosed ScrollClosed faction_ranking_scroll
		set_event_counter my_best_counter 0
	end_monitor 

Насколько я понимаю, для event_counter считаются установленными все значения, которые <= текущего.

[bitterhowl]

Serge de Bouillon 06 февраля 2026, 22:22

Serge de Bouillon 06 февраля 2026, 20:40

Кстати, поменял в нем не только условия для доступности зданий, но и для тех бонусов, которые обусловливались event_counter not is_the_ai 1 (с event_counter is_the_ai 1 явно работают). Вполне возможно, что трудности достижения количества населения, необходимого для перехода к следующему уровню поселения, возникали именно из-за того, что полагавшиеся игроку бонусы от построек попросту не попадали в игру.

Получил вылет из-за единицы в условиях для бонусов (замена на ноль ничего не меняет). То ли event_counter is_the_ai 0 в них все-таки работает, то ли event_counter not is_the_ai в этих условиях работает без цифрового параметра. Проверить будет довольно геморно.

Вылеты бывают ещё если в условиях здания с наймом юнитов есть building_min_present.

Кроме того, эта запись event_counter not is_the_ai должна иметь вид
not event_counter is_the_ai 1

[Serge de Bouillon]

bitterhowl 07 февраля 2026, 03:39

Кроме того, эта запись event_counter not is_the_ai должна иметь вид
not event_counter is_the_ai 1

Спасибо! Это у меня уже крыша поехала!
Конечно же, and not event_counter is_the_ai 0 и and not event_counter is_the_ai 1 ! Так и было в эксперименте. Обмишурился когда писал посты. Прошу простить, торопился и нервничал: кот не жрет ничего вторые сутки! Ношусь сейчас с ним.

[Serge de Bouillon]

alexPN 06 февраля 2026, 23:15

Для проверки можно добавить перестановку event_counter-ра по действию в UI...

Спасибо, alexPN! bitterhowl все объяснил. Я после проверки условий для здания решил исправить EDB, но меня сильно отвлекли (кот). Вернувшись к исправлению, я в суете и расстройстве "от чувствс" перепутал синтаксис, испоганил файл, что и привело к вылету. Не проверив результат, я бросился постить, но получилось еще хуже, чем сначала.
Исправляюсь.

[Serge de Bouillon]

Движок иезуит какой-то настраивал, однозначно! Проверил условие для бонуса здания и ... как бы это помягче сказать... охренел.
Я ожидал, что продублируется логика условий для доступности постройки: рабочие условия - and event_counter is_the_ai 1 , and not event_counter is_the_ai 1, остальные два просто игнорируются движком. Ну, как бы так, да! Но при этом!..
Что я сделал:
Геную сделал деревней с частоколом и населением 800 человек. Все бонусы для нее заблокировал. Сделал population_growth_bonus bonus 10 requires not event_counter is_the_ai 0 . Менял его и смотрел процент роста населения (при игре за соседа запускал прокачанного шпиона "снимать показания счетчика"). Получилось при игре за Геную:
event_counter is_the_ai 0 - +3.5
event_counter is_the_ai 1 - +1 (как и ожидалось)
not event_counter is_the_ai 0 - +1
not event_counter is_the_ai 1 - +3.5
А когда за Геную играл ИИ, получилось:
event_counter is_the_ai 0 - +2
event_counter is_the_ai 1 - +2 (Почему не +3.5? Движок подыгрывает игроку на 1.5!)
not event_counter is_the_ai 0 - -0.5
not event_counter is_the_ai 1 - -0.5
Я не возьмусь это комментировать. Замечу только, что однозначно правильно работает условие not event_counter is_the_ai 1, и, очевидно, event_counter is_the_ai 1 . При этом event_counter is_the_ai 0 не работает вообще, а not event_counter is_the_ai 0 ... Я перепроверил раз десять - все точно: блокирует бонус для обеих сторон!

[Serge de Bouillon]

"Движок подыгрывает игроку на 1.5!"
Я думал, это потому, что я экспериментировал на среднем уровне сложности. Удалил все бонусы вообще для Генуи, выбрал режим "очень сложно" (максимальный), зашел игроком и соседом - результат не поменялся! +1 для игрока, -0.5 для ИИ, - те же самые 1.5 единицы разницы. Я ждал, что будет по нулям, или хотя бы 0.5 разницы. Вот так реальность поправляет тех, кто пытается умничать!