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

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

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

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

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

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

6 часов назад, Zlodey сказал:

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

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

Однако, теперь стало понятно, в чем суть разночтений по таймингам: если статистика строится не на временных метках самого движка, а на времени обработки события твоим скриптом записи в базу, то итоговая хронология, я полагаю, напрямую зависит от очередности и скорости обработки пакетов этим же скриптом. А значит, "хронология", которую мы все видим - это не то чтобы объективный лог сервера, а лишь результирующий лог работы твоего парсера. Становятся понятны причины искажений: например при высокой нагрузке на скрипт записи реальный порядок событий в базе данных неизбежно смещается относительно реального времени. Однако подозреваю, что это найболее удобный вариант в угоду упрощения кода.

6 часов назад, Zlodey сказал:

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

Ах вижу, что тебе определенно нравятся риторические вопросы, так как прямого метода для выгрузки посекундного лога (с привязкой к тикам движка) в открытом API естественно и ожидаемо, банально нет. Там доступна только та же сводная стата, что и на сайте, а доступа к "соку" сырых логов сервера у нас, опять же совершенно логично, нет. Сваггер просто "выдыхает" ровно то же самое, что уже есть на витрине сервера в готовом виде, но это явно не то, что могло бы пролить свет на то, что и как работает. И поскольку я заранее знаю твой возможный ответ на мой следующий возможный вопрос, то задавать его просто не стану, чтобы не затягивать время и не отвлекать тебя лишний раз.

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

Запусти ДСервер, с лоюбой миссией, полетай и почитай логи. Почему тебе должны с других серверов логи давать?

Ты даже можешь из одиночной миссии получить логи. Там плюс/минус будет все одно и тоже.

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

"хронология", которую мы все видим - это не то чтобы объективный лог сервера,

Не правильно. Это объективный лог. Я же сказал - порядок остается тем, который есть в журнале вылета. То, что там будет время записано относительно других событий не верное, так это не важно. Важна последовательность.

2 минуты назад, Zlodey сказал:

Запусти ДСервер, с лоюбой миссией, полетай и почитай логи. Почему тебе должны с других серверов логи давать?

Ты даже можешь из одиночной миссии получить логи. Там плюс/минус будет все одно и тоже.

Не правильно. Это объективный лог. Я же сказал - порядок остается тем, который есть в журнале вылета. То, что там будет время записано относительно других событий не верное, так это не важно. Важна последовательность.

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

Предлагать мне запустить свой сервер для проверки логично, но это лишь подтвердит, что на своем сервере я получу свои логи, а не те, что выдает ваш API. Разница в том, как именно ваша система парсит и выдает эти данные наружу. Не злись, я уже разобрался. Как я и говорил, "вопросов по архитектуре системы стало меньше". А твой ответ про "неважность времени" лишь подтвердил мои догадки о том, как это работает.

...И последнее: не воспринимай это как критику кода, я пишу это как перфекционист, который болеет за UX проекта. Обиды и ссоры - это контрпродуктивная шелуха, которая только мешает достигать цели, а цель - это твой проект, максимально привлекательный, интуитивно простой и доступный любому пользователю.

Сейчас лента событий выглядит перегруженной: когда урон по одной цели или пожар двигателя размазывается на десятки строк, визуальная составляющая теряется. Когда я вижу "километровую ленту" сообщений, возникает неопределенность: я нанес этот урон одной цели или "накрыл" осколками сразу десяток?

ИМХО, было бы значительно удобнее, если бы логирование учитывало группировку событий:
Сведение урона: если урон наносится одной цели в одном временном окне - логичнее суммировать его в одну строку.
Идентификация: если целей несколько - критически важно видеть их индексы/ID для понимания масштаба воздействия.
Фильтр "наводнения": длительные события (вроде пожара) лучше выводить как сводное событие, а не как поток однотипных записей.

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

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

Сведение урона: если урон наносится одной цели в одном временном окне - логичнее суммировать его в одну строку.

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

Фильтры событий есть в преме.

Статистика без према - сделана как обычная статистика, доступная каждому.

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

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

Нет! Сколько раз можно повторять? Последовательность сохраняется! Какая последовательность в логе сервера - такая последовательность и будет в журнале.

7 минут назад, Zlodey сказал:

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

Фильтры событий есть в преме.

Статистика без према - сделана как обычная статистика, доступная каждому.

Остап явственно понимал, что оппонент пошёл на удушающий, он принялся давить на святое, в самый центр его жадности ... эта пытка была, невыносима. Оказалось, что-то всё чего он так давно и страстно желал было уже доступно, стоило ему только раздобыть достаточно денег на донат... Как, всё-таки жаль его, бродягу, мечтающего о Рио-де-Жанейро. Мечтам не всегда положено сбыться. Заседание можно считать закрытым, граждане присяжные и заседатели. Расходимся.

P.S.: Тему можем закрывать в архив, для благодарных потомков.

Edited March 10Mar 10 by Matpocob