[Эффективность по танку / Per-vehicle efficiency / TEFF]

[NikolayHAOS]

Поставил до 20.

Странно.

МОбыть мы говорим о разных вещах :)

Я так понял что Вы с demon2597, обсуждали параметр

Динамический цвет по эффективности на текущем танке (xvm-stat)

Если нет, то тада я ошибся, если да то в тестовом редакторе больше 10 поставить не могу.

 

Посмотрел конфиг, Демона, не.., точно вы обсуждали этот параметр,

З.Ы. В редакторе не работает :)

Edited December 11, 2012 by NikolayHAOS

[KPOXA3ABP]

На правах бреда: а что если раз в неделю прочситывать на сервере рейтинг мастерства на танке (по аналогии с КВГшным - 1-9: игрок лучше чем 10%->90%, ну и плюс M - "Мастер": лучше 99%) и сравнивать его с высчитанным на клиенте. Или я ошибаюсь и сейчас на клиенте таких расчётов не ведётся ? Ну тогда распределить расчёты в рамках существующей кл/серв модели. Смысл в том, чтоб не пытаться найти баланс среди абсолютных значений, а оперировать сравнительными.

[sirmax]

Странно.

МОбыть мы говорим о разных вещах :)

Я так понял что Вы с demon2597, обсуждали параметр

Динамический цвет по эффективности на текущем танке (xvm-stat)

Если нет, то тада я ошибся, если да то в тестовом редакторе больше 10 поставить не могу.

 

Посмотрел конфиг, Демона, не.., точно вы обсуждали этот параметр,

З.Ы. В редакторе не работает :)

редактор еще не обновлял

 

Ну для обычной эффективности же стоит 9999, никого вроде не колбасит:) Нормально будет. Ну можно вообще по аналогии ткнуть 99 тогда

просто в редакторе это не очень будет выглядеть.

 

На правах бреда: а что если раз в неделю прочситывать на сервере рейтинг мастерства на танке (по аналогии с КВГшным - 1-9: игрок лучше чем 10%->90%, ну и плюс M - "Мастер": лучше 99%) и сравнивать его с высчитанным на клиенте. Или я ошибаюсь и сейчас на клиенте таких расчётов не ведётся ? Ну тогда распределить расчёты в рамках существующей кл/серв модели. Смысл в том, чтоб не пытаться найти баланс среди абсолютных значений, а оперировать сравнительными.

в итоге примерно так и будет. пока что надо формулу отладить.

[KPOXA3ABP]

в итоге примерно так и будет. пока что надо формулу отладить.

 

Значит я зря прибеднялся фразой "на правах бреда". Мне как раз это и казалось логическим продолжением просчёта танкового КПД.

[Roisin]

Я тут подумал, искать максимум все-таки не совсем правильно. Нужно выбрать средний топ, чтобы сгладить случайные пики. Мало ли КВГ кому-то рейтинг накрутит. :)

Тоже так думаю, еще перед усреднением надо откинуть 'выбросы' : например смотрим по танку топ-5 дамагеров: 100, 102, 103, 105, 115. Вот 115 надо исключить.

Но вообще не факт, что выбросы будут.

[sirmax]

Проблема в том, что мы используем NoSQL БД mongodb, она под аналитику, мягко говоря, не заточена. Например, чтобы посчитать сумму, нужно обработать все записи и на JS в скрипте собирать нужные данные. Даже этот маленький скриптик на незагруженной системе работает 4 часа.

Для аналитики, которая требуется в этой задаче необходима OLAP система, тем более что данные необходимо считать постоянно. Предлагаю пока серьезную аналитику не затрагивать. Я планировал в следующем году поиграться на работе с EMC/GreenPlum, вот, на этих данных и обкатаю. Собственно, XVM для меня сейчас и является тестовой площадкой для отладки решений, которые мы потом внедряем (или отказываемся) в корпорации.

[fakels]

дайте ссылку на последний тестовый XVM, немогу найти где скачать.

[13]

@fakels, тестовых версий XVM на данный момент нет. Самая новая версия всегда доступна по этой ссылке, можете добавить в закладки и отслеживать появление новых версий(включая тестовые) в левой колонке.

[kashbessm]

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

уже выкатывал имхо, но чего-то отмахнулись..

 

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

верно, хороший свет тоже может быть убит, сделав отлично работу. но!

если посмотреть на выживаемость хорошего света ~ 20% и ололошного ~ 4-6%? то думаю, что как раз влияние этого параметра и расслоит ЛТ по эффективности.

[sirmax]

уже выкатывал имхо, но чего-то отмахнулись..

 

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

верно, хороший свет тоже может быть убит, сделав отлично работу. но!

если посмотреть на выживаемость хорошего света ~ 20% и ололошного ~ 4-6%? то думаю, что как раз влияние этого параметра и расслоит ЛТ по эффективности.

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

[TurinDeNar]

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

sirmax,а вот сейчас в послебоевой статистике отображается расстояние пройденное танком в бою. А эти данные... их никак нельзя вытянуть из статистики? Выживаемость для светляка, который априори смертник очень спорный показатель, можно просидеть весь бой в кустах изображая из себя ПТ и иметь очень хороший процент выживаемости (правда и засвета в этом случае не будет). И хороший светляк может отлично светив в течении боя в конце умереть и плохой, который умрет в оло-ло засвете, и ни чем они отличаться не будут по сути. Что хороший светляк, что плохой они все как правило умирают, но вот не каждый хороший светляк накатает много км по карте имея при этом хорошее количество засвеченных врагов. Но наверно среднее количество пройденного пути вытянуть к сожалению невозможно, да?  

[sirmax]

нет, невозможно.

[Roisin]

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

 

Понятно, впрочем те возможности, что есть - эт уже неплохо.

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

 

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

[kashbessm]

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

весьма непросто найти и привести доказательства эмпирической теории ))

кроме эмпирических же.

 

на практике, при выборе светляка в роту по этим двум параметрам, мы очень редко, примерно 1 из 50 оказываемся неудовлетворенными.

 

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

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

 

и да, это действительно попытка слепить б/м адекватный рейтинг света из того что есть.

 

 

P.S.

Ну, и все таки что-то с артой не то. Или не с артой, а топ-танками.

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

 

В игре, ессно, пофиг. Потому что любая шкала дает представление об относительном умении.

Но нормализовать было бы здорово.

Edited December 12, 2012 by kashbessm

[deimos]

Проблема в том, что мы используем NoSQL БД mongodb, она под аналитику, мягко говоря, не заточена. Например, чтобы посчитать сумму, нужно обработать все записи и на JS в скрипте собирать нужные данные. Даже этот маленький скриптик на незагруженной системе работает 4 часа.

Для аналитики, которая требуется в этой задаче необходима OLAP система, тем более что данные необходимо считать постоянно. Предлагаю пока серьезную аналитику не затрагивать. Я планировал в следующем году поиграться на работе с EMC/GreenPlum, вот, на этих данных и обкатаю. Собственно, XVM для меня сейчас и является тестовой площадкой для отладки решений, которые мы потом внедряем (или отказываемся) в корпорации.

Я так понимаю, что сервер сейчас один и нагрузку по вычислениям с помощью map-reduce не распределяете?

[sirmax]

шардинг настроен, но нода одна, соответственно, map-reduce не нужен.

Реальная польза от шардинга и map-reduce появится, начиная минимум с 4х серверов - два продуктива + 2 реплики, иначе система получается ненадежной, и пропадание связи с одним из серверов ломает весь сервис.

[deimos]

Это понятно, я просто к чему... у меня есть возможность предоставлять временные вычислительные мощности. Понятно, что для обслуживания клиентов не подойдет, но обсчитывать интересные срезы раз в неделю, может заинтересует.

[sirmax]

Да не, тут больше будет геморроя по выгрузке базы. У нас по процу проблем нет - загрузка до 10%. Самое узкое место - это винт, а тут ничем удаленно не помочь.

[13]

Макс, а сколько там приблизительно база весит и с какой скоростью расширяется? Может есть смысл взять SSD, если в объём и темп укладывается? (из цен вычитаем 19%, ессно).

[deimos]

Да не, тут больше будет геморроя по выгрузке базы. У нас по процу проблем нет - загрузка до 10%. Самое узкое место - это винт, а тут ничем удаленно не помочь.

А какой объем базы?