StranikS_Scan

Заходишь на сайт. А по умолчанию графики не показывает. Нужно тыкать. Тебе нужно ввести разделение статистики по версии игры. Потому что в каждом новом патче игра по сути новая. И это кстати существенно снизить нагрузку на БД. Ибо все данные в кучу - это средний винегрет на Луне в вакууме. И еще вдогонку - нужно от обобщенных статистик, которые один раз посмотрел и все на этом, переходить к динамическим статистикам. Нужно выводить и смотреть динамику, что и как происходит с игроками/танками/.... в разрезе боёв, дней, недель, месяцев, патчей игры. Это кстати имеет хоть какую-то практическую пользу. Например можно в клиенте игры в ангаре например выводить инфу, на каком танке например сегодня или сейчас лучше выйти в бой. ----------------------------------------------- Ниже исправленная и отредактированная версия текстов для страницы, а то читать местами сложно и не сразу понятно. Расширенное распределение урона Выберите один вид урона Учитываются выстрелы ББ, БП и КС снарядами по танкам с ХП, превышающим максимальный урон снаряда Описание График расширенного распределения строится исключительно для одного вида урона, поскольку в игре урон принимает только целочисленные значения. Округление урона до целых значений приводит к тому, что при одном и том же разбросе получаются разные графики относительного распределения при разных видах урона. Например, для базового урона в 11 единиц граничные значения 11 - 25% = 8.25 => 8 (минимальное значение в игре) 11 + 25% = 13.75 => 14 (максимальное значение в игре) Это значит, что урон может принять любое значение из дискретного ряда [8, 9, 10, 11, 12, 13, 14], или же [-3, -2, -1, 0, +1, +2, +3] относительно базового урона. Если выполнить нормализацию значений относительно базового урона, то получим ряд [-27%, -18%, -9%, 0%, +9%, +18%, +27%], в котором всего 4 промежуточных значения -18%, -9%, +9%, +18%, а крайние значения -27%, +27% выходят за рамки исходного разброса в 25%. Слияние такого дискретного ряда с графиком, построенным для другого вида урона, например 390, приведет к возникновению аномальных пиков и провалов, что естественно для дискретных случайных величин, но совершенно не характерно для величин с непрерывным распределением. Поэтому для каждого вида урона строится индивидуальный график распределения вероятностей. Граничные значения График распределения строится из центра, таким образом, чтобы базовый урон располагался строго по центру. По этой причине, на графике возможно только нечетное число значений урона в каждом из его столбиков. Из-за особенностей округления крайних значений иногда наблюдаются некратные интервалы. В таких случаях, крайний левый и крайний правый столбики графика могут содержать разное число значений урона. Если вы хотите оценить минимальный и максимальный урон, то выбирайте шаг графика равный 1. Например, для базового урона в 390 единиц при 7 значениях на столбик 390 - 25% => 293 (минимальное значение в игре) 390 + 25% => 488 (максимальное значение в игре) Следовательно, на графике, слева от базового урона будет 390-293=97 возможных значений, а справа 488-390=98, в сумме же будет всего 196 значений. Построить симметричный график относительного базового урона в этом случае невозможно, поэтому на графике центральный столбик будет состоять из 7 значений [387, 388, 389, 390, 391, 392, 393], крайний левый столбик из 3 значений [293, 294, 295], а крайний правый из 4 значений [485, 486, 487, 488]. Пример для урона в 360 единиц 360 - 25% => 270 360 + 25% => 450 Диапазон возможных значений урона [270; 450] и состоит из 181 значения, 90 из которых находится слева от среднего, а еще 90 справа от него, что позволяет построить зеркально симметричный график с шагом в 1 значение на каждый столбик. При распределении урона по столбикам с шагом в 5 значений, получается 17+1+17=35 центральных столбиков по 5 значений в каждом и два крайних столбика по 3 значения в каждом. В этом случае график сохраняет симметрию относительно центральной оси. При этом следует учитывать, что крайние столбики могут содержать меньше значений, чем остальные. Расчет погрешности Погрешность графика распределения зависит от: базового урона BASE_DMG (разная величина ошибки округления) количества выстрелов N с уроном (влияет на достоверность распределения) числа уронов M на столбик (меняется форма дискретного графика) Для определения погрешности искусственно генерируется серия из X «экспериментов» распределения при фиксированных значениях указанных выше параметров, и с их помощью определяется возможный диапазон отклонения значений для исходного графика. Алгоритм расчета погрешности: 1. Первоначально с помощью стандартного генератора псевдослучайных чисел math.random() в JavaScript генерируется N вещественных значений в диапазоне от 0 до 1, включительно. 2. Сгенерированный ряд преобразуется в танковое распределение урона подобное Гауссовскому распределению с диапазоном значений от -1 до +1, включительно. С помощью сплайн интерполяции по 100 значений к функции численно обратной функции распределения урона (CDF) для канонического нормального распределения с коэффициентами a = 0.02399886787, b = -0.006796346129, c = 0.4711312389 в формуле a*exp(-((x-b)/c)^2) 3. Результирующий ряд умножается на 0.25, к каждому значению ряда прибавляется 1, и это все умножается на базовый урон BASE_DMG, после чего итоговые значения ряда округляются до ближайших целых чисел. DMG = round((invCDF(RND) * 0.25 + 1) * BASE_DMG) - формула для расчета урона 4. Значения, полученного ряда, размещаются по столбикам из расчета M значений урона на столбик. 5. Алгоритм выше повторяется X раз, где X - количество «экспериментов», необходимых для расчета погрешности (параметр задается пользователем до начала расчета). 6. По завершении расчетов значения уронов в каждом столбике сортируются по возрастанию, образуя статистические интервалы, которые и определяют возможную погрешность исходного распределения. Доверительный интервал Зная погрешность графика распределения урона, можно построить доверительный интервал с указанием уровня доверия P. Интервал отображается на графике в виде двух огибающих линий, обозначающих нижнюю и верхнюю границы доверительного интервала, между которыми находится P% «экспериментов» из X симуляций. Карточки инфографики Средний урон Арифметическое среднее всех уронов в базе данных (сумма делить на количество) Медианный урон Значение урона, разделяющее все значения на две равные части. Если количество значений четное, медиана представляет собой среднее арифметическое двух центральных значений. Это означает, что половина значений урона меньше медианы, а другая половина — больше. Выстрелов с уроном ниже среднего Рассчитывается как процент выстрелов с уроном ниже среднего по сравнению с выстрелами с уроном выше среднего. Выстрелы с базовым уроном не учитываются. В идеальном распределении этот показатель должен составлять 50%.

Вышло обновление программы 2.2.1 1. Добавлен ключ --sevenzip-dll-file, позволяющий указать путь к пользовательскому файлу 7z.dll при консольном вызове (может быть актуально для модпаков и их установщиков) 2. Добавлен ключ --log-name, позволяющий указать путь и пользовательское имя для файла лога 3. При возникновении проблем доступа к файлам игры или при появлении ошибок записи обработанных файлов на диск, программа будет пытаться несколько раз повторить обработку проблемных файлов. Сообщение об ошибке будет выдаваться только, когда все попытки окажутся безуспешными 4. Добавлена проверка наличия свободного места на диске перед созданием модов 5. Внесены правки и улучшения в интерфейс GUI-версии мода. Добавлена опция параллельного запуска нескольких копий программы для ускорения создания модов (включена по умолчанию)

Глупости не пиши и не будут тебя дурачком называть.

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

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

Никак. Миникарта это скомпилированная флэшка с фиксированным функционалом. Из питона можно только вызывать те маркеры, вызов которых предусмотрен во флэшке. Потому тут либо флэшку надо модифицировать, либо к неё что-то приинжектить. Я во флэшках не разбираюсь, потому подробностей не расскажу. Обратись к протанкам, если их заинтересует твой мод может и с флэшкой помогут. В XVM-моде вроде бы вот эти файлы отвечают за миникарту: xvm_11.0.0_0037_....zip\ lesta\mods\1.25.0.0\com.modxvm.xfw\com.modxvm.xfw.actionscript_11.0.0.0037.wotmod\ res\gui\flash\battle.swf lesta\res_mods\mods\xfw_packages\xvm_battle_minimap\python\minimap.py Однозначно забанят, если твой мод будет в реальном времени показывать игроку куда ему ехать и что ему делать, исходя из текущей обстановки в игре. И скорее всего не забанят, если твой мод будет в начале боя загружать и показывать статически некие рекомендации игроку, основанные на анализе ранее собранных данных. На первых порах можно просто сделать рабочий колхоз, путем вызова стандартных маркеров. Вот есть два красивых маркера, это зеленая лампочка и оранжевый треугольник : Код вот такой: import BigWorld from gui.shared.personality import ServicesLocator from account_helpers.AccountSettings import AccountSettings from gui.Scaleform.daapi.view.battle.shared.minimap import settings, plugins from gui.Scaleform.genConsts.BATTLE_VIEW_ALIASES import BATTLE_VIEW_ALIASES from frameworks.wulf import WindowLayer from Math import Matrix, Vector3, createTranslationMatrix def __calcMarkerScale(self, markerScales, minimapSizeIndex): p = float(minimapSizeIndex - plugins._MINIMAP_MIN_SCALE_INDEX) / float(plugins._MINIMAP_MAX_SCALE_INDEX - plugins._MINIMAP_MIN_SCALE_INDEX) return p * markerScales[0] + (1 - p) * markerScales[1] #Параметры карты boundingBox = BigWorld.player().arena.arenaType.boundingBox x_min, y_min = boundingBox[0] x_max, y_max = boundingBox[1] __mapSize = [abs(x_max - x_min), abs(y_max - y_min)] #Миникарта battle = ServicesLocator.appLoader.getDefBattleApp() __minimap = battle.containerManager.getContainer(WindowLayer.VIEW).getView().components[BATTLE_VIEW_ALIASES.MINIMAP] #Выведем маркер по ценру карты markerPos = (0,0,0) markerType = settings.ENTRY_SYMBOL_NAME.LOCATION_MARKER #Зеленая лампочка #settings.ENTRY_SYMBOL_NAME.ATTENTION_MARKER #Оранжевый треугольник markerEffect = 'reply' #белое свечение внутри #'idle' свечение только контура markerScales = [0.8,1.1] markerOffset = [0,0] #Масштаб маркеров minimapSizeIndex = settings.clampMinimapSizeIndex(AccountSettings.getSettings('minimapSize')) currentScale = __calcMarkerScale(markerScales, minimapSizeIndex) #Формируем матрицы scaleMatrix = Matrix() scaleMatrix.setScale(Vector3(currentScale, 1.0, currentScale)) #Смещение определяется от верхнего левого угла маркера до кончика стрелки и выражается в долях от длины и высоты миникарты, мм #масштаб миникарты при этом не влияет entryMatrix = createTranslationMatrix(markerPos + Vector3(markerOffset[0]*__mapSize[0]*currentScale, 0, markerOffset[1]*__mapSize[1]*currentScale)) entryMatrix.preMultiply(scaleMatrix) __handle = __minimap.addEntry(markerType, settings.CONTAINER_NAME.ICONS, matrix=entryMatrix, active=True, transformProps=settings.TRANSFORM_FLAG.FULL) __minimap.invoke(__handle, 'setState', markerEffect) #Удаляем маркер __minimap.delEntry(__handle)

Ну давай давай

Всё правильно. Танки не должны работать, если мод с ошибкой. Это единственный способ заставить юзвера удалить косячный мод. Никаких других способов это сделать не существует. А если юзверы не будут удалять косячные моды, то наступит Ад для разработчиков модов. try except else finally

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

В клиенте трассер от дульного тормоза строится gunFire, а не от опорной точки пушки gunPoint или gunPos

И вопрос сразу "gunPoint" это gunPoint или gunFire, а?

Это всё хорошо, только пока что пользы нуль. Мозгуйте дальше, нужно искать реальный выхлоп

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

Не даёт. В игре сильно большой рандом, из-за чего % побед у игроков коррелирует только с их средним уроном за бой. Фиолетовый средний урон за бой? Значит и процент побед тоже будет под 70-80%. И наоборот, нет фиолетового урона за бой, тогда и % побед будет в районе 50%. Поэтому всё решает умение игрока делать сверхтоповый урон за каждый бой. Такие игроки не опираются ни на стратегию, ни на тактику. Они катают везде по полю меняя фланги по сто раз за бой, используют имбовую технику с топовым начинкой и применяют, на 200% отработанные и отточенные, игровые приёмы, которые преследуют только одну цель - сверхтоповый урон. А запредельный процент побед - это следствие. Я знаю, как это работает, т.к. когда-то давно смог в фиолет на старом хэлкате. Так что все эти идеи (давно устаревшие) о том, чтобы там предсказать фланг, процент побед, итог боя или еще чего - выкидывай из головы. Это всё не работает. Для 99,99% игроков ответ всегда будет один ~50%.

Осталось самое сложное - найти практическое применение всем эти данным.

А кривую идеального распределения наложить можно?

Там нет вопроса. Вижу только просьбу. Ответ - нет.

Не получится, не пайтановский объект. Тут только скопировать код функции PlayerAvatar.shoot(), продублировать как пользовательскую, вписать в неё свой код перед и/или после self.cell.vehicle_shoot() и затем прописать её как хук PlayerAvatar.shoot()

Все верно, если хукнуть self.cell.vehicle_shoot() и в хуке запоминать time = BigWorld.time(), то в PlayerAvatar.updateGunMarker() можно посчитать реальный тайумаут сервера timeout = BigWorld.time() - time и он будет по факту складываться из времени формирования пакета на ПК, времени отсылки, времени работы сервера, времени отправки ответа и времени расшифровки пакета клиентом игры. А если еще хукнуть __doShot() из vehicle_extras и туда тоже вставить код выше, то можно аналогично вычислять таймаут клиента игры.

Вышло обновление программы 2.2.0 1. Оптимизированы и ускорены алгоритмы обработки файлов и создания wotmod-пакетов 2. Обновлен формат cfg-файлов, введены маски с поддержкой звездочки, файлы проверены и актуализированы под клиент игры 1.24.0.0 3. Внесены правки и улучшения в GUI-версию программы, добавлено окно выбора клиента игры из тех, что установлены на ПК, доработано окно выбора цвета, исправлены ошибки и вылеты при выборе цвета, исправлены опечатки в текстах 4. Файл 7z.dll вынесен из ресурсов exe-файла в папку с программой, при отсутствии файла он будет автоматически скачен с сайта программы 5. Убран код на передачу статистики автору программы, соответственно убран ключ --no-send-statistic 6. Убран ключ --split-2gb-parts, теперь все пакеты объемом более 2 Гб делятся программой на части автоматически 7. Если нет файлов для обработки, то пустые wotmod-пакеты не создаются 8. Добавлена вставка файла properties.xml в wotmod-пакеты, он содержит информацию о версии пакета, мода, игры и опциях, с которыми мод был создан 9. Добавлен ключ --downsizing-ratio для уменьшения размеров текстур камуфляжей и ускорения их обработки, поддерживаются коэффициенты сжатия 2, 4 и 8 10. Добавлен ключ --rewrite-log, для перезаписи лог-файла

Клиентское сведение живет своей жизнью и синхронизируется с сервером только, когда прилетает вызов PlayerAvatar.updateGunMarker(). Потому лучше его хукать, так надежнее, а не VehicleGunRotator.setShotPosition(). Сервер присылает в updateGunMarker() реальную величину тангенса угла разброса dispersionAngle, которая вписывается в первую ячейку переменной-массива VehicleGunRotator.__dispersionAngles[0] и тем самым заменяет клиентский тангенс угла разброса на серверный с последующим вызовом перерисовки сведения через PlayerAvatar.inputHandler.updateClientGunMarker(). Все остальное время клиент перерисовывает сведение путем периодического вызова функций VehicleGunRotator.__rotate() и за ней VehicleGunRotator.__updateGunMarker() в цикле VehicleGunRotator.__onTick c общим тиком 0.1 сек. При этом первая функция нужна для пересчета значения переменной VehicleGunRotator.__dispersionAngles с учетом динамики танка, а вторая - для непосредственной отрисовки сведения. Пересчет VehicleGunRotator.__dispersionAngles выполняется путем вызова функции PlayerAvatar.getOwnVehicleShotDispersionAngle(). В ней с помощью коэффициентов-модификаторов разброса и клиентских значения скоростей вращения башни и движения и вращения корпуса танка высчитывается текущее значение клиентского тангенса угла разброса. У этой функции есть входящий аргумент withShot, принимающий два значения либо "0", либо "1". Если вызов с единицей, то разброс будет пересчитан, как для выстрелившего орудия, т.е. будет применен соответствующий модификатор. Еще есть значение "2", что соответствует модификатору разброса при серии выстрелов. Вызов PlayerAvatar.getOwnVehicleShotDispersionAngle() с ненулевым withShot прописан только в одном месте клиента игры, это функция __doShot() в модуле vehicle_extras. Срабатывает эта функция при вызове функции showShooting() в модуле Vehicle. А его делает функция PlayerAvatar.__showTimedOutShooting() таймера-колбэка, который запускается через функцию PlayerAvatar.__startWaitingForShot(), которая вызывается внутри функции PlayerAvatar.shoot(), срабатывающей, когда юзвер жмет на кнопку выстрела. Задержка у таймера-колбэка задается вот таким образом: timeout = BigWorld.LatencyInfo().value[3] * 0.5 timeout = min(_SHOT_WAITING_MAX_TIMEOUT, timeout) timeout = max(_SHOT_WAITING_MIN_TIMEOUT, timeout) берется половина значения сглаженного пинга Ping/2 и накладывается ограничение в виде диапазона [0,12...0,2] сек (границы прописаны как константы прямо в модуле). Так как у большинства игроков пинг явно меньше 240 мс, то получаем таймер на 120 мс. Что же касается сервера, то команда выстрела на сервер уходит внутри функции PlayerAvatar.shoot() через нативный вызов self.cell.vehicle_shoot(), расположенный перед вызовом функции __startWaitingForShot() ---------------------------- Таким образом, при нажатии кнопки выстрела на сервер улетает команда выстрела, сервер обрабатывает её, делает выстрел и присылает новый тангенс угла разброса уже с учетом выстрела и на всё это у него уходит T1 = 2*Ping+ServerTime времени, а клиент с момента нажатия кнопки выстрела ждет T2 = 120 мс и затем сам пересчитывает тангенс угла разброса и перерисовывает сведение с учетом выстрела. Как результат, если окажется, что T1<<T2, то серверный разброс отреагирует раньше на выстрел чем клиентский, а если Т1>>T2, то клиентский разброс отреагирует на выстрел раньше серверного. Классическая проблема синхронизации клиент-сервер.

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

Не понял, ты про api лесты? Всё есть как и у ВГ и работает. Заходи в личный кабинет и внизу ссылка на кабинет разработчика И там создаешь аккаунт доступа для своего приложения/сервера и получаешь ключ XXXX для запросов к https://api.tanki.su/wgn/servers/info/?application_id=XXXX&game=wot Если у тебя сервер, то указываешь его IP-адреса и доступ будет разрешен только с них. Так XVM данные получает. У ВГ на сайте такой же механизм сделан, только у него свой api сервис https://api.worldoftanks.eu/wgn/servers/info/?application_id=XXXX&game=wot ================================================== А я максимум вот такое смог сделать https://straniks.ru/pub/api/v2/wot_online.php?online=all. Штатная БД, какая была из коробки, и ПХП. На ПХП мне понравилось писать. А вот фронтэнд я до сих пор не осилил, всё хочу прикрутить график реального времени и всё руки не доходят разобраться как это делается.

Можешь убирать их, у них нет своей механики, они выделены только на уровне интерфейсной части клиента игры. ARMOR_PIERCING_HE это ARMOR_PIERCING, а FLAME это HIGH_EXPLOSIVE

Что за БК и ОС?