Сжатие конвейеров(kovarex)

Решение о том, как приблизиться к сжатию конвейера в 0,16, было нелегким, мы в основном столкнулись с двумя возможностями:

  • Сплиттеры — единственный способ надежно сжать конвеер.
  • Сжатие автоматическое везде (манипуляторы, боковые загрузки, буры)

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

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

Решение заключалось в том, что всякий раз, когда есть какой-либо промежуток, превышающий стандартное расстояние между предметами на ленте, предмет может быть вставлен туда и для (обычно) короткого момента, предметы сжимаются ближе, чем обычно. Но как только лента начинает двигаться, разрыв между двумя раздавленными предметами простирается до стандартного размера. Это изменение потребовало от нас фундаментальных изменений в логике конвейера, что могло бы привести к возникновению множества новых проблем, но поскольку мы просто хотели, чтобы это было разрешено в 0,16, мы должны были это сделать сейчас.

Результатом является то, что та же самая установка в 0.16.25+ приводит к совершенно сжатому конвейеру:

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

Загрузка журнала сбоев(Twinsen)

Введение

Начиная с 0.16.24, Factorio загружает свой журнал сбоев нам каждый раз, когда она вылетает (это можно отключить из меню опций).
Очень долго мы хотели это сделать. Я бы часто говорил, что отчеты об авариях, которые мы получаем на форуме отчетов об ошибках, — это очень небольшой процент фактических сбоев, и что мы действительно не знаем, что важно или нет, если нет большой ошибки, о которой многие люди сообщают. Это подтвердилось после выпуска 0,16.24. Мы получили сотни журналов сбоев, но ничего не было опубликовано на форуме, и мы быстро нашли серьезную проблему и исправили ее.

Способ, которым он работает, заключается в том, что при сбое Factorio и создании журнала сбоев в его умирающие моменты начинается новый процесс, который пытается загрузить factorio-current.log (и в некоторых редких случаях factorio-dump-current.dmp). Однажды на нашем сервере мы проанализируем трассировку стека и организуем его с идентичными журналами сбоев в папку. Таким образом, мы можем знать, какие сбои происходят чаще, и позволяют нам более точно определять приоритеты. Наш интерфейс выглядит примерно так.

До сих пор это оказалось очень полезным. Всего за 2 дня Rseding зафиксировал около 12 сбоев, которые были найдены в нашем инструменте отчетности, ни о чем не сообщалось на форуме.

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

Конфиденциальность

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

Журнал содержит только основную системную информацию (CPU, GPU и свободную память), настройки отображения игры, журнал операций, трассировку стека аварийных сигналов для основного потока, а в некоторых редких случаях — минидампы. Мы отправляем эту информацию (если вы не отказались), в нашем двоичном формате, надежно, через HTTPS на один из наших серверов. В следующей версии мы даже немного очистили журнал, чтобы он не содержал ничего, что можно было бы рассматривать как нарушение конфиденциальности, например IP-адреса. Мы также обновили наше лицензионное соглашение и включили его в игру, чтобы смягчить любые юридические проблемы.

Даже со всем этим некоторые люди думают, что мы делаем что-то неправильно. Перефразируя то, что сказал kovarex: «Игры, которые я играл, отправляли все виды данных, и они не позволяют мне отказаться, теперь мы делаем это  прозрачно, и мы плохие парни?»

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

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

Таинственная проблема Ryzen (например, ошибка памяти / ошибка процессора / плохое оборудование / не наша ошибка наверняка)

Второй наиболее распространенный вылет игры, о котором сообщалось в 0.16.24, с 61 уникальными авариями, был таинственным сбоем в EntityRenderer :: prepareRow. Это один из тех сбоев, которые появляются на форумах каждые несколько месяцев, и мы не можем найти причину, поэтому мы не исправим ее. Некоторые из нас часто обвиняют его в повреждении памяти или ошибке процессора, но я часто скептически отношусь к словам, что мы не можем использовать это оправдание каждый раз, когда мы не можем найти причину сбоя.

Теперь, когда у нас есть инструмент для загрузки сбоев, мы можем сделать больше. Прежде всего, мы заметили, что 100% этих сбоев были на процессоре AMD Ryzen. Даже со всеми аварийными журналами мы все равно не выяснили, что происходит. Итак, в 0.16.25 мы начали загружать мини-накопители, когда происходит сбой EntityRenderer :: prepareRow. Несколько минидампы, которые мы получили, по-прежнему очень странны, и мы не можем понять, что происходит не так, причем самым простым козлом отпущения является возложение вины на плохое оборудование. Вероятно, это будет одна из тех ошибок, которые будут преследовать нас в течение некоторого времени …

Как всегда, дайте нам знать, что вы думаете на нашем форуме


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

Читать далее


В скором будущем нас ждёт новый элемент для управления энергосетью фабрик — выключатель.
Несложно догадаться, что благодаря ему мы сможем, к примеру, отключать определённые участки фабрик с высоким энергопотреблением на время обороны или нападения. Или создать автоматическую систему «переключения электричества» на альтернативный источник питания.

Художники уже закончили работу над выключателем, и сейчас он выглядит вот так:

Выключатель. Анимация работы

анимация работы выключателя

Управлять выключателем можно вручную, если он не подключён к логической сети.

Подробнее можно прочитать в блоге разработчиков(на Английском языке).


В Factorio 0.13.x нас ожидает новая система строительства железных дорог, которая позволит быстро и эффективно строить жд пути.
Поиск оптимального пути происходит с помощью «Алгоритма поиска А*»
На данный момент выглядит это примерно так:

Улучшенное строительство железных дорог

Поиск оптимального маршрута.

Подробнее можно прочитать в блоге разработчиков(На Английском языке):