Автору конечно виднее , но раньше в версии 059 не было мгновенного выстрела после захвата цели .
И с тем и с этим вариантом уже немало пострелял , так что это уже объективное мнение .
З.Ы. Причём настройками это не поправишь - пытался подсунуть файл ранней версии без толку .
1. Это работает для любых целей (подвижных и динамичных). Само срабатывание захвата катка зависит от настроенного расстояния в конфиге - параметр
<!-- Расстояние до цели с которого по функц.клавише захватываются катки (гусеницы) -->
<!-- цель при этом должна быть в автозахвате -->
<chassisDist>100.0</chassisDist>
т.е. ближе установленного расстояния при условии, что цель захвачена и зажата функц.клав. будет захватываться ближайший каток.
2. Да, исправлено. Два недавних поста посвящены этому вопросу (#3682, #3685)
Это не так. Возможно вам надо подстроить коэффициенты для упреждения. Почему это происходит и как это сделать, в этой ветке есть множество постов, полистайте, не ленитесь.64 конечно хороший прицел - точки выцеливает и все такое... но Упреждение по движущейся цели берет отвратительно. Все время позади цели снаряды летят. 059 был гораздо точнее в этом плане
64 конечно хороший прицел - точки выцеливает и все такое... но Упреждение по движущейся цели берет отвратительно. Все время позади цели снаряды летят. 059 был гораздо точнее в этом плане
Это не так. Возможно вам надо подстроить коэффициенты для упреждения. Почему это происходит и как это сделать, в этой ветке есть множество постов, полистайте, не ленитесь.
Зорро, вопрос не по твоему моду, а просто как к человеку который шарит в питоне, из-за чего может появляться такая хрень в питон логе.
ERROR: [EXCEPTION] (scripts/common/Event.py, 34):
Traceback (most recent call last):
File "scripts/common/Event.py", line 32, in __call__
File "scripts/client/gui/battle_control/arena_info/listeners.py", line 203, in __arena_onAvatarReady
File "scripts/client/gui/battle_control/arena_info/listeners.py", line 69, in _invokeListenersMethod
File "scripts/client/gui/Scaleform/daapi/view/battle_loading.py", line 157, in invalidateVehicleStatus
File "scripts/client/gui/Scaleform/daapi/view/meta/BattleLoadingMeta.py", line 108, in as_setVehicleStatusS
Exception: PyGFxValue - Failed to invoke method as_setVehicleStatus.
Сегодня игрался с настройками, сохранил по запарке блокнотом в тоталкомандере. Играю, в бою стреляю, попадаю, вот думаю настроил круто, просто огонь, сносит на лету гонщиков на быстрых танках. Захотел шасси-корпус-башня поменять, а они у меня на свои кнопки забиты, жму-не меняется. Отыграл бой с установками по дефолту. Очень неплохо игралось с предустановленными автором.Поддерживаю, упреждение вещь индивидуальная. Большинству подойдут настройки по умолчанию, но в некоторых случаях нужно откорректировать коэффициенты под себя.
<!-- Упреждающий коэффициент для дальних целей (норм. примерно 1.5) -->
<AimOffsetFar>1.2</AimOffsetFar>
<!-- Упреждающий коэффициент для близких целей может быть больше AimOffsetMax -->
<AimOffsetClose>2.50</AimOffsetClose>
<!-- Расстояние с которого начинает действовать упреждающий коэффициент для близких целей -->
<minDistToAimOffset>200</minDistToAimOffset>
в случае с отставанием следует увеличить параметр AimOffsetFar
Не стоит забывать, необходимо что бы цель двигалась равномерно какое-то время, какое, зависит от расстояния и параметров
<!-- Размер буфера данных о скорости (менять не рекомендуется!) -->
<bufSpeedSize>5</bufSpeedSize>
<!-- Размер буфера данных о направлении (менять не рекомендуется!) -->
<bufDirSize>5</bufDirSize>
а так же
<!-- определяется размером буфера средних значений данных -->
<!-- Размер буфера упреждения для дальних целей(менять не рекомендуется!) -->
<!-- ("<" быстрее реакция, меньше точность ">" больше точность, медленней реакция) -->
<AimSlowerMax>40</AimSlowerMax>
<!-- Размер буфера упреждения для близких целей(менять не рекомендуется!) -->
<AimSlowerMin>3</AimSlowerMin>
после ввода алгоритма задержки срабатывания упреждения стоит обратить внимание на параметр
<!-- Задержка включения упрехдения, если скорость цели достигла 0, в сек. -->
<!-- влияет на подёргивания упреждения при движении цели рывками -->
<preemptDelay>1.0</preemptDelay>
он не даёт дёргаться прицелу, но не обеспечивает точность, нужно понимать в какой момент стоит отправлять снаряд в цель, или надеяться на автовыстрел
Сегодня игрался с настройками, сохранил по запарке блокнотом в тоталкомандере. Играю, в бою стреляю, попадаю, вот думаю настроил круто, просто огонь, сносит на лету гонщиков на быстрых танках. Захотел шасси-корпус-башня поменять, а они у меня на свои кнопки забиты, жму-не меняется. Отыграл бой с установками по дефолту. Очень неплохо игралось с предустановленными автором.
ZorroJan, возможно и в этом часть проблемы с жалобами на аим у игроков. Что-то настраивают под себя, не сохраняют в нужной кодировке и в результате жалобы на не успевающий аим за целью...
Но у меня вопрос другого порядка.
Почему аим выцелив точку на совершенно неподвижном танке, выстрелив, прыгает на другую? Зачем? Чем аиму начинает нравится другая точка на абсолютно неподвижном танке, ведь и я совершенно не двигаюсь? В тренировке, например. Как избавить его от этого? Ведь большинство дерганий прицела именно из-за такой ситуации....
ZorroJan, при изменении положения своего, или танка противника все понятно. Но почему меняется выбранная точка у неподвижных танков, в тренировке? Ведь ее значение и характеристики не изменялись. Получается, что точки подбираются постоянно новые из разных частей массива? А почему они не фиксируются при не изменении выбранной точки? Почему происходит новая выборка, если у старой точки все характеристики соответствуют? Почему не задать проверку перед новой выборкой соответствия выбранной точки, если она вписывается в установленные параметры, поиск не прыгает в новую часть массива? Прицел стоит на старой точке, не прыгает? А может, если нашлась точка у движущегося противника, с характеристиками, близкими к максимально положительным, поиск не идет по другой части массива, а ищет и контролирует рядом находящиеся? Ведь так аим прыгать будет меньше....Набор точек - это не мгновнный процесс. Точки набираются случайным образом по всей видимой поверхности танка. Характеристики точки - такие как координаты и запас пробития записываются в массив. Условием для включения точки в массив служит значение параметра
<!-- Минимальный процент пробития брони для включения точки в расчёт АвтоБота, от 0% - 100% -->
<minPercent>45</minPercent>
Далее идёт выборка из массива. Проверяются все собранные точки на момент выборки и определяется подходящая по предустановленному параметру
<!-- Нижняя граница пробития брони в процентах для выбора точки из расчётных, в качестве искомой, от 0% - 100% -->
<!-- Поиск точек ведётся от центра к краю -->
<piersingPercent>75</piersingPercent>
Поиск точки при этом ведётся от среднего центра всего массива координат к краям, т.е. как бы по спирали от центра. Это для того, чтобы искомая точка была как можно ближе к центру цели, для повышения вероятности попадания в цель и стабилизации искомого участка. При добавлении новой точки, выполняется перерасчёт и определение новой точки, центр при этом может сместиться, но в основном, чем больше точек, тем стабильнее держится определённый участок. А вот когда танк меняет положение, массив приходится очищать, т.к. показатели бронепробития в точках устаревают из-за изменения координат и углов цели. Вот тут вы и наблюдаете передёргивания, т.к. при очищении массива набор случайных точек начинается заново. Но без этого фактора никак.
Вопрос можно решить при помощи параметра
<!-- Время задержки очередной проверки АвтоБотом лучшей позиции для выстрела -->
<timeFindBestPos>0.8</timeFindBestPos>
после того как первая точка определена и смещение выполнено, второй перерасчёт и последующие будут производиться через установленное в нём время, в секундах
ZorroJan, при изменении положения своего, или танка противника все понятно. Но почему меняется выбранная точка у неподвижных танков, в тренировке? Ведь ее значение и характеристики не изменялись. Получается, что точки подбираются постоянно новые из разных частей массива? А почему они не фиксируются при не изменении выбранной точки? Почему происходит новая выборка, если у старой точки все характеристики соответствуют? Почему не задать проверку перед новой выборкой соответствия выбранной точки, если она вписывается в установленные параметры, поиск не прыгает в новую часть массива? Прицел стоит на старой точке, не прыгает? А может, если нашлась точка у движущегося противника, с характеристиками, близкими к максимально положительным, поиск не идет по другой части массива, а ищет и контролирует рядом находящиеся? Ведь так аим прыгать будет меньше....
Подскажите пожалуйста - как увеличить скорость поиска уязвимых точек ? Какой параметр отвечает за это в xml файле ?
Зорро, приветствую, ты не мог бы сохранять конфиг и выкладывать его для скачки в том виде как ты сам играешь, а то постоянно надо вспоминать что подстраивать
и еще, будь ласков, как то низковато берет у меня, ты мне как то писал что надо менять где то , то ли 1 то ли 2, а я уж прости запамятовал где и не могу никак найти, вы флудите как пулеметчики, только страницы прибавляются
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?