[bitterhowl]

Автоматически сгенерированная тема для поддержки статьи - To view the link Register.

Сегодня, 17:32 = Дата публикации статьи в Библиотеки.
Сегодня, 17:32 = Дата обновления статьи в Библиотеки.

[gaulish723]

А что если скриптом ввести исторические события как респавн юнитов с героями-например мамлюков с бейбарсом илиОсмана с кингдомса. У меня есть вопрос по скриптингу.

[bitterhowl]

Дополнение, насчёт операторов campaign_wait и battle_wait.

Как я понимаю, они приостанавливают действие монитора, в котором находятся, чтобы за это время сработали другие мониторы в скрипте.

Корректируя скрипт для тактических битв, уменьшая количество monitor_conditions до одного, в который помещается все содержимое скрипта, столкнулся с тем, что накапливается большое число операторов battle_wait в одном мониторе.

Да, они через if, но получается, что скрипт считается сверху вниз, и каждый оператор ожидания тормозит весь монитор целиком. То есть части монитора, расположенные под разными if считываются последовательно, а не параллельно. Тогда как в ситуации, где в скрипте много monitor_conditions, каждый со своими if (как изначально в Германикусе, например) - они считываются параллельно.

Чтобы разрешить эту проблему для своего скрипта, пробую сейчас пользоваться скриптовым таймером. Если у кого-то есть опыт, поделитесь, пожалуйста.

[bitterhowl]

В дополнение к предыдущему сообщению - эмпирические данные. Размножил один monitor_conditions на несколько, скрипт значительно изменился.

Ранее был задан счётчик, отслеживающий перемещение отрядов игрока, в предыдущих тестах с одним монитором я подобрал значения для разного размера армий игрока, чтобы оценивать передвижения игрока и приближение к армии ИИ.

Сейчас после изменений мне два юнита дали значение как целая армия в предыдущем варианте.

Это показывает
а) частоту обращения движка к оператору monitor_conditions (высокая), раз счётчик показал такой драматический рост значения - подтверждение данных основной статьи про оптимизацию
б)влияние размера монитора и количества операторов wait на ход вычислений значений в мониторе - оптимизировать надо с умом и без фанатизма

В скрипт советника в целом достаточно безболезненно может включать значительное количество мониторов monitor_conditions без ущерба общей производительности, т. к. включается на короткое время по запросу.

Взаимодействие скрипта кампании и скрипта советника - ещё один вариант оптимизации. Думаю, DinarMayor мог бы хорошо поделиться опытом в этой сфере.

[DinarMayor]

bitterhowl

В скрипт советника в целом достаточно безболезненно может включать значительное количество мониторов monitor_conditions без ущерба общей производительности, т. к. включается на короткое время по запросу.

Если вызвать скрипт советника содержащий мониторы, то эти мониторы будут работать до окончания цикла

while I_InBattle 
end_while

В данном случае работает пока в битве.

Если вызвать на страт карте, например, с циклом I_TurnNumber < 5(или какой-нибудь счетчик), то мониторы из скрипта советника будут работать до пятого хода. И влиять на переход хода, само собой. Перезапуск/перезагрузка обнуляет эти мониторы. В риме1 такой метод используется в кампаниях. После каждой загрузки сейва происходит активация скриптов.

Но я делаю чуть иначе. например у меня есть монитор в скрипт файле кампании и я не хочу, чтоб он влиял на переход хода, то можно прописать вот так вот. По идее этот же монитор будет в файле советника, но он не влияет на время перехода хода(или влияет, но совсем чуть-чуть).

export_descr_advice.txt (Reveal)

;--- Скрипт пиратства ---
AdviceThread Pirate_Bonus_Thread
    GameArea Campaign

    Item test_1_Text_01
        Uninhibitable
        Verbosity  0
        Priority  6
        Threshold  1
        MaxRepeats  0
        RepeatInterval  1
        Attitude Normal
        Presentation Default
        Title test_1_Text_01_Title
        On_display scripts/raznoye/Pirate_Bonus.txt
        Text test_1_Text_01_Text1

Trigger Pirate_Bonus_Trigger
    WhenToTest PostBattle

    Condition FactionIsLocal
;		and I_EventCounter new_scripts = 1
		and I_ConflictType Naval
		and IsAdmiral
		and WasAttacker
		and WonBattle
		and BattleSuccess >= crushing

    AdviceThread Pirate_Bonus_Thread  1

Pirate_Bonus.txt (Reveal)

script
	declare_show_me
	
	generate_random_counter Pirate_Bonus 0 4

	if I_EventCounter Pirate_Bonus = 0
	historic_event Pirate_Bonus100
	console_command add_money 100
	end_if
	if I_EventCounter Pirate_Bonus = 1
	historic_event Pirate_Bonus200
	console_command add_money 200
	end_if
	if I_EventCounter Pirate_Bonus = 2
	historic_event Pirate_Bonus300
	console_command add_money 300
	end_if
	if I_EventCounter Pirate_Bonus = 3
	historic_event Pirate_Bonus400
	console_command add_money 400
	end_if
	if I_EventCounter Pirate_Bonus = 4
	historic_event Pirate_Bonus500
	console_command add_money 500
	end_if
	set_event_counter Pirate_Bonus 0
end_script

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

[bitterhowl]

[quote][В скрипт советника в целом достаточно безболезненно может включать значительное количество мониторов monitor_conditions без ущерба общей производительности, т. к. включается на короткое время по запросу.
/quote]в данном случае я именно про скрипт тактического ИИ имел в виду. Он выгружается из памяти после окончания битвы и производительность не страдает.

В остальных случаях конечно надо смотреть по ситуации - если большой скрипт советника в кампании на несколько ходов с большим количеством monitor_conditions то эффект для производительности будет негативным.

---

помимо этого, отдельно убрать Германикус полностью к советнику имеет смысл ещё и из-за большого количества счётчиков, которые он создаёт. Если они заданы в скрипте кампании, то будут постоянно занимать память, а при длительной игре именно ошибки записи в оперативку и приводят к вылетам.

[bitterhowl]

Видите, православные, что оптимизация животворящая с ИИ делает?

А ведь мы начали это дело намного раньше кетайцев, "украли чертежи" с ТВЦ. То ли ещё будет

[Master_TW_DAR]

Камрады, в процессе просмотра данного раздела появились интересные мысли. Хочу поделиться и заодно узнать, насколько, на Ваш взгляд, это реализуемо на практике.

Здесь собран громадный материал по написанию скриптов для моддинга любимой нами игры.
Конечно, затруднительно говорить об общем уровне качества опубликованных листингов кода - это слишком сложно.
Однако можно уверенно сказать, что для определенных разновидностей скриптов существуют более или менее похожие реализации.
Реализации, как правило, отличаются деталями данных от мода к моду, но лежащие в основе шаблоны относительно похожи друг на друга за исключением технических деталей конкретных скриптов.

Здесь на форуме принято называть совокупность подобных материалов "библиотекой скриптов".
Это вроде бы обычное название, но, как мне кажется, мы, модмейкеры, интуитивно понимаем, что это потенциальные материалы для повторного использования.
Для меня, как программиста, само понятие "библиотеки" в плане техническом есть нечто более глубокое, чем то, что описано выше.
Без заумных определений, просто скажу, что для меня "библиотека" прежде всего это набор полезных строительных блоков для программы.

И тут я подвожу к главной мысли - что, если среди всех существующих материалов отобрать наиболее качественные/проверенные/надежные/оптимизированные скрипты, максимально абстрагировать алгоритмы избранных скриптов, вынести специфические для конкретных модов игровые данные в отдельный формат описания, а затем с помощью какого-нибудь относительно простого скриптового языка наподобие JavaScript/Python/Lua создать строительные блоки типовых скриптов более высокого уровня, чем есть на данный момент.

По сути это в идеале привело бы к тому, что мододел писал бы быстро и просто нужный скрипт на любимом скриптовом языке и затем генерировал бы своё творение в формат скриптов Меди2. Отлаживать скрипты трудно и долго, особенно когда нет за плечами многолетнего опыта моддинга. Вместо того чтобы перелопачивать сотни страниц форума, мододелы-новички могли бы тем самым опереться на опыт ветеранов моддинга.

Это конечно всё звучит круто, но кто возьмется за реализацию всех озвученных идей ?
В перспективе мне было бы интересно заняться подобным делом - в рамках моего проекта OpenTWEMP (это не только про лаунчер модов).
Хотя в идеале есть желание найти здесь единомышленников и тех, кто будет готов помогать с тестированием потенциальных наработок.
Пока что я просто хочу прощупать "общественное мнение" по данному вопросу. Если интересно, обращайтесь, буду рад обсудить Ваши предложения.

[bitterhowl]

Master_TW_DAR 16 October 2025, 19:34

И тут я подвожу к главной мысли - что, если среди всех существующих материалов отобрать наиболее качественные/проверенные/надежные/оптимизированные скрипты, максимально абстрагировать алгоритмы избранных скриптов, вынести специфические для конкретных модов игровые данные в отдельный формат описания, а затем с помощью какого-нибудь относительно простого скриптового языка наподобие JavaScript/Python/Lua создать строительные блоки типовых скриптов более высокого уровня, чем есть на данный момент.

Я не программист и с другими языками не знаком. Есть ощущение, что скрипты Меди слишком частный случай для обобщения и создания упрощённой библиотеки.

Как человек, у которого несколько раз по разным причинам "сгорал" скрипт кампании, и приходилось его восстанавливать с нуля, могу сказать, что уже примерно знаю оптимальную структуру скрипта, его "скелет", на который удобно потом навешивать дополнения и "ветвления". Но не более того.

Сейчас для Myth TW с нуля пишу скрипт по этому принципу. После релиза можно будет посмотреть и обсудить структуру "скелета" на его примере.

[Master_TW_DAR]

Quote

Я не программист и с другими языками не знаком. Есть ощущение, что скрипты Меди слишком частный случай для обобщения и создания упрощённой библиотеки.

Игровые скрипты campaign_script.txt по своей сути построены на специализированном подмножестве языка Lua. Фактически скриптинг Меди 2 - это написание сценариев с использованием ориентированной на игровой геймплей библиотеки функций - тех самых, что задокументированы в таблице Docudemons. Наличие в дистрибутиве Меди 2 DLL-библиотеки Lua - косвенное тому подтверждение. И вероятно именно по этой причине проект EOP также ориентируется на создание уникальных скриптов как раз с помощью Lua. В общем, так или иначе Вас можно назвать программистом, который занимается созданием игровых сценариев на высокоуровневом скриптовом языке, а точнее - на предметно-ориентированном подмножестве языка Lua

Quote

Как человек, у которого несколько раз по разным причинам "сгорал" скрипт кампании, и приходилось его восстанавливать с нуля, могу сказать, что уже примерно знаю оптимальную структуру скрипта, его "скелет", на который удобно потом навешивать дополнения и "ветвления". Но не более того.

Вот-вот, отсюда и растут корни моей задумки. "Скелет" скрипта можно воспринимать как некий проектный примитив. Насколько я представляю, Ваш практический опыт сейчас достиг того самого уровня, когда в процессе написания скрипта мышление происходит в терминах абстрактных шаблонов тех или иных скриптовых конструкций, а не бессознательного копипаста отдельных скриптовых команд в надежде, что "работает там, значит, наверное, заработает и здесь". Значит, мы примерно схоже мыслим.

Quote

Сейчас для Myth TW с нуля пишу скрипт по этому принципу. После релиза можно будет посмотреть и обсудить структуру "скелета" на его примере.

Тогда у меня есть небольшое предложение - без присущего мне пафосного чарджа - начать с чего-то простого, в стиле "одобрите мои смелые начинания".

Сейчас ведете работу над Myth TW - замечательно, фокусируйтесь на том, что для Вас важно и интересно.
Затрудняюсь предположить сложность скрипта, над которым выполняется работа конкретно сейчас, однако опыт подсказывает, что если это что-то творческое, то непременно крупное и вероятно непростое.
По итогам создания скрипта появятся разного рода мысли: что можно улучшить, что больше всего раздражает, что осталось непонятно, как бы хотелось сделать в идеале и тому подобное.
Поделитесь всеми вышеуказанными соображениями и отправьте листинг скрипта - чтобы я со своей колокольни взглянул на код и поразмышлял над Вашими комментариями.
Далее я попробую набросать упрощенный вариант того же самого скрипта в каком-нибудь альтернативном формате (это необязательно скриптовый язык, это может быть даже, к примеру, XML-разметка).
Независимо от выбранного формата (их может быть несколько, в итоге же можно будет остановиться на наиболее понятном) моя потенциальная поделка будет генерировать код того же самого скрипта.

Если всё удастся, все будут довольны, то, возможно, кто-нибудь еще подтянется к этой инициативе. Вот, пока что это всё в плане мыслей на данную тему.