Storan

Хорошо, немного теории. Все рейтинги WoT, если считать рейтинг некой шкалой отображающий игровой скилл — имеют просто гигантскую погрешность. И связано это не с косорукостью или неграмотностью авторов рейтингов, а с концепцией игры и игровой статистики проповедуемыми самими WG. Раз. Понятно что задротство и взводное задротсво (+ к онлайну), прем-аккаунт, прем-танки, пропуск веток прокачки, экипаж на стероидах и сербоголда в боях — для компании идеальные пользователи приносящие доход, и игровые награды всё это поощряют; тут проблем нет — умеют так зарабатывать их право. Проблема в том, что WG многое из этого ещё и впихивает в статистику, причём так что внешние наблюдатели никак отсортировать/отключить сие не могут — с самого начала у нас неполная, и местами не вполне корректная статистика. Два, со старта игры, уже выпущено несколько десятков обновлений, которые очень, очень сильно меняли гемплей, превращая весь раннее набранный массив данных по игрокам в кучу хлама, годную разве что для выдачи ачивок, но никак не для оценки эффективности. Актуальный реальности рейтинг может быть основан только на данных начиная с последнего большого патча и точка (недаром, во многих киберспортивных дисциплинах команды начинают сезон на турнирном клиенте который по версии сопоставим с збт «из будущего» общеигрового, а заканчивают сезон каким-нибудь ЧМ уже отставая на патч-другой «из прошлого» от общеигровых серверов — всё ради как можно меньших правок баланса за профсезон). Три, практически нереально вытянуть объективные данные о навыке, даже из супер-полного набора чисел, если статистика этих чисел никак не учитывает в каких по уровню навыка боях эти числа были получены. Человеческим языком — рандомный принцип балансировки команд в WoT (понятно, что речь об игроках, а не об их технике) — вот главное и неустранимое препятствие для разумной оценки навыков игрока. И это не шутка, у таких игровых флагманов как Valve или Microsoft в отделах разрабатывающие многопользовательские онлайн рейтинги профессора математики сидят. Лучшие из модельных результатов рассчитывающие приближение рейтинг_вычисленный = рейтинг_реальный, для случайных составов команд, перемешивающихся от сессии к сессии — требуют многие десятки матчей, при том что команды и их члены каждый раз подбираются по примерно равным текущим рейтингам — без последнего условия, эффективность просто хуже на порядки (считай необходимы уже тысячи матчей. модельные «тупые» ии-боты, конечно могут и миллион междусобойных матчей отыграть с заданным скиллом и в неизменном «окружении», а для реальных людей и несколько сотен уже разумеется утопия недостижимая). Естественно, большинство игроделов не особо заморачиваясь с подобным, реализуют принцип перезапуска «сезонов», где сбор плюшек и ачивок за текущий сезон это некий симбиоз времязатрат выраженный формулой рандом×тупость_игрока. Из вышесказанного, повторю вывод от предыдущего сообщения. Если играешь ради циферок какого-либо рейтинга, не ломай себе мозг, и просто играй на том и так, что в данный момент с твоим стилем игры даёт наибольшую добавку для циферок данного рейтинга. Это самый правильный и эффективный путь в рамках заданных условий. Также можно немного сменить тактику, и менять по-необходимости рейтинги, выбирая более удачный для себя в данный момент.

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

Извиняюсь за долгое молчание. Да, с B0 и R0 опечатка. Наверно мы по-разному понимаем продолжительность этого самого "периода". Если имеется в виду игровая сессия, день, несколько дней - то правда ваша. Но если под периодом понимать последние месяцы/полгода - тогда, например для wn8, каждый раз когда разработчики рейтинга меняют таблицы средних значений техники - нужно будет сбрасывать до первой (нулевой) итерации и весь рейтинг за период. После такого обновления новое значение wn8 - это не просто следующее и уточненое. При этом ещё и все старые значения wn8 одномоментно становятся неверными и ошибочными. По сути рейтинг начинает высчитываться по новой формуле. Да, вид у неё точно такой же как у всех предшествующих, но числовые коэффициенты - стали другими. Берём любое слагаемое wn8, (упрощено, без минимаксов и нормализации): 210*rDAMAGE*rFRAG = 210*(avgDmg / expDmg)*(avgFrag / expFrag) = 210.0/(expDmg*expFrag) * avgDmg * avgFrag. средние урон и фраги - это x1 и x2, переменные которые закономерно изменяются и от игрока к игроку и влюяют на само значение wn8. Но вот 210 деленое на ожидаемый урон и ожидаемые фраги - это просто числовой коэффициент, и как только он изменился (при обновлении табличных средних значений) - формула стала другой. Вчера считали Y(x1,x2) = 0.025*x1*x2, сегодня стали считать Y(x1,x2) = 0.017*x1*x2; все старые добытые при ".025" значения Y для нас теперь попросту не имеют смысла, а х... мы не храним, потому что затратно. Значит нужно смирится с тем, что у рейтинга за период обнулилась память.

Существует одна проблема, для рейтингов вроде WN8, где показатель рейтинга не абсолютный, а рассчитывается от сравнения со средними значаниями по танкам. Там не удасться отделаться "лёгкой формулой" S1 = S0*a + r*(1-a), так как после пересчета эталонных средних самого wn8 - у всех игроков корректируется и "старое" значение B0. Вопли грилеводов, у которых "своровали" их рейтинг в конце июня ещё свежи в памяти. Примитивный и условный пример. Катал челове на имбах, набил wn8 1500, суммарно у него 10к боёв. Мы запомнили id_игрока, количество_боёв, значение_wn8 (B0 = 10k, S0=1500). Происходит перерасчёт в wn8, выясняется (в самом рейтинге) что у данного игрока реальный wn8 1200, затем откатывает он ещё десятку (просто 10 раз) боёв, строго на свои законные ~1200, видит новые катастрофичные 1200, и удаляет танки на неделю. А мы делая текущий срез и в итоге получаем откровенную фигню r=(R1*B1-R0*B0)/(B1-B0)=(1200*10'010-1500*10'000)/10= -299k Ограничение значений r будет костылем, и скорее всего неудобным. Ведь в следствие "памяти" у скользящего среднего единожды запомненный некоректный B0 за каждую итеррацию будет менятся очень незначительно, и создавать ту же самую проблему и в шагах i+1, i+2, i+3, ...

Управление тут для аркады действительно лучше чем у WoWP от варгеймингов. Но вот экономика: Самолёты не правят по характеристикам. Нагибаторов - калибруют ремонтом, за среднее фраго-сбитие. В итоге - если ты ас/вирпил/ - летай на чём хочешь, веселись и радуйся жизни. Если ты просто опытный - с премом летаешь почти на всём без проблем, на самых успешных крафтах будешь уходить в минус, причём почти гарантировано. Проблемы появляются у обычных/нубоватых игроков - хоть как рви жопу, но минимум на ~половине крафтов будешь уходить в глубокий минус, включен ли у тебя премиум, нет - значения не имеет. И текущий статус беты это никак не микширует. Сам принцип не раз подтверждался администорами и разрабами - зарабатывающие крафты будут по-прежнему много зарабатывать, но увеличивать свою цену ремонта - и принцип только и поддерживают эту губительную тенденцию - играешь хорошо, летай на всём, хочешь платить но играешь средне/плохо - страдай и плачь.

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

Особенного вроде ничего нет, при стрельбе по дистанции близкой к максимальной, как раз крутейшая ("вертикальная") траектория и получается. Хотя нюанс есть, для разных пушек разная "кривизна" самой траектории (не путать с начальной скоростью снаряда). Вот пояснения Серба: / http://forum.worldoftanks.ru/index.php?/topic/245932-%d0%b2%d0%be%d0%bf%d1%80%d0%be%d1%81%d1%8b-%d1%80%d0%b0%d0%b7%d1%80%d0%b0%d0%b1%d0%be%d1%82%d1%87%d0%b8%d0%ba%d0%b0%d0%bc-7/page__st__1020__pid__14779652#entry14779652 / Соответственно, чем больше g пушки - тем лучше арта закидывает за препятствия. Но насколько я знаю, в общем доступе такие измерения ни разу не проводились/не опубликовывались.

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

А можно ли в хитлоге как-то определить количество просто выстрелов/попаданий, и под эти величины макросы сделать?

стояла rc2, но почему-то не информировала что устаревшая. Сейчас rc4 поставлю, посмотрю на реакцию.

[003] ERROR: vehicle info (3) missed: T71. Please notify XVM support. xvm-stat вот такую строчку в окне выдает. Саму лт в бою нормально при этом показывает, и все шансы на победу вычисляет

Собственно вместо 0 пустое место, как-то непривычно. Уши ведь в последних модификациях не меняли, что это может быть? XVM.xvmconf

При начислении опыты ещё учитывается разница в уровнях. Числа "от балды", чтоб принцип пояснить: 500 урона от 6 лвл по 8-му, равнозначны 1000 урона от 8 лвл по 6-левельным. Выдавали бы сервера "честный" опыт без према по стате - действительно лучший бы синтетический "к-т эффективности" получился. А вообще, все эти получаемые параметры - они как-то отсекают старые данные? Тот же нелюбимый почему-то % побед - он ведь "врет" считай из-за того, что либо данных мало, либо когда объём уже приличный всё ещё лежат грузом бои х-летней давности. Какая разница по какой формуле считать, если учитывать все данные, и когда игрок "имярек" в лохматом 2010 году считал что светить - это газ до упора и кратчайшим путём на базу врага, и когда сейчас из 261 бб-шками на лету французов лопает допустим.

всё, поигрался двоеточиями и нашел правильный путь: <img src='img://../folder/image.png' /> - указывает на папку folder находящуюся в res_mods, и там на изображение image.png; имхо удобнее для конфига в отдельную папку все положить, чтоб с каждым патчем не таскать картинки из 0.8.х в 0.8.х+

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

Думаю проще всего картинки в любом графическом редакторе (стандартный примитивный paint из windows хотя бы) под один нужный размер подогнать, и не мучиться в конфиге с width, height, align p.s. заодно подскажите, можно ли такой путь в теге img указать, чтобы из папки "\res_mods\images" изображения подхватывались?

Тут я совсем запутался. Разве эти настройки "public static var damage_mapping:Object = {....} " не будут зашиты в коде? Т.е. в конфиге я могу назначить цвета (шрифты) "me" - малиновый (курсив курьер), а "TeamKiller" - бирзовый (болд ариал). Но если в коде свои выстрелы всегда обозначены как "me" - значит я не смогу перебиндить варианты свой урон по врагам малиновым, а свой урон по своим на бирюзовым.

А кто-нибудь проверял, как сейчас красится урон от/по совзводного во встроеном отм? Если присутсвует отдельный цвет - то в xvm его убирать как-то странно будет, если совпадает со своим/ просто от союзника - то и здесь можно так же оставить. Я за css. Это на самом деле проще для восприятия, и скорее всего быстрее в обработке парсеру игры. Кто со всем не знает что это такое - аналог, стили из word'a. Сообщение несёт в себе только текст "а-ля" смысл. Оформление - определяется полностью стилями, т.е. оформление отделено от содержания.

Само-повреждение при падении точно кодируется цветами world_collision. Причём поскольку танк сам себя повреждает, и получается что союзники красятся от "ally", враги - от "enemy", совзводники - от "squad" (т. е. в противовес с атакой/тараном/пожаром, где они друг другу урон наносят).

Нашёл свой глюк - у меня 2 секции "colors" образовались из-за глупого copy|paste, из-за этого нестабильность цветов и была... Вопрос. с отдельной раскраской в состоянии "dead" (смертельный выстрел) можно попрощатся? Уважаемые разработчики, и в связи, с возможным вводом настроек анимации/вспышки - повторю запрос, можно ли реализовать "базовое" generic-описание (хотя бы отлетающего урона), вроде такого: "markers": { "basic":{ "damageText":{ "visible": true, "x": 0, "y": -60, "alpha": 100, "color": null, "font":{ "name": "Calibri", "size": 16, "align": "center", "bold": true }, "shadow":{ "alpha": 100, "color": null, "angle": 0, "distance": 0, "size": 9, "strength": 250 }, "speed": 3, "maxRange": 70, "damageMessage": "{{dmg}}", "blowupMessage": "ОП-ПА!" } } } т. е. все элементы которые для любого состояния танка/его принадлежности будут в конфиге неизменны - мы заполняем лишь один раз, в "обобщённом" виде. Для конфиго-составителей, это сильно упростит заполнение повторяющихся полей.

возможные глюки: В 1й альфе свой урон нормально красился жёлтым, в 3й альфе он перестал окрашиваться, и стал белым. (массив dmgTextPalette в colors разумеется перенёс, fire->attack поменял). Плюс один раз увидел пурпурный цвет урона вдалеке - вообще не понял откуда, в матрице такого RgB | R-B нет вообще. Проблема: при новой анимации, с яркими цветами урона/теней, цифр практически не видно, белое пятно появляется на пару секунд, только в цвет окрасилось - уже исчезло. p.s. может кто кинуть ссылкой на "удачный" реплей, чтобы было - по врагам: свой урон, урон от совзводника, урон от команды... от врагов: урон по совзводнику/своим. Плюс чтоб был обоюдный таран в пределах видимости, кто-то подольше горел (желательно от пожара и загнулся чтоб), ну и в довесок самоповреждения у кого-нибуть при падении и накрытие сплешем от арты )))

Имхо, если есть возможность - сделать в этой схеме нечто вроде "наследования" установок. К примеру: ALLDAMAGE# damageText: {"visible":true, "x":X, "y":Y, "alpha":A, "color":"0xCCCCCC", "font":{...}, "shadow":{...}, "speed":S, "maxRange":MR, "damageMessage":"{{dmg}}", "blowupMessage":buM} Дальше дополняем/переопределяем лишь некоторые поля у разных типов урона К примеру: FROM_ENEMY# damageText: {"color":"0xFF0000"} FROM_ALLY# damageText: {"color":"0x00FF00"} FROM_PLAYER# damageText: {"color":"0xFFFF00"} FROM_SQUAD# damageText: {"color":"0x808000"} И на последнем шаге уже дополняем/переопределяем поля из отдельных столбцов таблицы $fire damageText: {"font":{"name":"Webdings", "size":30}, "speed":1, "maxRange":0, "damageMessage":"æ"} $ramming damageText: {"damageMessage":"** {{dmg}} **"} $explosion damageText: {"shadow":{"size":36, "strength":500}} Хотя наврал. Последним шагом может быть переоределение полей уже для конкретной ячейки - пока в голову не приходит для чего это можно сделать, но голь на выдумки хитра - и скорее всего кто-то из авторов конфигов мелкую но приятную фичу и на этом свойстве придумает. к примеру мне очень понравилась идея в конфиге hellraiser'a - инвертирование цветов шрифта/тени для простых пробитий/убийства танков. Реализация простейшая, выглядит эффектно, за обстановкой в бою "по краям взгляда" следить помогает - а на ум не приходило нечто подобное сделать, хоть и пробовал изучать конфиги.

Можно поинтересоваться, эти настройки появилась для xvm.config? И что там с пожаром... Правильно ли я понял, что теперь вместо постоянно отлетающих мелких чисел урона, например просто надпись можно "огонь" выводить (с соответствующим неотдалением во времени)?