Stellaris

8.9
()

Дневник разработчиков Stellaris #204 - Язык скриптов и улучшения для моддинга

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

Сперва пробежимся по новым особенностям.

  • Шпионаж: моддеры могут добавлять новые операции, почти как археологические раскопки.
  • Первый контакт: всё по скриптам, так что моддеры могут менять большую часть этой системы. Однако все первые контакты теперь являются одной длинной цепочкой событий, поэтому перезапись может стать проблемой. К счастью, чтобы сгладить её, у нас появился новый эффект fire_on_action, который мы теперь кое-где используем.
  • Стать кризисом: особенности кода, например, интерфейс, целиком завязаны на скриптах. Поэтому в теории можно создать полностью новую систему какого-либо развития и достижения цели, если это будет нужно в моде.
  • Император и хранитель: эта особенность создана самым опытным контент-дизайнером студии. Вместе с ней добавилось множество сопутствующих улучшений скриптов, таких как повышенная гибкость резолюций Сообщества и возможность создавать флотилии федерации и Сообщества через скрипты.

Будет очень интересно посмотреть, что моддеры с этим сделают, но со времён выхода 2.8 мы сделали ещё очень много всего, так что...

Основные улучшения и стандартизация

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

Для будущего обновления мы уделили время, чтобы целостно взглянуть на картину и внести некоторые общие улучшения и стандартизацию.

Первым выиграло от этого то, что мы называем «скрипт-листами». Это система кода, которая создаёт объекты с припиской random/every/any/count из одного блока кода — так мы можем быть уверены, что построенный таким образом массив будет всегда одинаковым. То есть, что any_owned_pop будет проверять именно те поселения, на которых выполняется every_owned_pop. Мы их используем уже довольно давно, но для некоторых скоупов были совсем старые решения, которые появились ещё до скрипт-листов. По итогу возникали странности. Например, x_pop и x_planet порой делали совершенно разное, в зависимости от того, используешь every, random, any или count (при работе с разными скоупами иногда ссылки были на все объекты в игре, а иногда на те, что принадлежат текущему скоупу...). Самое неприятное — мы обнаружили, что any_ship ссылается на «все корабли в игре», и всё это время мы использовали его неправильно. А ещё бывало, что одна из версий (зачастую count) просто отсутствовала.

В новом патче почти все решения, придуманные до появления скрипт-листов, удалены и заменены скрипт-листами. В некоторых случаях мы использовали эту возможность, чтобы прояснить назначение скрипт-листа. Например, скрипт-лист planet теперь поделён на galaxy_planet и system_planet. (Это сломает некоторые моды, о чём я немного жалею, но не особо. Это определённо того стоило, и в списке изменений мы подробно укажем, что поменялось. В большинстве случаев пройтись автозаменой будет достаточно. Кроме того, из-за скрипт-листов немалое количество count_x триггеров потеряло букву S на конце, что несколько прискорбно с грамматической точки зрения). Также расширился функционал некоторых скрипт-листов, например, owned_pop, owned_planet и system_within_border теперь работают со скоупом сектора.

Ещё одна выбивавшаяся область, которую надо было улучшить — ссылки на скоупы в эффектах и триггерах, к примеру, create_pop = { species = <что-нибудь> }. Оказалось, что есть довольно большие расхождения в том, чем это <что-нибудь> может быть, в зависимости от эффекта или триггера. Иногда доступны были только расы, иногда расы, лидер, государство и поселение, иногда всё то же, но без поселений... А иногда мы даже использовали нечто под названием owner_main_species, которое работало только здесь (в отличие от owner_species, которое работало везде...). Решением было пройтись по каждому триггеру и эффекту и привести всё в единообразие, чтобы в каждом случае и во всех скриптах использовались одни и те же функции: расы, государства, планеты, лидеры и солнечные системы. Хватит терпеть, что нечто работает тут, но не работает там!

Благодаря этому мы также можем быть уверены, что ошибки всегда записываются правильно (и информативно), если в скриптах что-то пошло не так. (Примечание для моддеров, если кто-то не знает: лог ошибок можно найти в Documents/Paradox Interactive/Stellaris/logs/error.log). Сама запись ошибок тоже стала лучше по всему языку. Мы обновили множество сообщений об ошибках, которым не хватало важной информации (где лежит файл, например) — я как хранитель логов с наших ночных тестов лично отправился в крестовый поход против бесполезных сообщений об ошибках. Более того, мы исправили пугающее число случаев, когда что-то не работало, но не сообщало об этом, например, если в триггере что-то не так и он всегда будет возвращать false, или если в эффекте ошибка, из-за которой он ничего не будет делать. Не могу обещать, что такого больше никогда не повторится, но мы приложили немало усилий, чтобы избавиться от подобных случаев. Моддеры могут рассчитывать на то, что их лог ошибок заметно увеличится как при запуске игры, так и по ходу кампании. А ещё теперь нам легче исправлять баги скриптов, потому что большая их часть сразу всплывает в ночных тестах.

Переменные

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

В 2.8 с переменными можно было делать следующее:

  • сравнивать, приравнивать, добавлять, отнимать, делить или умножать переменную на число, другую переменную в той же скоупе, или ту же переменную из другого скоупа;
  • экспортировать различные настройки создания галактики в виде переменной;
  • использовать переменные в локализации, но если значение переменной было 0, то она отображалась в виде пробела, потому что очищалась;
  • использовать переменные в качестве параметра в некоторых случаях, например, как счётчик в эффекте while.

С тех пор мы многое усовершенствовали, и ещё есть планы на ближайшее будущее. В грядущем патче:

  • можно сравнивать, приравнивать, добавлять, отнимать, делить или умножать переменную ещё и на другую переменную из другого скоупа;
  • новые эффекты для получения остатка от деления (оператор %), округления вверх, вниз, и к ближайшему целому числу;
  • новый триггер check_variable_arithmetic проверяет значение переменной, если бы вы произвели с ней какие-то арифметические операции, например, умножили на другое число или переменную (работает для сложения, вычитания, умножения, деления и остатка от деления);
  • новые эффекты для экспорта различных игровых значений в переменные. За это отвечают: export_modifier_to_variable (check_modifier_value теперь тоже есть), export_resource_stockpile_to_variable и export_resource_income_to_variable;
  • add_modifier, add_resource, resource_stockpile_compare теперь имеют параметры mult, в которых принимается переменная. Так что теперь можно масштабировать стоимости в ресурсах и бонусы от эффектов при помощи переменной;
  • переменные больше не очищаются при значении 0, для этого появилась команда clear_variable, и их можно свободнее использовать в локализации;
  • в некоторых случаях использование переменных будет создавать запись в логе ошибок, если вы вдруг попытаетесь использовать переменную, не определив её.

Кроме того, мы начали обеспечивать возможность использовать переменные чаще. Суть в том, что мы хотим изменить принцп работы простых числовых эффектов и триггеров (т.е., тех, что принимают в качестве параметра число и не имеют фигурных скобок):

  • эффекты должны позволять вам использовать переменные, а также брать значение этих переменных;
  • триггеры также должны позволять вам использовать переменные, а также сравнивать себя со значением этих переменных;
  • триггеры должны позволять сравнение с другим скоупом, где они могли бы сработать. Таким образом, num_pops > from будет проверять, больше ли поселений в текущем объекте, чем в from.
  • должна быть возможность экспортировать текущее значение триггера в переменную при помощи эффекта, т.е. чтобы export_trigger_value_to_variable = { trigger = num_pops variable = my_var } записывало в my_var количество поселений в текущем скоупе.

К сожалению, эти изменения стали возможны только недавно, и хоть основу мы заложили, они ещё не полностью введены в игру — завершение работы над Nemesis и сопутствующим обновлением было более приоритетной задачей (эти изменения не безопасны, мы изменили многие строки кода ради них). Так что считайте этот дневник анонсом того, как код начнёт работать в (надеемся) ближайшем будущем. Пока же по описанному принципу будет работать триггер fleet_power, и export_trigger_value_to_variable тоже включён в обновление, хотя и работает только с этим триггером.

Эффекты кнопок

При разработке интерфейса мы прикрепляем функцию к кнопкам в исходном коде. Но есть также и поддержка кнопок интерфейса, которые вы можете добавить модами. В предыдущих версиях они не подхватывали скоуп объекта, к которому были прикреплены, поэтому кнопка у планеты применяла эффект для всего вашего государства, а не только лишь для планеты. Для ряда случаев мы это исправили: теперь кнопки способны распознавать, относятся ли они к планете, флотилии, кораблю, системе, фоновому объекту, мегасооружению, федерации, месту раскопок, месту первого контакта, агентурной сети или шпионской операции. И случайно так вышло, что консольные команды отладки, вроде «effect ...» и «trigger ...», теперь работают в тех же скоупах.

Уточнение: принцип работы этих эффектов не совсем честный, и систему можно ввести в заблуждение, открыв одновременно несколько окон. Я советую проверять строку is_scope_type = planet/что-нибудь в секциях allow и effect эффекта кнопки. Но, судя по всему, в большинстве случаев всё должно работать как надо, а это лучше, чем ничего.

Ещё больше приятных новинок

  • В большинстве мест, где ранее можно было использовать логические операторы >, >=, =<, <, теперь можно использовать != в значении «не равно».
  • Типы сообщений получили собственную директорию, поэтому моды могут добавлять новые типы, не переписывая весь файл (отличная новость для совместимости модов, к тому же мододелы теперь смогут добавлять улучшения качества жизни, не мешая друг другу).
  • Сообщения, вызываемые эффектом create_message, теперь поддерживают использование команд локализаций, например [This.GetName], где This является целью сообщения.
  • А ещё из-за того, что нам много где пришлось исправлять Галактическое сообщество на Империум, переменные локализации теперь работают в некоторых новых местах.
  • Добавлены эффекты add_victory_score = <число> и win = yes. Уверен, никто не станет ими злоупотреблять.
  • Добавлены новые типы событий: leader_event, system_event, starbase_event, first_contact_event и espionage_operation_event. Однако среднее время срабатывания (MTTH) для них пока не работает. Исправление этого упущения не было для нас приоритетным, да и в целом лучше избегать использования MTTH.
  • Прописанное в коде поведение джаггернаута теперь привязано к размеру корабля, являющегося мобильной космической базой, а не к ключу juggernaut. То есть теперь можно добавлять джаггернауты в модах, и они не будут страдать от критических ошибок.
  • Теперь можно скрывать статичные модификаторы из списка модификаторов государства.
  • Теперь можно проверять расстояние до объектов в пределах одной солнечной системы, добавив к триггеру расстояния строку same_system = yes.
  • Появилось много новых on_action, и вы теперь можете делать свои с помощью эффекта fire_on_action.
  • И многое другое

И последнее на сегодня: я оставлю вам новую документацию по триггерам (по состоянию на сегодня), которые теперь можно найти в отдельном файле trigger_docs.log. В представлении они не нуждаются. Кроме того, не пропустите Paradox Insider, который пройдёт в эту субботу в 22:00 МСК на канале TwitchGamming.

Оригинал на английском

ПК
10
Источник
ЕЩЁ ПО ТЕМЕ
Ваш комментарий
Комментарии: 0