Zlodey, кстати, интересный кусок, отдельное спасибо. Посмотрел на тайминги и структуру тиков - появилось пару вопросов по теме статистики, если ты будешь свободен. Правильно ли я понимаю, что ты работаешь с событийной моделью движка, где все события внутри одного тика (включая критические состояния пилота) прилетают одним паком, и серверная часть не всегда успевает отделить хронологию повреждений внутри самого тика? По сути, это "лейка с фильтрами" при API логировании движка игры, и ты сейчас обрабатываешь это через свои авторские скрипты-обертки на стороне БД. А как в таких случаях выставляется приоритет событий? Вот например, если попадание снаряда и "смерть" прилетают в рамках одного тика, скрипт пишет их в базу как одновременные, или у тебя стоит какой-то внутренний буфер для предсказания последовательности (тут и зарыта "собака" из-за которой пишется за одну секунду целая серия разнесенных в реале по времени событий)? Очень интересно, как удается выравнивать эту дискретность по сути, чтобы стата не теряла доли реализма, хочется понять границы возможностей самого движка (там где разрабы делятся, такая каша навалена, что найти, что-то для трезвой оценки... прям в край проблематично). Просто насколько мы впринципе, как клиенты, можем быть тогда требовательны к точности, если двигло ила допускает такие разбросы? И еще, там небось "мусора" сыпет выше крыши, нет ли шанса упустить на фильтрации такого потока, что-то важное? Только не злись, я ж в роли подглядывателя под локтем не по своей воле, работу не прошу, просто любопытство чешется.

42 минуты назад, Matpocob сказал:

Zlodey, кстати, интересный кусок, отдельное спасибо. Посмотрел на тайминги и структуру тиков - появилось пару вопросов по теме статистики, если ты будешь свободен. Правильно ли я понимаю, что ты работаешь с событийной моделью движка, где все события внутри одного тика (включая критические состояния пилота) прилетают одним паком, и серверная часть не всегда успевает отделить хронологию повреждений внутри самого тика? По сути, это "лейка с фильтрами" при API логировании движка игры, и ты сейчас обрабатываешь это через свои авторские скрипты-обертки на стороне БД. А как в таких случаях выставляется приоритет событий? Вот например, если попадание снаряда и "смерть" прилетают в рамках одного тика, скрипт пишет их в базу как одновременные, или у тебя стоит какой-то внутренний буфер для предсказания последовательности (тут и зарыта "собака" из-за которой пишется за одну секунду целая серия разнесенных в реале по времени событий)? Очень интересно, как удается выравнивать эту дискретность по сути, чтобы стата не теряла доли реализма, хочется понять границы возможностей самого движка (там где разрабы делятся, такая каша навалена, что найти, что-то для трезвой оценки... прям в край проблематично). Просто насколько мы впринципе, как клиенты, можем быть тогда требовательны к точности, если двигло ила допускает такие разбросы? И еще, там небось "мусора" сыпет выше крыши, нет ли шанса упустить на фильтрации такого потока, что-то важное? Только не злись, я ж в роли подглядывателя под локтем не по своей воле, работу не прошу, просто любопытство чешется.

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

2. Я не ориентируюсь на тики и не вычисляю время по тикам. Я ставлю время обработки события и все. Хранение, разумеется, с разными айдишниками (64 бита), сортируется прекрасно, при необходимости.

3. Что тебе мешает открыть логи и посмотреть как и что там пишется, если интересно?