Пятничные факты #233 — Администратор Вики странички факторио

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

Магазин футболок в полном разгаре

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

Визит вики администратора

Давным-давно мы создали официальную вики страницу Factorio, и мы в основном решили, что сообщество ее поддержит. Через некоторое время мы посмотрели на Wiki и увидели, что не все так хорошо. Поэтому мы создали руководство. Время прошло, и вскоре гайд был устаревшим. Трудно быть в раннем доступе таким образом, любая работа, которую мы делаем, может устареть через несколько месяцев.

За это время к нам подошли два человека, Gangsir и Bilka. Из беспорядка что, они спасли и восстановили Wiki в некотором разумном состоянии. Вскоре качество и полезность Wiki превысили качество гайдов, и благодаря своей невероятной работе Wiki стал настоящим ресурсом

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

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

Пятничные факты #232 — PAX, Ошибки, Графы

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

Борьба за стабильность

Большинство из нас работает над исправлением ошибок и небольшими проблемами в нашем отставании, но некоторые из нас уже работают с 0,17. TOGoS делает серьезные изменения в генераторе карт, чтобы исправить множество мелких проблем, которые он по-прежнему имеет. HanziQ и sindri работают над заменой графического интерфейса OpenGL 3.3 вместе с posila, который начал работать с DirectX 11 back-end. Wheybags работает над новым рендерингом шрифтов. Oxyd начал внедрять наш первый графический интерфейс из переписаного GUI, новая технология GUI, как и другие мелкие вещи, находятся в очереди.
Продолжить чтение

Пятничные факты #231 — Сжатие конвейеров и загрузка журналов сбоев

Сжатие конвейеров(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. Несколько минидампы, которые мы получили, по-прежнему очень странны, и мы не можем понять, что происходит не так, причем самым простым козлом отпущения является возложение вины на плохое оборудование. Вероятно, это будет одна из тех ошибок, которые будут преследовать нас в течение некоторого времени …

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