Свой мод я так и не выложила (его ещё пересоздавать надо из-за нового ДЛС, вот ведь засада), но сведений накопилось столько, что пора бы их уже народу показать. Кому-нибудь, думаю, пригодится.

Я принципиально не повторяю того, что есть в Modding Instructions.pdf, кроме самых общих понятий, без которых о модостроительстве не расскажешь. За деталями – в инструкцию, она лежит в корне игры и любой сможет её прочитать. Кто не сможет на английском – вот перевод, сделанный пользователем Mandarin. А у меня тут будут детали, которых в инструкции нет.

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

В первую очередь создаём сценарий (ладно, в первую очередь открываем Storyteller.exe и создаём мод, но с этим, полагаю, любой справится и без моих советов).


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



Ну что, не запутались? ;) В свойствах сценария есть несколько параметров (Dweller set name, Timeline names и т.д.), каждый из них указывает на соответствующий раздел (зелёным цветом написан путь к этому разделу). Пробелы я добавила для лучшей читаемости. В редакторе не Shelter attack rule set name, а ShelterAttackRuleSetName, к примеру.

Нас интересуют:

Complication tier – сложность сценария. Ставим 0, чтобы он был доступен сразу. Кстати, можно поставить сложность 10000 остальным сценариям, чтобы для выбора был доступен только ваш. Через сколько прохождений какая сложность вступает в силу, задаётся в MainConfig, но о MainConfig я расскажу отдельно.

Важно! Ваш сценарий не будет виден, если оригинальных (без учёта ДЛС) больше 13, увеличение их общего количества в Scenarios config –> Classic Scenarios Count не поможет, как и манипуляции со сложностью Complication tier. Надёжнее всего заменить вашим сценарием любой из оригинальных (кроме ДЛС-овских); если хотите оставить оригинальный для себя в редакторе – скопируйте его через дублирование, а оригинал превращайте в свой. Ну или поудаляйте все старые (кроме ДЛС-овских!), но это менее надёжно. Если что-то всё-таки пойдёт не так, закройте редактор и снова откройте. Возможно, вы увидите там совсем не те сценарии, которые он показывал до закрытия. При удалении или дублировании сценариев его иногда клинит, даже если нет сообщений об ошибках.

Texture name – название картинки сценария в формате .dds, которая лежит в_папке_с_модом/textures/UI/select/ (адрес указывается, начиная с UI)

Dweller set name – название набора персонажей, который создаём по адресу Scenarios config –> Dweller sets

Home scene name – локация нашего убежища. Если оставить поле пустым, будет выбрана случайно.

Location pack name – имя набора локаций для ночных похождений (из Scavenge locations config –> Location packs). Если оставить пустым, выберется любой из подходящих по Complication tier.

Shelter setup name – стартовое состояние персонажей и всё, что связано с убежищем (Scenarios config –> Shelter setups)

Timeline names – наборы событий (Scenarios config –> Timelines). Их для одного сценария можно задать несколько, поэтому добавляются они через очень глючную менюшку.

Самый главный глюк таких списков – их лучше не копировать через Duplicate, даже если редактор не против. Это может вызвать ошибку, после которой (!!!) работу в редакторе нельзя продолжать и сохранять, в моде может что-нибудь непредсказуемо втихаря отвалиться. У меня, например, заглючили цены в таймлайне, причём заглючили капитально, создание их заново не помогло. И один предмет не отображался в игре – опять-таки, не помогало его пересоздание.

Безопасный способ копирования – нажимаем слева на уровень выше интересующего нас объекта, раскрываем его справа, нажимаем правой кнопкой мыши, выбираем Duplicate Item, если доступно. Подробнее покажу на примере радио, сейчас – о добавлении вручную.

Щёлкаем по полю, справа появляется многоточие, жмём на него, попадаем в менюшку, жмём на «Добавить» слева, заполняем Value справа. Для примера я создала сценарий Test с двумя таймлайнами:




Здесь можно указать только стартовый состав группы и текст в начале первого дня, который расскажет, как они дошли до жизни такой. Эти тексты лежат в Localization strings –> Daily log –> Strings, можно добавить свой или выбрать нейтральный IntroMessage или IntroMessageScenarioEditor.



Список персонажей есть в официальном руководстве. Их стартовое состояние задаётся, как ни странно, не здесь, а в Scenarios config –> Shelter setups.


Карта убежища задаётся в поле Home scene name сценария. Их две:
!CURRENT/0_home_shelter_nu3 – городская (с надписью «F*ck the war!»)
!CURRENT/0_home_shelter_B – пригород.

С последним патчем добавилась радиостанция из ДЛС: !CURRENT/0_home_shelter_radiostation – очень неудобная; как и во всех сюжетных, слишком много мест, куда нельзя ставить мебель, потому что на фоне что-то нарисовано.
Апд.: Ещё мы с toomanynights недавно выяснили, что один из шкафов в этом убежище (справа на чердаке над комнатой с радио) содержит фиксированный лут – 1 овощи и 2 мяса – который добавляется, не считаясь с тем, что задано в настройках убежища для сценария. Даже если там задано ноль еды, например.

Можно насильно взять убежище из ДЛС:
!CURRENT/WAR_STORY_1/0_home_shelter_tenement_house
!CURRENT/WAR_STORY_2/0_home_shelter_radiostation (см. выше)
!CURRENT/WAR_STORY_3/00a_shelter_anja_house
!CURRENT/WAR_STORY_3/00b_shelter_museum
…Но, честно говоря, в этом мало смысла. Их карты слишком малы и напичканы сюжетными объектами типа рисунков Амелии и экспонатов музея.

В Shelter setups прописываем стартовые повреждения персонажей (Sick, Wounded или Tired, можно и Hungry) – либо оставляем их всех здоровыми. Повреждения будут раскиданы между ними случайно, каждому достанется ОДНА строчка. Если строк больше, чем персонажей, использованы будут только первые.

И ещё два важных параметра Shelter setups:

Loot generator name – предметы, раскиданные по шкафам и кучкам в убежище (Loot generator config)

Scene setup name – настройки карты убежища. Этот параметр отвечает, насколько я увидела, только за наличие уже готовой мебели и, возможно, количество куч и шкафов:

• Basic, BadBandits, Bandits, Thiefs – старый добрый стул
  
• Winter_Builders, Winter_Thiefs – печка и стул
  
• Kids_Winter – печка, стула нет
  
• Kids, OrdinaryPeople – ни печки, ни стула
  
• OldCouple – 2 кровати, стул, кресло (ТОЛЬКО в деревенском доме !CURRENT/0_home_shelter_B с недавних пор есть в обоих вариантах)
  
• FullWypas – тестовый вариант с кучей всего и почему-то двумя базовыми верстаками

Один из персонажей на старте слегка болен, второй сильно устал, третий здоров. У них есть печка и стул:



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

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

Ведут в другие разделы:

• Shelter attack rule set name – ночные атаки на убежище
  (Scenarios config –> Shelter attack config –> Attack rules)
  
• Visits group name – дневные визиты в убежище: торговец, квесты и новые жители
  (Visits config –> Visit groups)
  
• Winter config entry name – погода, то есть температура воздуха в убежище без отопления (Winter config). Дни, закрытые из-за морозов, на самом деле задаются именно здесь.
  
• …и чёртово радио, которое не задаётся явным образом, а потому нельзя попросту сослаться на уже существующие сеты и приходится создавать для каждого таймлайна новые.

Непосредственно в таймлайне:

• Major event config – события, объявления о которых выводятся в начале дня (преступность и морозы). На самом деле это ТОЛЬКО объявления, сами события – в Attack rules и Winter config.
  
• Blocked locations – даты закрытия локаций боями. Вот тут без обмана, они и правда заданы именно здесь.
  
• War duration in days – количество дней до окончания войны.
  
• Item price def – скачки цен.
  
• Vanish items – то, как быстро начнут пропадать на локациях разные вещи.
  
• Debug visits – вообще визиты в игре рандомны, но если нужно установить какие-то с гарантией, то это наш параметр.

Самый простой способ со всем этим разобраться – копировать уже существующее и менять только то, что нужно. Можно и таймлайны поставить из оригинальных сценариев, если они вас устраивают.

А теперь подробности.


В Major event config задаются только красивые объявления и картинки, с которых начинаются дни. Это означает не только то, что их надо сверять с Attack rules и Winter config, но и то, что их можно попросту заменить на свои (поменяв им надписи и текстуры в Scenarios config –> Major events definitions) и создать таким образом совсем другие события (бои, жару, Новый год, да что угодно). Единственное ограничение – их количество не может быть больше пяти.

С Blocked locations всё просто: какие дни выставите, в такие и будет закрыта часть локаций. Впрочем, и это могут быть не бои, если изменить текст в Localization strings –> UI –> Scavenge –> notDuringFights.

В Final cut появилась альтернативная блокировка локаций, в время которой нельзя покинуть убежище вообще (как бомбёжки в сценарии с музеем): поле Selective locations blocking entry def таймлайна. Мжно задать количество дней блокировки, но вряд ли стоит больше одного за раз.


Вот уж что в большинстве случаев можно взять готовое из существующего сценария (главное – не забудьте, что в Major event config всплеском преступности должен называться период самых жёстких атак).

За одним исключением: если нужно в какой-то период защитить определённые предметы в убежище от грабителей. У каждой атаки есть почти-скрытый параметр No Stealable Items, о котором не написано в официальном руководстве. Он не раскрывается в левой части редактора, вписать в него что-то можно только справа (войдя в String[0], как на скриншоте с добавлением тестовых таймлайнов). Вот он, подсвечен:




Игра знает 4 типа визитов: квест, кандидат в жильцы, торговец и помощь (это когда не мы идём помогать, а нам что-то дарят – например, GiveWood или MedsForAnna). У квестов приоритет самый высокий, у помощи самый низкий. Сменить расстановку приоритетов можно в Visits config –> Visit types, создать свой набор визитов – в Visits config –> Visit groups.

Для каждого визита мы задаём временной период, в который он может произойти, но это не значит, что он действительно произойдёт (гарантию даёт только DebugVisits таймлайна). Но мы однозначно можем запретить ненужные события, поставив им ValidFromDay=100.

Fixed Days After Pass Requirme – задаёт повторение того же самого события. А вовсе не продолжение его сюжетной линии, как можно подумать. Так что на квестовые визиты его ставить нельзя – иначе, например, дети будут приходить за таблетками раз за разом.

И это не единственная глупость, которую я успела сделать в своём моде. Ещё я разрешила почти всем потенциальным жильцам приходить до конца игры, понадеявшись на Main config –> Dweller cap. Я всё ещё думаю, что этот параметр должен ограничивать их максимальное количество, но по какой-то причине он не действует. Ближе к финалу игра спохватилась, что не все же ещё пристроены, надо успеть их приткнуть! И желающие повалили толпами, каждый день по кандидату, пришлось их начать посылать. В убежище жило уже человек десять…

Видимо, игра группирует визитёров по времени возможного появления. Допустим, у вас одни визиты в дни 3-15, другие в 16-30, третьи 31-45 – игра будет выбирать сначала из первой группы, потом из второй… и не собьётся. Но если один новичок приходит в 4-10, второй в 7-13, третий в 8-16… это разные группы, игра считает своим долгом реализовать хоть что-то из каждой. Вот и разгадка толп зомби постояльцев.

В Visits config –> Joining dwellers initial states задаётся уровень контуженности новоприбывших в зависимости от количества дней, прошедших с начала игры. Как и приоритеты в Visit types, это распространяется на все сценарии.

Не вместилось в предыдущий раздел…


Непосредственно в свойствах Winter config (нажимаем на Winter config слева, смотрим на правую часть редактора) есть два любопытных параметра: Winter effects starts at и Winter starts at. Первый задаёт температуру чисто визуальных эффектов зимы (локации выглядят снежными), второй – температуру, при которой блокируются снегом локации, замерзает коллектор воды, появляется снеговик и опция копания снега у входа в убежище.

Поставив, например, Winter starts at = -5, можно перекрыть локации только на часть зимы, что я и сделала в своём моде (у меня там почти всё время зима). Увы, но добыча воды при этом начинает выглядеть странновато.

Ещё несколько важных для зимы параметров находятся в Sick and heat config:

Freezing Temp – температура, при которой персонажи могут замёрзнуть насмерть.

Heat Coefficient – то, насколько сильно нагревает воздух печка. Сделав это значение отрицательным, можно превратить её в кондиционер. Правда, модельку (Shelter item -> Shelter item name в свойствах предмета) поменять не получится, к ней привязаны скрипты его работы.

Optimum Temp – максимально возможная температура в убежище. Погодные изменения в Winter config не смогут превысить её.
Похоже, участвует в расчётах болезней персонажей. Если её увеличить, они простывают при более высоких температурах и чаще.

Shelter heat UI cap (Main config –> (Прочее) –> Shelter heat UI cap) должен ограничивать максимальную температуру при подбрасывании дров в обогреватель, но на деле ограничивает температуру сверху, даже если обогреватель не задействован (до Shelter heat UI cap минус 1). Вы не сможете задать жару выше 23°C, пока не измените это значение. Но и прогреть комнату выше Optimum Temp не удастся.
Ну а чё, столько модов This War of Mine про жестокую зиму и ни одного про жестокое тропическое лето…

Осталось всего ничего – создать всё-таки сет погоды для мода, но думаю, что с этим вы и без меня прекрасно справитесь ;)


Всего в игре три радиостанции:

• Important – столичная, рассказывает о самых важных событиях: ходе конфликта, росте преступности и положении в городе в целом
  
• Trivia – местные новости, в основном о ценах
  
• Weather – погода

Посмотреть тексты сообщений можно в Localization strings –> Radio.

У каждой радиостанции есть набор сообщений для каждого таймлайна. Значит, у тестового сценария должно быть:
Radio config –> Important –> Test_Timeline1
Radio config –> Important –> Test_Timeline2
То же для Trivia, Weather, Music и MusicVaria.

Теперь обещанное о том, как копировать радиособытия для таймлайнов через Duplicate. Нажав на Important слева, раскрываем его список Timelines справа:



Затем выбираем нужный таймлайн и копируем его через Duplicate Item. Если попытаться скопировать тем же способом, но в левой части редактора, он выдаст ошибку.



Ничто не мешает создать свою радиостанцию. Единственное, что для этого нужно – немного сократить частоты Trivia и Weather, чтобы освободить небольшое окно между 0.3 и 0.45, куда мы и воткнём её.

В Loot generator config указываются предметы, которые будут сгенерированы в локациях на старте игры. Это один из способов добавить на них новый предмет, но есть куда более простой и быстрый – поставить ему в свойства один из генераторов лута, которые уже записаны во всяких LootGen_Map(…). Но о работе генераторов чуть позже.

Указание отдельных предметов в FixedPool позволяет регулировать их количество – в том числе и запретить добавлять их вовсе, если выставить ноль. Так в локации «Ветхая трущоба» запрещена к генерации любая еда.

На скрине видно, как задана работа генератора лекарств:



Сеты локаций, которые выпадают на старте, задаются в Scavenge locations config –> Location packs.

Можно не вписывать туда ничего и отдаться во власть рандома, можно сделать для своего сценария личный набор локаций и вписать его в Location pack name сценария, тогда каждый раз будет выпадать именно он.

А можно насоздавать для рандома свои наборы и запретить стандартные, вписав в их сложность Complication tier что-то вроде 100000. В этом случае нужно убрать из доступа пользователей галочку Anniversary edition. (Если она включена, игра попытается найти один из стандартных паков, известных ей как содержащие локации из расширенного издания, не найдёт ни одного и начнётся без единого доступного для посещения места.) Но убрать её невозможно средствами редактора. Самое меньшее, что можно сделать – заменить текст Localization strings –> UI –> ForceNewContent и ForceNewContentPopUp на предупреждение («Не нажимайте ни в коем случае!»).

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


И новенькие из финальной версии (переделанные ДЛСшные):



– раздел, в свойствах которого закопано много полезного.

Dweller cap уже упоминался. Предположительно, отвечает за максимальное количество приходящих в убежище новых жильцов, но как-то он плохо за это отвечает.

Про Shelter heat UI cap тоже было сказано. Возможность сделать жару (и перенастроить игру так, чтобы персонажи от неё страдали, например, медленнее работали) очень интересная. Особенно если удастся превратить обогреватель в кондиционер на батарейках. Но для этого нужно очень хорошо уметь редакровать внутренние файлы игры, куда лучше, чем я.

Intro sequence – тут можно убрать заставки, показываемые при запуске игры, присвоив им, например, Enable only on platform = PS.

Раздел Day and night – продолжительность суток (если увеличить её, персонажи будут всё делать ме-е-дленнее, так как время каждого действия задано в часах), время начала дня, конца дня и конца ночи.
Day begin hour – начало дня, Day end hour – конец дня.
Время начала ночной вылазки строго фиксировано (8 часов) и зависит от времени её конца Night end hour (вот его можно задать). SkipHoursOnEndDay отвечает за что-то другое.

MainConfig –> GameConfig –> Complication Tier Max Games Played – вот они, уровни сложности ComplicationTier. Тут можно переопределить, какое количество прохождений какому ComplicationTier соответствует.

Здесь же, в GameConfig, есть Home scene names – карты убежища, случайно выпадающие на старте. Если вы хотите оставить только одну или нашли, как их редактировать, и можете вставить новую, – это сюда.




Trading config – здесь можно изменить ассортимент у торговцев.
BasicTrader – торговец, приходящий в дом.

Emotion config – управление настроением.
Самое важное про настроение: отрицательные значения его улучшают (уменьшается депрессия), положительные ухудшают.

В Archetypes config –> Dweller_Generic (Dweller_Kid для детей) –> Components –> Kosovo emotional component config хранятся значения, при которых наступает каждый уровень настроения.

А в самом Emotion config расписано, как на него влияют квесты (Events data), подбадривание (Depression change on cheer), при каких значениях депрессии персонажи вредят себе или другим (Trauma effects).

Самое важное, о чём следует помнить – вам не удастся создать активный предмет (оружие, ножовки, отмычки) без ручной редактуры ресурсов, результаты которой вы ещё и не сможете вшить в свой мод. Увы.

Исключение – то, что употребляется как результат крафта прямо с верстака. Новую еду сделать можно. Но и она не будет доступна для заботы о раненом или ребёнке, придётся им ножками топать к плите. Опять-таки – если вы не пороетесь в файлах игры и не подредактируете скрипты. Но о редактировании файлов позже.

Создание предметов и рецептов описано в официальном руководстве, не буду повторяться. Только немного нюансов:

Inventory item в свойствах предмета задаёт раздел инвентаря, в котором этот предмет будет отображаться. Обратите внимание, что "Другое" с меткой Other и "Другое", которое вообще без метки – это две разные категории в инвентаре.

Shelter item –> Shelter item name – моделька, отображающаяся в игре (для стоящих в убежище вещей).

Item influences (а также Shelter item –> Param modifiers) – накладываемые эффекты. Их легко копировать с других предметов. Вот, например, выпечка, которая не только насыщает, но и повышает настроение по образцу детских игрушек:



Item – самый важный раздел. Тут и текстура (не забудьте, что текстурина для результата крафта, висящего снаружи верстака, своя и задаётся не здесь, а в Crafting предмета), и ссылка на текстовое название в Localization strings, и прочность (HP), и стоимость (Value), и даже звук при взятии.

А также загадочное Tags и ещё более загадочное Min loot location group. Оба они задают случайное выпадение предмета на локации, но как работает Min loot location group, я не поняла.

Item –> Tags – незаменимейшая вещь, если вы не хотите распихивать новый предмет по локациям вручную. Осталось разобраться, что значат эти теги.



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

Наполнение локаций предметами задаётся в Loot Generators Config -> LootGen_Map*** (или LootGenHome_***, если речь об убежище).


Теги локаций выводятся в их описании на карте (например, «Много оружия», «Немного еды»). Предметы с этими тегами будут посчитаны в свою категорию, предметы без них не отобразятся в описании никак.

Дальше пойдут предположения. За небольшим исключением (несколько предметов мне удалось найти в \templates\helperobjects\loot) я вычисляла, что где возникает, собирая статистику во время игры.


Важно! Сами по себе теги контейнеров не создают предметы, они просто говорят, в каком ящике этот предмет может оказаться, если он задан в FixedPool локации или в генераторе. Каждому контейнеру в игре может соответствовать несколько тегов; как и каждому предмету – несколько тегов контейнеров и тегов генераторов.

К примеру, вы хотите положить лопату или ломик в убежище на старте. Если не привязать к ним теги, они могут оказаться где угодно, от куч до закрытый сейфов, что нежелательно. Но если приписать их к Container_Furniture – появятся в столе либо открытом деревянном шкафу, и только если их на локации не будет, включится вариант «где угодно».


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

Дальше – снова догадки:


Стройматериалы, пули и разные детальки из генераторов, начинающихся на «Timeline_», повторю, разбросаны по всем контейнерам и локациями, я просто не стала их все вписывать в каждую строку. К слову, именно генераторы задаются в Vanish items таймлайнов для постепенного исчезновения вещей с локаций.

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



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

Пример, чтобы показать, как работают генераторы.
Я захотела убрать сахар из локации «Ветхая трущоба» (ну потому что странно, что голодающие не съели его только потому, что игра не считает его едой).

Для этого нужно в Loot Generators Config -> LootGen_Map04 -> FixedPool убрать один из генераторов – LootGenerator_TraderBasic (где как раз сахар); я заменила его на LootGenerator_Trader. Кроме того, я добавила в тот же FixedPool Sugar со значением 0 (по образцу мяса и консервов, которые там тоже с нулём стоят).

Тем, кто собирается добавлять их в мод, следует знать несколько вещей.

1) В некоторых случаях новые тексты добавить невозможно. Если какой-то параметр ссылается не на явно заданные строки в Localization strings, а на теги (как диалог обучения ребёнка), добавление нового диалога ничего не изменит, игра не посчитает его таким же тегом. Описание тегов зашито в недра игры, до которых не добраться обычным путём. Впрочем, я добавила у себя два события Major event config в файлик MetaData.xml в корне игры; это позволило сделать больше событий в сценариях, которые остались в них даже после возвращения оригинального MetaData.xml (просто без названия). Но многие конфигурационные файлы лежат в dat-архивах, которые не так-то просто вскрыть.

И по загадочной причине нельзя добавить новый набор реплик для нажатия на работающее устройство типа коллектора воды или ловушки (SpeechesItems/ItemWorking/…), хотя в свойствах предмета прописывается ссылка на строку.

2) Игра знает, что у персонажей есть пол, и это отражается на текстах (всё-таки поляки делали), но, увы, все имена должны быть в именительном падеже (винительный не со всеми именами прокатывает).

{ms|Я мужчина}{fs|Я женщина} – кто говорит эту реплику
{mr|Он мужчина}{fr|Она женщина} – о ком в ней речь

(s – speaker, r – responder; m – male, f – female)
^CharacterName^ – имя персонажа, о котором говорят.

Пример: «Я рад{ms|}{fs|а}, что ^CharacterName^ помог{mr|}{fr|ла} пациентам больницы».

^OtherCharacterName^ – используется только в биографических записях детей для обозначения человека, который этого ребёнка опекает (^CharacterName^ в них – сам ребёнок). Если его не было изначально (или погиб), через какое-то время будет выбран тот, кто больше всего с ребёнком возится.
Пример: «{mr|Обеспокоенный}{fr|Обеспокоенная} благополучием Искры, ^OtherCharacterName^ {mr|решил}{fr|решила}, что лучше покинуть убежище и попросить помощи в другом месте» – имя ребёнка можно не заменять переменной, чтобы не мучиться с падежами; всё-таки это тот, в чьей биографии лежит эта запись. А вот ^OtherCharacterName^ может быть любым взрослым играбельным персонажем.

Кстати, таких временных опекунов дети называют не по имени, вместо ^CharacterName^ они начинают подставлять в своих диалогах Localization strings –> Names –> Male_Protector или Female_Protector («Дядя» или «Тетя»), поэтому ^CharacterName^ в их репликах должно стоять не только в именительном падеже, но и в начале предложения, чтобы оправдать заглавную букву.

Вот такие трудности перевода.

3) И последнее. Если беда пришла в ваш аул вы потеряли тексты своего мода при переносе его в новый после выхода дополнения (это сделать необходимо, иначе мод не запустится), нет ничего проще. Создайте в Localization strings строки с нужными названиями там, где они были, и оставьте пустыми. Сохраните и закройте мод. Затем (НЕ РАНЬШЕ!) скопируйте в папку localizations нового мода свои старые файлы локализации, т.е. файлы вида язык_номер-вашего-мода (например, russian_f35ece6b4bc143dd93cc63bcf2d5e0a0.lang), переименуйте под новый мод – и можно его открывать, строки будут заполнены.

4) ...Нет, не последнее. Я узнала, как перекодировать содержимое кириллического файла локализации, чтобы искать по всему файлу при необходимости. Кодировки ASCII-8bit -> UTF-16LE. По крайней мере, на этом сайте[www.online-decoder.com] работает, но он большие объёмы текста не переваривает.

Подумав, добавлю эту информацию в уже созданное руководство, она не помешает.

Всего в игре четыре типа характера (эгоист, альтруист, выживальщик и… как бы перевести Homie? по словарю – что-то типа «свой парень», но по поведению в игре ближе всего «конформист»), отвечающие за реакцию на события, изменение морали и сообщения об этом в дневнике. Кроме того, у каждого есть дополнительный флаг, вероятно, отражающий возможные изменения в их характере: у одних апатия, у других бесчувственность, у третьих агрессивность.

Возможные варианты (взято из текстов дневника):

• Altruistic (альтруист): Apathic
  
• Egoist (эгоист): Aggresive, Insensitive
  
• Homie (конформист): Apathic, Insensitive
  
• Survivalist (выживальщик): Insensitive
  
• Kid (ребёнок): Aggresive, Apathic

Ни одному ребёнку дополнительные особенности характера не заданы, все тупо Kid. Возможно, им доступны оба варианта (Aggresive и Apathic), в зависимости от стиля прохождения игрока?

С текстурами всё очевидно (кроме одного: распаковав текстуры при создании мода, удалите все лишние, иначе они так и будут паковаться в мод, замедлять его компиляцию и увеличивать вес), поэтому просто перечислю текстуры, которыми красятся модельки персонажей.

Они все лежат в \textures\meshes\, но некоторые в подпапках, а некоторые просто в корне meshes. Если папка не указана, ищите там. В квадратных скобках указан номер в текстуре из нескольких картинок, начиная с 1 (например, lower_02_diff [07] - левый нижний угол).

С большим трудом, но мне удалось-таки добыть инструменты для распаковки и запаковки DAT-файлов: https://forum.xentax.com/viewtopic.php?f=10&t=11378
Пришлось на английском просить у автора перезалить, а потом несколько месяцев ждать ответа. Но он всё-таки это сделал, не очень торопился, это да :) Всё равно спасибо. Правда, запаковщик не скачивается без регистрации на форуме, а ссылка на распаковщик может опять пропасть. Так что залью-ка я копию на яндекс-диск на всякий случай: https://yadi.sk/d/VBSZrDdV5mCeDQ

Содержимое папок BSUnpacker_0.0.4.r7 и BSPacker_0.0.2.r3 нужно распаковать в корень игры, дальше всё вполне понятно. Запускайте и пользуйтесь. Не пугайтесь папки __Unknown, этих файлов просто не было в списке FileNames распаковочной программки (видимо, новые – от ДЛС-ок, например), но она их без проблем запакует обратно, даже отредактированные, если отредактированы правильно. И всё-таки на всякий случай сделайте бэкапы DAT-архивов.

И самое главное: в моды вся эта красота не пойдёт (кинуть распакованное в папку с модом не прокатит, я проверяла). А если очень хочется, то придётся просить игроков, ставящих мод, заодно скачивать себе и кидать в корень игры ваш новый common.dat, к примеру. И работать оно, конечно, будет только до первого обновления. В общем, думайте сами, решайте сами, надо оно вам или нет.

Распакованные файлы я бы условно поделила на два типа: скрипты lua, которые легко можно редактировать, и остальные файлы, с которыми увы. Скрипты можно открывать и сохранять любым блокнотом (но специализированным, типа Notepad++, это просто удобней). А вот те, с которыми увы, отображаются в блокнотах с кракозябрами и после сохранения в этих самых блокнотах игра отказывается иметь с ними дело и вообще работать. Даже в HEX-редакторах (кто о них вспомнил – ещё раз увы, я вас разочарую) можно только заменить информацию посимвольно, добавление новой убивает файл.

Поэтому дать в руки персонажам новый инструмент вроде топора или отмычки по-прежнему не получается. Возможно, получится у кого-то другого (кто научится редактировать эти гадские файлы, потому что где-то в них закопан список инструментов, в отличие от списков оружия и еды, которые есть прямо в моде). Вот еда и алкоголь – другое дело, с ними можно кой-чего замутить через скрипты)…


…А для нового оружия даже скрипты, как выяснилось, не нужны. Достаточно добавить его в списки в настройках Main config:

Combat –> Dweller Weapons – чтобы взять его в руки в ночной вылазке;

и Night Jobs _Guard –> Defense Weapons / Night Jobs _Guard –> Defense Melee Weapons (для дальнего или ближнего боя соответственно) – чтобы им пользовались дежурящие ночью в убежище.

Ну то есть, если вы тупо скопируете лом и впишете в оба списка, он будет нормально работать как дубинка, но не будет вскрывать замки.


Мелочь? Но приятная. Меня напрягало, что деда Хенрика дети называют «дедушка», а деда Антона почему-то «дядя».

Заодно пусть будет примером работы с HEX-редактором.

Имя защитника зашито в личные файлы персонажей (которые лежат \templates\characters\player_characters, и, разумеется, они из не поддающихся редактуре). Чаще всего это Male_Protector или Female_Protector из Localization strings –> Names, но у тех, кто стартует с ребёнком, есть специальные имена: Christo_Protector, Henrik_Protector… во, этот-то нам и нужен.

Вставить его напрямую в файл Антона не выйдет, поскольку в Henrik и Male – очевидно разное количество букв, а нам нужно заменить одно другим. Так что создаём имя Anto_Protector, копируем в него содержимое Henrik_Protector на всех языках… а затем открываем \templates\characters\player_characters\dweller_mathematician.binarytemplate любым HEX-редактором и аккуратненько, вручную, а не копипастом, заменяем Male на Anto.



Теперь запаковываем обратно папку templates при помощи BSPacker.exe и наслаждаемся результатом. Если в результате игра вылетает – значит, заменили как-то не так, у меня не с первого раза получилось. Либо что-то ещё в templates изменить успели.



Ну да, здесь тётя Света, а не дедушка Антон, я на ней это дело тестировала, с ней и скриншот сделала.


С ним оказалось куда проще, чем с едой. Но в обоих случаях понадобится common.dat.

А точнее, файлы itemactionbindingconfig.lua и resourcedisposer.lua в \common\scripts\items\. Для алкоголя – только второй из них.



Нужно найти строки с перечислением всех предметов, которые игра считает алкоголем (оно же пьётся из одного меню, что спирт, что самогон), и добавить туда свой. Таких списков в файле должно быть два.


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

Так что придётся идти трудным путём: искать в обоих файлах каждое упоминание CookedFood и вставлять рядом такой же кусок кода, заменив "CookedFood" на своё (в моём случае – на "SpicedFood").

Например, так:


Или так (иконку, разумеется, тоже заменить):


И не забудьте про текстуры иконок в конце resourcedisposer.lua



Поставила вторую плиту с обычной едой, чтобы в меню (двусмысленно получилось… меню с содержимым меню, во) попали обе тарелки.

Но и это не всё! Иконка еды теперь появилась над персонажем, и даже кормление происходит, но при этом они стоят, как истуканы. Чтобы запустились анимация и диалог кормления, нужно добавить название еды в список предметов для ухода за детьми и больными. Он есть в EmotionalConfig –> Other –> Help Dweller Settings редактора мода, только редактор не позволяет ничего сюда внести, вылетает. (Возможно, потому что одного этого недостаточно, пользователь же должен ещё и скрипты править, чего он делать, по-хорошему, не должен… потому и правку списка отрезали, наверное.)

Жестом фокусника открываем блокнотом файл EmotionalInfluenceConfig.xml в папке своего мода (который, естественно, не должен быть открыт в редакторе в этот момент), ищем строчку <Prop Name="Help Dweller Settings">, добавляем к списку предметов свой, сохраняем – и вуаля! Что по-французски означает «Мы победили этот вредный редактор модов».

Йес! Способ не только выдернуть из игры файлы, но и запихать их обратно в мод, – найден!

Только для этого нужен другой распаковщик (который делали для Фростпанка), он не имеет заданного списка файлов и не придаёт им приличный понятный вид при распаковке, а просто кидает всё как есть в папку с названием архива, без нормальных имён, расширений и папок. Зато он безотказный и работает со всем, что дают, это и не распаковщик как таковой, а просто два питоновских скрипта, умеющих работать с такими архивами.

…И да, это значит, что придётся установить Python. Гугл вам в помощь, он лежит на своём официальном сайте, бесплатный и мало весит.

А «распаковщик» вот: https://yadi.sk/d/ISyTGl26E0Jthw. Я его тоже откуда-то качала, но уже забыла откуда, решив, что BSPacker лучше.

Итак:

1. кидаем в распаковщик\data из This War of Mine\Mods архив вида номермода_имяархива.DAT и номермода_имяархива.IDX, а также имяархива.DAT и имяархива.IDX из корня This War of Mine
   
2. запускаем unpack.py
   
3. поиском по содержимому ищем в \распаковщик\out нужное (скорее всего, оно будет в архиве основной игры, но не мода)
   
4. правим, кидаем в папку \распаковщик\out\номермода_имяархива и запускаем pack.py
   
5. кидаем в This War of Mine\Mods созданные в out архивы мода
   
6. запускаем и проверяем (начав новую игру)

…И эту операцию нужно будет повторять после ЛЮБОГО изменения, внесённого в мод, потому что при каждой новой компиляции архивы будут перезаписаны редактором.

В моём случае это были настройки зимы в архиве common, которые я нашла там, распаковав его через BSUnpacker (они в скрипте shelterstates.lua). Да, в игре стоит ограничение на минимальную температуру в -5°C, недоступное из редактора (лопата, смейтесь)! Распаковав common фростпанковским архивом и запустив поиск по содержимому с текстом OutsideTemperature, я нашла этот скрипт в виде файла ce6d60cf. Отредактировала его и закинула в папку 0dfe44a4e78f4b32bfe5e75b1cd80b1c_common в out, запаковала обратно и вернула мод на место.

Буду добавлять полезные файлы:

Честно говоря, я хотела найти файлы кастомных персонажей, чтобы не было у них у всех по 12 ячеек в рюкзаке. Не нашла. Похоже, у этих ребят один файл на всех, а где хранится их общее 12, я не нашла (но точно не в templates\characters\dwellerwithactions - это я проверила).

И да, снова увы - templates.dat. Этот архив не создаётся модом, а значит, впихнуть эту инфу в мод не получится, изменить её можно только для себя через основной templates из корня игры.

Но если кому интересно, вот файлы персонажей:


Распаковать templates фростпанковским распаковщиком, найти файл, открыть его любым HEX-редактором и заменить нужные символы. Они где-то в конце, среди нулей. Потом, естественно, запаковать обратно.

Вот для примера:


Борис


Бруно

Успехов всем в модостроительстве!

А также, чем чёрт не шутит, в дальнейших раскопках ресурсов игры. Я бы всё-таки хотела узнать, как менять карты локаций, настройки персонажей… Словом, все те файлы, которые не берутся даже HEX-редактором. Возможно, кто-нибудь догадается, в какой программе они делались?