• Страница 1 из 1
  • 1
Модератор форума: k©קaso√®  
Форум - gamer-mods » Fallout 4 » Fallout 4 - Sim Settlements » Sim Settlements - Треугольник Смерти (Причины падения игры в районе Сенкчуари - Эбернети - Ракета)
Sim Settlements - Треугольник Смерти
13.09.2018 в 03:52:16, сообщение 1
Offline
Локализатор
Исследователь
46 постов
Sim Settlements
ТРЕУГОЛЬНИК СМЕРТИ

- оригинал -


Глава 1
КРАТКОЕ ОПИСАНИЕ ПРОБЛЕМЫ


Введение в Треугольник Смерти

Одной из наиболее распространенных областей игры с часто случающимися CTD (crashes to desktop -- выброс на рабочий стол) и другими проблемами с игровым процессом при использовании Sim Settlements является область Сенкчуари - Ферма Эбернети - Красная Ракета, обычно упоминаемая здесь как "Треугольник смерти". Чтобы понять, почему происходят эти падения, нам нужно взглянуть на некоторые из основных механизмов, которые использует движок Fallout 4 для создания мира вокруг вашего персонажа, как эти основные механизмы обычно обходят при создании модификаций и какие последствия это может оказать на стабильность игры.

Во-первых, нужно рассказать о треугольниках.

Треугольная растеризация и лимит построек

Fallout 4 использует так называемую треугольную растеризацию для рендеринга объектов на экране. Все, что вы видите в игре, состоит из множества крошечных треугольников, связанных между собой. Движок использует треугольники, потому что их проще рисовать, чем другие фигуры, и с точки зрения геометрии каждая форма может быть разделена (грубо) на треугольники, но треугольник можно разделить только на другие треугольники. Лимит построек поселения измеряет количество треугольников, которые движок пытается прорисовать в поселении. Наши компьютеры и сам движок могут отображать не только определённое количество треугольников в заданном месте в данный момент времени, но при этом выполнять все функции, которые ему понадобятся в это же время. К сожалению, некоторые из трюков, которые разработчики используют для создания более сложных пейзажей в играх, таких как плоскостные экраны (которые препятствуют отображению чего-либо позади них, тем самым экономя драгоценную вычислительную мощность), не могут использоваться в свободно построенных поселениях и городах RotC.

Тем не менее, игроки и авторы модов быстро выяснили способы обманывать, обходить и полностью отключать лимит построек в поселении, и это общепринятая практика для людей, которые строят поселения широко. С полным на то основанием, поскольку лимит построек большинства ячеек заполняется почти сразу, если вы строите какое-либо здание, которое включает в себя украшения или пользовательские объекты. Когда городские планы RotC были созданы, дизайнеры продолжили эту практику и почти во всех случаях радикально превысили лимиты построек поселений, на территории которых были размещены города. Это особенно проблема в районе Сенкчуари, Фермы Эбернети и Красной Ракеты. Два из этих трех поселений (Сенкчуари и Ферма Эбернети) являются большими, а их ванильный лимит построек намного меньше, чем их физические размеры должны были бы быть в состоянии поддерживать. Таким образом, очень заманчиво и часто необходимо обходить ограничения, чтобы получить логичный, красивый и проработанный результат строительства.


uGrids to Load и uExterior Cell Buffer

Вся карта Fallout 4 разделена на так называемые ячейки. Чтобы понять их и почему они имеют значение, вам нужно знать о параметре "uGrids to Load", который является настройкой игры, сообщающией движку, сколько ячеек нужно полностью отображать вокруг той ячейки, в которой находится ваш персонаж, и о параметре "uExterior Cell Buffer", который сообщает движку, сколько ячеек сохранять загруженными в памяти в любой момент времени. Значения по умолчанию: uGrids to Load = 5 и uExterior Cell Buffer = 36. Всякий раз, когда вы пересекаете границу ячейки, игра пытается выгрузить из памяти эту перекрывающуюся область и перемещает загружаемую/рисуемую сетку, чтобы центрировать её на новой ячейке, в которой вы теперь находитесь.

Проблема в том, что, стоя в Сенкчуари, в память загружается до 36 ячеек вокруг вашего персонажа, и все, что содержится в сетке 5x5 ячеек, сосредоточенных вокруг вас, фактически обрабатывается в игру. В зависимости от того, с какой стороны вы вошли в Сенкчуари, Ферма Эбернети и Красная ракета находятся в основном в указанных диапазонах, и если лимиты построек были превышены в этих локациях, то... полагаю, вы уже понимаете, к чему это приводит.

Ещё хуже, когда вы двигаетесь, и хуже всего, когда бегаете или летаете на вертибёрде, так как вы заставляете игру загружать, обрабатывать и выгружать эту область 5x5 клеток вокруг вашего персонажа довольно быстро. Кроме того, сами эти поселения включают в себя несколько ячеек с застроенными областями, то есть перемещение вокруг и внутри них может вызвать изменение ячеек и запуск новых вычислений. Добавьте недостатки производительности, которые не позволяют игрокам/RotC создавать объекты в игровом мире, ограничивают скриптовые потоки, необходимые для запуска систем поселения в фоновом режиме, ИИ поселенца и любые другие игровые скрипты, которые работают в фоновом режиме, и вы таким образом можете быстро перегрузить даже самый мощный компьютер.


Пример 1. Границы ячеек и перемещение в поселении

Это пример карты ячеек Fallout 4:



В этом примере вы находитесь в ячейке, где Карла останавливается перед старым домом игрока в Сенкчуари. В зависимости от того, как вы вошли в Сенкчуари, небольшая область изображения может быть частью uExterior Cell Buffer , а почти весь остров находится в области uGrids to Load:



Теперь давайте представим, что вы перебегаете в другой конец Сенкчуари, к мосту:



Обратите внимание на то, как область uGrids to Load вокруг вас графически рисует область игры, которая теперь заключает в себе большую часть Красной Ракеты и начала прижиматься к краю Фермы Эбернети, тем самым значительно увеличивая количество треугольников, которые игра попытается отрисовать, а также, вероятно, запуская очередь скриптовых функций, опирающихся на загрузку ячеек, чтобы инициировать их работу.

Scrap Everything, который я люблю до смерти, значительно усугубляет эту проблему, удаляя прекомбинированные меши в ячейках поселения, которые обычно функционируют смутно напоминая "сжатые" версии обычных текстур (что не совсем точно, я чрезмерно упрощаю) и требуют меньше памяти для загрузки и последующей отрисовки. С их отключением ВСЕ объекты визуализируются отдельно, добавляя по-настоящему огромное количество объектов для рендеринга, что значительно усугубляет проблему.


Пример 2. Загрузка ячеек и обновление информации о поселении

Кроме того, проблемы с расчетами ресурсов поселений исходят из крупных многоэлементных поселений (например, позорная "ошибка отображения ресурсов в пипбое"). Допустим, вы бежите к Сенкчуари из Конкорда по дороге, которая проходит мимо Красной Ракеты. У вас есть здание, полное генераторов в пустом месте на северной стороне тупика Сенкчуари, энергия от него проведена к башне рядом с главным мостом, который защищают лазерные турели:



Когда вы приближаетесь к Сенкчуари, и он начинает загружаться в память и отрисовываться, вы решаете проверить свой пипбой. Скрипты мастерской начинают обновление. Ячейка, в которой находятся наши генераторы, не отображается, и поэтому, к сожалению, они не существуют в связанных расчётах скрипта мастерской. Таким образом, ваши лазерные турели все окажутся без энергии (потому что во время расчетов, они есть), и показатель защиты в пипбое внезапно и необъяснимо уменьшится. То же самое может случиться и для количества кроватей, количества еды и т. д.. Эти подсчёты случаются прежде, чем будет обновлён расчёт счастья, и, таким образом, оно начинает падать без уважительной причины. Если вы развернётесь и вернётесь обратно, расчёт мастерской сохранится таким образом, и ваше счастье будет продолжать падать/ваше поселение будет считаться уязвимым для атаки, пока вы не вернетесь в поселение и не позволите сценариям полностью обновиться.


Это не просто Треугольник Смерти

Для этой статьи был использован Треугольник Смерти, чтобы проиллюстрировать некоторые из основных проблем, с которыми мы, как игроки и пользователи модов, сталкиваемся при разработке поселений. Почти каждый, кто играет в Fallout 4 и взаимодействует с системой поселений, сталкивается с какой-то частью Треугольника Смерти в течение нескольких минут после первого выхода из Убежища 111. Черт возьми, игра в основном предназначена для того, чтобы побудить игроков начать строительство в Сенкчуари и Красной Ракете почти сразу. Таким образом, это отличный пример, который может быть понятен большинству игроков.

К сожалению, эти проблемы не являются исключительными для Треугольника Смерти:
  • • Любое поселение, которое в пределах 5 ячеек граничит с путями, по которым обычно ходят игроки, может испытывать "Ошибку отображения ресурсов".
  • • Любое поселение, которое в пределах 5 ячеек граничит с другим поселением, может инициировать CTD, связанное с проблемами рендеринга и базовыми скриптами.


Вклад скриптов и скриптовых объектов

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

Согласно мнению Sclerocephalus, одного из кодеров команды Unofficial Patch, как только вы превысите определенное количество скриптовых объектов между всеми вашими поселениями (сюда входят поселенцы, простаивающие маркеры, турели, зоны Sim Settlements, кровати, радиостанции, все, что производит ресурсы, и т.д.), вы значительно увеличиваете вероятность удушения WorkshopParentScript, основного скрипта, который запускает систему поселений в Fallout 4.  Технические подробности

Они рекомендуют никогда не превышать ванильный максимум из 21 поселенца в одном поселении и сводить к минимуму количество скриптовых объектов, которые вы создаете в любом поселении, даже если вы используете UFO4 Patch версию WorkshopParentScript (которая отличается от сценария ванильной игры, к счастью, Kinggath разрабатывает Sim Settlements для работы с версиями скриптов ванильной и UFO4 Patch, поэтому безопасно использовать оба). Лаги различных скриптовых вычислений мастерской обостряют все эти проблемы и увеличивают их вероятность. В треугольнике Сенкчуари - Ферма Эбернети - Красная Ракета есть много областей, где множество скриптовых объектов и поселенцев могут рендериться и способствовать общей скриптовой нагрузке.


Это не баг, это функция...

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


Глава 2
РЕШЕНИЕ ПРОБЛЕМЫ


Вызываем убойную команду!

Большинство из нас, в какой-то момент, подумали: "Подождите минуту! Я могу решить эти проблемы, увеличив мощность! Если бы я мог только обновить свой компьютер, я мог бы сделать Fallout 4 настолько шустрым, насколько захочу!" В то же время пользователи сталкиваются с проблемами Fallout 4 и часто делают заявления, которые являются некоторыми вариациями на тему "У меня не комп, а зверь! Разогнанный процессор Intel Core i9-7980XE с жидкоазотным охлаждением, 2 ТБ ОЗУ, объединённые видеокарты Titan V и 2TB 970 EVO SSD, предназначенные только для Fallout 4 и модов! Почему игра всё ещё падает?!?"(Я гиперболизирую, но вы понимаете).

К сожалению, спецификации вашего компьютера имеют значение только в определенной точке, и эта точка не намного выше рекомендованных системных требований Fallout 4. "Узкое место". Фраза, которую я часто слышу в игровых кругах: Узкое место, это не ваш компьютер, узкое место -- это Fallout 4.

Далее статья станет немного технической, но для понимания того, почему спецификации нашего компьютера имеют значение только до определенного момента, нам нужно заглянуть под капот Fallout 4 и рассмотреть некоторые из его основных частей. Надвиньте поглубже шляпы и держитесь за поручни!


Техноболтовня

Как вы, возможно, слышали, Fallout 4 работает на так называемом Creation Engine. Papyrus VM, система скриптов для Creation Engine, является лишь одной из многих подсистем, на которую Creation Engine должен выделять ресурсы вашего компьютера для запуска игры. Creation Engine выделяет большинство ресурсов, которые он имеет, для рендеринга графики игры. Это имеет смысл, потому что мы все хотим отличной графики, не так ли? Это, как правило, первая и часто самая важная вещь, по которой большинство игроков оценивают игру.

Остальные ресурсы вашего компьютера разделены между всеми другими подсистемами, помимо Papyrus VM, и все это связано с вашей частотой кадров (частота, с которой Fallout 4 обновляет изображения неподвижных кадров это рендеринг). Creation Engine использует частоту кадров как своего рода "временной пояс" для синхронизации всех подсистем, в которых он работает. Поскольку подсистемы имеют очень разные возможности с точки зрения того, насколько быстро они могут выполнять свои разные роли, Creation Engine был разработан с целевой и максимальной частотой кадров в 60 кадров в секунду для компьютеров и 30 кадров в секунду для консолей. Если Fallout 4 работает на цель/максимум 60 кадров в секунду, один кадр отрисовывается каждые 16,67 миллисекунды. (Если Fallout 4 работает со скоростью 30 кадров в секунду, один кадр отрисовывается каждые 33,34 миллисекунды).

Хотя Papyrus VM не влияет на частоту кадров, частота кадров абсолютно точно влияет на Papyrus VM. Источник

Копнём поглубже...

Вики Sim Settlements содержит две настройки твиков, о которых нам нужно поговорить, чтобы понять, как Creation Engine выделяет ресурсы для системы Papyrus VM в течение этого минимального таймфрейма: “fUpdateBudgetMS” and “fExtraTaskletBudgetMS”.  Эти два параметра определяют, сколько миллисекунд за фрейм Creation Engine предоставляет Papyrus VM для запуска скриптов.  [url=https://www.creationkit.com/fallout4/index.php?title=INI_Settings_(Papyrus)]INI Settings (Papyrus)[/url] Значение по умолчанию для этих настроек - 1,2 (или 1,2 миллисекунды), а руководство по оптимизации рекомендует удвоить их до 2,4 (или 2,4 миллисекунды). Используя настройки руководства по производительности, Creation Engine предоставляет Papyrus VM 2,4 миллисекунды для запуска сценариев каждый раз, когда Fallout 4 рисует новый кадр на экране.

К счастью, Papyrus VM - это многопоточный скриптовый язык [url=https://www.creationkit.com/index.php?title=Threading_Notes_(Papyrus)]Threading Notes (Papyrus)[/url] , а это означает, что он может попытаться обработать несколько скриптов одновременно в течение этого крошечного промежутка времени. Большинство сценариев, таких как WorkshopParentScript, являются частью гигантской паутины взаимосвязанных дочерних скриптов, которые генерируют и обновляют различные переменные и значения, которые затем передаются по сети. Затем родительские скрипты объединяют все эти переменные, чтобы что-то делать в игре. Система, известная как стек вызовов, используется для отображения этой сети взаимосвязей.

Это приводит нас к следующему набору настроек твиков, которые содержит вики Sim Settlements, и о которых нам нужно поговорить: "iMinMemoryPageSize", "iMaxMemoryPageSize" и "iMaxAllocatedMemoryBytes". Эти настройки определяют, сколько памяти, в байтах, Papyrus VM может выделить для организации и запуска всех скриптов в стеке вызовов. Значения по умолчанию для этих параметров:
iMinMemoryPageSize = 128 (или 128 байт),
iMaxMemoryPageSize = 512 (или 512 байт) и
iMaxAllocatedMemoryBytes = 153600 (или 156 килобайт).
Руководство по производительности рекомендует удвоить эти значения до следующих:
iMinMemoryPageSize = 256 (или 256 байт),
iMaxMemoryPageSize = 1024 (или 1024 байта) и
iMaxAllocatedMemoryBytes = 307200 (или 312 килобайт).


Если Papyrus VM не сможет выполнить скрипт за 2,4 миллисекунды, которые он имеет во время каждого кадра, он перекидывает этот скрипт к следующему кадру. Согласно мнению SMKViper, сотрудника Bethesda, ответственного за Papyrus, Papyrus VM будет продолжать делать это до тех пор, пока (1) скрипт не завершится или (2) в Fallout 4/вашем компьютере/вашем XBox не закончится доступная память. Нет такого понятия, как "сброс скрипта". Единственное, что может случиться, -- это перегрузка скриптового движка и переполнение памяти Papyrus FAQ.


Я сам убойная команда!

К сожалению, чистая вычислительная мощность не сделает этого, потому что подсистема выделения памяти была разработана для работы как на консолях, так и на ПК. Подсистема выделения памяти должна работать на Xbox и Playstation, а также на ПК. Каждая из консольных и система ПК имеет различные методы расчёта распределения системных ресурсов. Подсистема выделения памяти Creation Engine, по-видимому, была разработана с учетом стандарта, который может вместить большинство систем, для работы на которых она предназначена.

Помните, что у нас есть до 2,4 мс, чтобы Papyrus VM сделал столько, сколько возможно. Мы не можем выжать частоту кадров выше 60 кадров в секунду, обусловленную контролирующими таймингами papyrus. Однако,-мы можем частично перебороть это. Более быстрый процессор (одноядерный) может протолкнуть больше скриптов Papyrus за те же 2,4 мс. Несколько ядер не помогут в этом конкретном аспекте производительности (но они помогают в другом).

Что ж, вы согласны на грубую силу? Ответ "да, но..." Да, но если вы станете делать так, вы получите уменьшающуюся выгоду.

Что произойдет, если перегрузить виртуальную машину Papyrus? Начинается сброс в память. Вы, наверное, не заметите этого, пока не заполнится файл подкачки -- тогда всё остановится и рухнет. Но к этому времени, вы уже находитесь за пределом того, что ваш процессор может обработать за 2,4 мс. Случайная перегрузка в порядке. Он догонит в менее напряженное время. Но постоянные перегрузки? Вот когда вам нужно уменьшить свой список модов и сократить на 60 поселенцев ваш magnum opus, потому что реальная польза от очень мощного компьютера, это то, что у вас есть чуть больше возможностей, чтобы подтолкнуть систему, прежде чем случится авария.


Блокируйте скрипты, блокируйте частоту кадров

Когда поток начинает выполнение родительского или дочернего скрипта, он "блокирует" этот скрипт на время обработки, что предотвратит доступ к нему других скриптов и чтение его переменных. Если скрипты являются массивными кластерами из сотен различных дочерних скриптов, каждый из которых должен каждый раз генерировать/обновлять свои переменные (например, WorkshopParentScript, к сожалению для нас), и они используют функции (это алгебраически вычисляемое уравнение, представленное на скриптовом языке Papyrus), которые выполняют эту работу, но запускаются медленно (помните, что "медленно" значит здесь больше миллисекунды или около того), это заблокированное состояние означает, что родительский скрипт может занять в буквальном смысле несколько минут. Следовательно, для Papyrus VM может потребоваться много, много, много кадров, чтобы в конечном итоге запустить финальный родительский скрипт и выполнить действие, которое вы попросили его выполнить.

Частота кадров -- это ключ. Помните, что Creation Engine был разработан с целевой и максимальной частотой 60 кадров в секунду для компьютеров и 30 кадров в секунду для консолей.
  • • Независимо от того, насколько мощный ваш компьютер, Creation Engine не может предоставить Papyrus VM более 2,4 миллисекунды (1,2 миллисекунды для консолей) из каждой секунды для запуска скриптов.

Если вы запускаете слишком много скриптов, они в конечном итоге начнут выполнять резервное копирование, что увеличивает использование памяти и вытесняет другие вещи, такие как подсистема рендеринга, что в свою очередь замедляет частоту кадров, а это еще больше ускоряет работу, пока этот цикл, наконец, не начнёт задыхается от Creation Engine и... бум, игра падает. Будет еще хуже, если вы попросите движок отобразить группу объектов высокого разрешения (т.е. огромное множество треугольников), сложную графику.

Независимо от того, насколько мощный ваш компьютер, Creation Engine не может давать другим подсистемам, таким как графический рендерер, более 997,6 миллисекунд (498,8 миллисекунды для консолей) каждую секунду, чтобы запускать каждую другую системную потребность Fallout 4.

Грубая сила покупает только время.

Но, если я отключу частоту кадров...

По крайней мере, некоторые из вас, вероятно, думают: "Обожди-ка! Если я просто отключу частоту кадров, я могу получить 144 кадра в секунду, а потом все будет быстрее!"

Согласно SmkViper, повышение частоты кадров фактически уменьшает количество времени за которое скриптовый движок должен обрабатывать все необходимое в одном кадре. Таким образом, при 30 кадрах в секунду новый кадр отображается один раз каждые 33,34 мс. При скорости 60 кадров в секунду кадр отображается каждые 16,67 мс. При 144 кадрах в секунду кадр отображается каждые 6,9 мс. Помните, что значение по умолчанию для "fUpdateBudgetMS" и "fExtraTaskletBudgetMS" (количество миллисекунд работы Papyrus VM за кадр) составляет 1,2 мс (2,4 мс, если вы используете максимальные значения).

И вы ещё спрашиваете о проблемах, когда используете достаточное количество скриптовых модов, чтобы требовать полного времени обработки 1,2 мс (или 2,4 мс) на кадр, но кадр-то длится всего 6,9 мс. Вы отдаете для остальной части игровых систем только 5,7 мс на кадр (или 4,5 мс) для выполнения всех других функций, которые должна воспроизводить игра.

Конечно, игра будет работать и с частотой кадров выше 60 кадров в секунду. Но, если вы поиграете достаточно долго, то в какой-то момент случится CTD, потому что позволяя игре неограниченно визуализировать эффекты, используется временной масштаб скриптов, что заставляет скрипты запускаться, когда этого не нужно, NPC перемещаются быстрее, анимации работают быстрее и т. д.

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

Вы можете добиться такого же эффекта, установив временную шкалу игры на 120 с помощью команд консоли (по умолчанию 20). Через несколько минут это сработает. Даже если установить на 30, это приведет к сбою, хотя это займет намного больше времени. Система Papryus VM очень хрупка, когда дело касается времени. Вы можете подтолкнуть чуть-чуть... но один неосторожный толчок может привести к неудаче.


Аналогия

Представьте себе Fallout 4 и ваш компьютер в качестве автомобиля. Двигатель -- это ваш компьютер. Все остальное, кузов, сиденья, система рулевого управления, подвеска, колёса, электрика, тормозная система и т.д. -- это Fallout 4.

Fallout 4 -- это седан среднего размера, 4-дверный. Каждая из его систем была спроектирована так, чтобы наилучшим образом работать с линейным 2,4-литровым 4-цилиндровым двигателем (по этой аналогии, системные спецификации для Xbox One).

Но ваш компьютер -- 8-литровый с 16-цилиндровым турбо-двигателем от Bugatti Veyron.

Вы берёте свой седан среднего размера и ставите туда двигатель от Bugatti Veyron. Разве седан после этого будет ездить, управляться, поворачивать, ускоряться, тормозить и останавливаться точно так же, как Veyron?

Конечно, нет. Не поймите меня неправильно; он поедет быстрее, чем 4-цилиндровый... пока все остальное не выйдет из строя, и то, потому что оно хорошо работает за пределами своих допусков.


Но что мы можем сделать?

1. Будьте очень избирательны в отношении того, какие поселения вы выбираете для строительства по планам Rise of the Commonwealth. НЕ пытайтесь построить все три поселения в Треугольнике Смерти в одном и том же прохождении, и ТЕМ БОЛЕЕ НЕ пытайтесь строить все три с нуля одновременно.  То же самое касается и других опасных мест, например Ферма Уорвиков - Спектакл-айлэнд - Замок.

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

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

4. Если возможно, избегайте использования модов, которые (1) расширяют границы поселений и (2) отключают прекомбинированные меши.

5. Помимо рекомендуемых настроек INI из руководства по производительности Sim Settlements, избегайте делать такие вещи, как (1) изменение шкалы времени, (2) сворачивание частоты кадров, (3) изменение других параметров INI, (4) запуск ненужных программ в фоновом режиме во время игры, (5) применять иные параметры, вызывающие сбой.


----------------------------

ОТ АВТОРА
Я хотел бы поблагодарить следующих лиц за содействие, влияние или иное информирование об этом руководстве, а также всех, кто ответил на исходную тему и предоставил отзывы:
  • SmkViper
  • Sclerocephalus
  • GA_Darkerside
  • damanding
  • wim95
  • GamerPoets
  • Blick Mondoo
  • Yagisan
  • woodfuzzy

Оригинальные вклады были слегка переформулированы, чтобы соответствовать общему тону и потоку статьи, но, надеюсь, дух и детали информации не были потеряны. Любые ошибки или упущения являются моими собственными.

- snarkywriter


ОТ ПЕРЕВОДЧИКА
Прошу прощения за невысокое качество перевода. Я толмач, а не спец по железу и не кодер, поэтому, возможно я где-то исказил некоторые термины или понятия в силу своей не полной компетентности. Однако, полагаю, что статья вполне информативна, и если я смог понять, о чём тут речь, то и остальные смогут, иначе и переводить не имело смысла. Но в то же время, если найдётся желающий откорректировать текст и "перевести" всё это на более понятный технически грамотный русский язык, то милости просим.
-------------------------
13.09.2018 в 03:52:50, сообщение 2
Offline
Локализатор
Исследователь
46 постов
Резерв
13.09.2018 в 03:53:01, сообщение 3
Offline
Локализатор
Исследователь
46 постов
Можно удалить
13.09.2018 в 03:53:12, сообщение 4
Offline
Локализатор
Исследователь
46 постов
Можно удалить
13.09.2018 в 03:53:28, сообщение 5
Offline
Локализатор
Исследователь
46 постов
Можно удалить
23.09.2018 в 00:44:50, сообщение 6
Offline
Проверенные
Горожанин
9 постов
Спасибо.

Есть ещё Scrapping Mods and Performance Issues
Форум - gamer-mods » Fallout 4 » Fallout 4 - Sim Settlements » Sim Settlements - Треугольник Смерти (Причины падения игры в районе Сенкчуари - Эбернети - Ракета)
  • Страница 1 из 1
  • 1
Поиск:
Gamer-mods.ru © 2012 - 2018