Всё о разбросе

[KPOT2338]

22 Май 2016 - 23:25 пользователь Galaxy_Plus сказал:

Для арты для орудия V^2/g=const. Если V снарядов разные, то и g разные.

V1^2/g1=V2^2/g2

Это правило выполняется при изменении скоростей снарядов арты.

 

У всех танков g=9.81.  При  переключении снарядов с разными скоростями на танках, автоматически меняется возвышение ствола для той же точки прицеливания.

Kolohousenka при прицеливании в стенку на высоте примерно 1м и расстоянии 300м при ББ имеет абсолютный угол возвышения 0.16 град, при OФ - 1.4 град, на голде 0.03 град.

То есть, углы у танков почти не меняются и траектории почти прямая, по сравнению с артой. Но время полета меняется в разы: ОФ на 300м - 1.5 сек, ББ - 0.6 сек.

 

 

Так всё-таки меняется угол возвышения ствола или точка прицеливания?

[Galaxy_Plus]

Координаты маркера прицела неизменны, а угол возвышения меняется при смене снаряда. Значение разброса при этом тоже неизменно.

[Galaxy_Plus]

За выходные настрелял восемь сотен выстрелов на CУ-26 с углом возвышения 42.0 градуса. Данные пока не обрабатывал, но на глаз Баг Поперечного Сжатия Разброса хорошо виден - в крайние правые и левые четверти радиуса зоны  сведения снаряды вообще не попадают. Хочу настрелять две с половиной тысячи выстрелов, чтобы избежать возражений разработчиков о недостаточной статистике. 

Измеритель выполняет свою функцию отлично. Единственное неудобство - это невозможность задать точную задержку после события при записи лога.

Если записывать данные в момент выстрела, то пропадает значение первого выстрела, ибо в этот момент снаряд ещё не долетел.

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

В условие записи лога, что в скобках, хорошо бы ввести значение задержки момента записи от указанного события, например. %ShotCount%+14.5

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

Изменено 23 мая, 2016 пользователем Galaxy_Plus

[anonym_prvu9rSvc3J0]

23 Май 2016 - 10:00 пользователь Galaxy_Plus сказал:

 

Измеритель выполняет свою функцию отлично. Единственное неудобство - это невозможность задать точную задержку после события при записи лога.

 

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

[Galaxy_Plus]

23 Май 2016 - 16:31 пользователь Med433 сказал:

 

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

 

Это называется предзапись регистратора. В измерителе этого сейчас нет и реализовать это сложнее, чем задержку записи после события. При выстреле сейчас записывается не размер круга разброса ДО выстрела, а уже успевший разлететься круг разброса. Чтобы записать исходный, нужно запомнить его за некоторое время ДО выстрела. За какое?

Это неочевидный вопрос, так что время предзаписи тоже придется задавать. 

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

 

 

 

[anonym_prvu9rSvc3J0]

23 Май 2016 - 16:40 пользователь Galaxy_Plus сказал:

 

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

 

 

Если ты хочешь о баге доложить, то да, ты прав. А если хочется поподробнее промерить распределение, то понятно да?

[Galaxy_Plus]

 

Экспериментальный план:

В эти выходные закончу настрел арты под углом 42 градуса для баг-репорта по Багу Поперечного Сжатия Разброса.

До патча сделал примерно 1100 выстрелов, хочу довести до 2500.

Потом сделаю такой же настрел арты под 30 градусов.

И попробую сделать под углом 47-48 градусов, что трудно.

Потом промерю текущую экспериментальную зависимость поперечного размера КРУГА СВЕДЕНИЯ  арты от угла на ровной дороге во всем диапазоне углов возвышения арты, от горизонтали до вертикали.

Потом сделаю серию экспериментов для танковых орудий, хочу использовать в тестах немецкую ПТ с ТТХ угла возвышения 85 градусов, есть одна такая.

Сначала промерю экспериментальную зависимость поперечного размера круга сведения ПТ от расстояния при горизонтальном орудии, а потом этот размер от угла возвышения орудия.

И сделаю две серии настрелов для измерения поперечного разброса попаданий ПТ - при угле 42 градуса и при угле 48 градусов.

Эта совокупность экспериментов однозначно покажет существование БПСР и даст информацию разработчикам о его возможной причине.

 

Мод измерителя от 0.9.14 в 0.9.15 работает. Для вышеперечисленных экспериментов его функциональности достаточно.

В перспективе моду не хватает вывода значения нанесенного при выстреле урона для экспериментов по распределению урона.

 

 

Изменено 27 мая, 2016 пользователем Galaxy_Plus

[HellQwer]

Так есть же отдельный мод с логированием урона. http://www.koreanrandom.com/forum/topic/27695-

[Galaxy_Plus]

А, посмотрел. Да, использовать можно, но для моих целей не слишком удобно.

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

Мне же нужны абсолютные числа урона по врагу, по одной цели, причем без уничтожения и пожаров.

Удобнее один мод, а не два, да и лишние действия с конвертированием в Excel.

Ещё один измеряемый параметр "дамаг" в Измерителе мне казалось более понятным решением, чем другой мод.  

Изменено 27 мая, 2016 пользователем Galaxy_Plus

[anonym_prvu9rSvc3J0]

27 Май 2016 - 10:28 пользователь Galaxy_Plus сказал:

Эта совокупность экспериментов однозначно покажет существование БПСР и даст информацию разработчикам о его возможной причине.

 

 

Разработчику хватило бы одного рисунка: отрисовываемый эллипс сведения со всеми декальками попаданий. И формулировки: уберите лишний косинус. А тем мэнэджерам, которым ты свои эксперименты собираешься показать, от этих данных просто поплохеет

[StranikS_Scan]

27 Май 2016 - 20:38 пользователь Med433 сказал:

 

Разработчику хватило бы одного рисунка: отрисовываемый эллипс сведения со всеми декальками попаданий. И формулировки: уберите лишний косинус. А тем мэнэджерам, которым ты свои эксперименты собираешься показать, от этих данных просто поплохеет

 

Мёд, ты не зришь в корень, я Гэлэкси об этом не говорю, но разработчик отлично знает про косинус, ибо он его и спецом добавил ))))) Так что 

[anonym_prvu9rSvc3J0]

27 Май 2016 - 19:56 пользователь StranikS_Scan сказал:

 

Мёд, ты не зришь в корень, я Гэлэкси об этом не говорю, но разработчик отлично знает про косинус, ибо он его и спецом добавил ))))) Так что 

 

Таки чтобы зреть подобным образом, нужны специальные окуляры, ибо как я ничего не понял

[KPOT2338]

27 Май 2016 - 20:56 пользователь StranikS_Scan сказал:

 

Мёд, ты не зришь в корень, я Гэлэкси об этом не говорю, но разработчик отлично знает про косинус, ибо он его и спецом добавил ))))) Так что 

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

А главное - это практически незаметно.

Вывод: Злоупотребление служебным положением.

Изменено 27 мая, 2016 пользователем KPOT2338

[anonym_prvu9rSvc3J0]

А, вы вон про что. Я-то уже испугался, что в корень зреть разучился.

[anonym_prvu9rSvc3J0]

Слышьте, а танковый раработчик своим уменьшил круг более чем в два раза, по обеим осям. Не справедливо!

 

[HellQwer]

Интересно, вот достучишься, баг исправят и арте же никак не компенсирует? Как оставили без компенсации танки после исправления бага с задним ходом, например. Или у них там геартолобби?

28 Май 2016 - 00:40 пользователь Med433 сказал:

по обеим осям.

Хм, был уверен, что по одной...

Изменено 27 мая, 2016 пользователем HellQwer

[KPOT2338]

27 Май 2016 - 21:40 пользователь Med433 сказал:

Слышьте, а танковый раработчик своим уменьшил круг более чем в два раза, по обеим осям. Не справедливо!

А я что-то упустил.

У арты в ПТ режиме разброс по всему кругу?

[anonym_prvu9rSvc3J0]

27 Май 2016 - 20:47 пользователь HellQwer сказал:

Интересно, вот достучишься, баг исправят и арте же никак не компенсирует? Как оставили без компенсации танки после исправления бага с задним ходом, например. Или у них там геартолобби?

 

Из кустов можно уезжать передом, а заезжать задом. На RU251 это, правда, не удобно

 

27 Май 2016 - 20:48 пользователь KPOT2338 сказал:

А я что-то упустил.

У арты в ПТ режиме разброс по всему кругу?

 

Вот ты спросил так спросил. Не знаю.

[KPOT2338]

27 Май 2016 - 21:47 пользователь HellQwer сказал:

Хм, был уверен, что по одной...

Ты похоже не понял, что речь про танковый прицел, который в ~2,3 раза больше круга разброса.

А по одной оси это у арты в артприцеле.

[Galaxy_Plus]

Ну вы тут развили теорию заговора, в пору массовое производство фольгированных головных уборов налаживать...

Вышеупомянутые действия разработчиков зарезаются принципом Бритвы Хэнлона.

Всё проще - разработчики не видят ОШИБКУ в своем алгоритме. Они строят башенку из кирпичиков, которые точно стыкуются друг с другом, они осматривают каждое место стыковки и не находят ошибок. Но башенка-то перекошена! Хотя стоит.

Почитайте багрепорт двухгодичной давности #6122: https://bugs.wargaming.net/issues/6122

Пользователь сказал:

Так. С этим вопросом разобрались, да. Полностью.

Подняли результаты тестов механизма, списались с авторами кода (и перепроверили код заодно).

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

Ошибка отсутствует.

Они честно с лупой проверили все стыки кирпичиков, и не нашли брака. Всё состыковано прочно. С их точки зрения. С лупой. А отойти и увидеть с другой точки, что башенка наклонена, они не смогли по психологическим причинам. Я представляю, что у них там матричные операции с объектами и в алгоритме сам черт ногу сломит. Они запутали его "костылями", связанными с ограничением траекторий настильными.

 

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

Баг действует на все пушки во всех режимах. И на ПТ режим арты в том числе.