Тема: AHK: Самонацеливающийся скрипт
Помогите сделать самонацеливающийся скрипт - AIM. Я не читер, просто хочу понять как это работает. Чтобы сам нацеливал в голову, например в игре Counter-Strike 1.6 и т.д.
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Помогите сделать самонацеливающийся скрипт - AIM. Я не читер, просто хочу понять как это работает. Чтобы сам нацеливал в голову, например в игре Counter-Strike 1.6 и т.д.
В играх эта программа не может брать объекты.
А сделать, чтоб работал никак?
Попробуй PixelSearch, но не уверен что поможет.
Попробуй PixelSearch, но не уверен что поможет.
Я в PixelSearch вообще ничего не умею. Дайте хоть пример, и укажите там где что указывать
Имхо, на АХК проще всего (из перечисленных в статье способов) сделать поиск по цвету/картинке.
Этот путь разделяется на 2 варианта реализации:
1. Замена моделей игроков на модели с более контрастными цветами, для упрощения поиска цвета. Проще говоря, цвета игроков должны быть такими, чтобы исключить возможность ложного срабатывания скрипта.
2. Написание заковыристого алгоритма для исключения ложного срабатывания скрипта.
Однако, у создания скрипта по данному пути есть минус, который сводит на нет смысл его написания: точность прицеливания слишком сильно зависит от расстояния до цели. Так же, скорее всего, игру придётся запускать в оконном, а не в полноэкранном режиме, чтобы работали команды поиска.
Вывод: не стоит забивать гвозди микроскопом.
Замена моделей...
Я так понимаю имелась ввиду замена текстурных карт у моделей. Приведу пример на CS:S, так вот если текстуры заменить (и не только текстуры моделей...), то подключиться к любому из серверов не получиться ввиду не соответствия контрольных сумм у заменённых файлов. Даже если цвет найден на экране, максимум, что можно сделать: нажать на нужную клавишу, подать звуковой сигнал. Координаты найденного цвета использовать в трёхмерной проекции не представляется возможным, потому как они соответствуют экрану.
Можно использовать относительные координаты, смещение на n пикселей относительно текущего положения прекрасно работает.
А контрольные суммы - это защита от дурака, вот вам для примера 2 модели awp и scout. Изменены так, что у них появляется прицел. Правда это не Source, а 1.6, но принцип тот же. На сервера пускает.
Автохокей не работает с ДИрект3D.
Из игр он не сможет брать ни какие пикселы, ни двигать мышкой...по крайней мере, стандартными функциями.
Фигню вы говорите, MouseMove, X, Y, , R прекраснейшим образом смещает курсор (в случае игры - вращает камеру).
Только что проверил в CS 1.6, CSS.
Насчет PixelSearch утверждать не буду, вечерком проведу опыты.
;определяем интересующий нас цвет
F1::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%, Fast
TrayTip, Title, %color%
return
;ищем цвет курсором
;надо будет поиграться с опцией Variation
;а так же немного подкорректировать координаты, потому что
;курсор мыши находится не точно по середине прицела в игре
F2::
MouseGetPos, MouseX, MouseY
Pixelsearch, X, Y, %MouseX%, %MouseY%, %MouseX%, %MouseY%, %color%, 10
if !ErrorLevel
{
TrayTip, Title, math!
return
}
TrayTip
return
MouseMove, X, Y, , R прекраснейшим образом смещает курсор...
Смещает, но не прекраснейшим образом.
LButton::MouseMove, 0, 250,, R ; вариант первый
LButton Up::MouseMove, 0, -250,, R
Вариант первый работает без нареканий в DirectDraw, в Direct3D работает тоже, но с погрешностями в виде не соответствия точке возврата*.
LButton::DllCall("mouse_event", UInt, 0x0001 ; вариант второй
, Int, 0
, Int, 250
, UInt, 0
, Int, 0)
LButton Up::DllCall("mouse_event", UInt, 0x0001
, Int, 0
, Int, -250
, UInt, 0
, Int, 0)
Вариант второй работает с погрешностями в виде не соответствия точке возврата* в DirectDraw и в Direct3D, но если в опциях выставлен прямой ввод с устройства, то работает без нареканий в Direct3D.
* не соответствие точке возврата - мною имеется ввиду, отсутствие наличия точного позиционирования курсора по отжиму хоткея, хаотичные смещения от стартовой позиции после многократного посыла команды
А вот тут возникает вопрос о чистоте эксперимента, потому как код:
LButton::MouseMove, 250, 0,, R
LButton Up::MouseMove, -250, 0,, R
прекрасно возвращает курсор на своё место, из чего можно сделать вывод, что проблема не в АХК, а в том, как игра обрабатывает движения мыши. Как можно заметить, в CS движение мыши по горизонтали осуществляется свободно, в то время как движение мыши по вертикали ограничено (точнее, движение то не ограничено, просто камера "упирается" в ноги или в небо).
Безупречная точность - главное, по этому мой выбор вариант 2.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться