LButton::MouseMove, 250, 0,, R 
LButton Up::MouseMove, -250, 0,, R

прекрасно возвращает курсор на своё место, из чего можно сделать вывод, что проблема не в АХК, а в том, как игра обрабатывает движения мыши. Как можно заметить, в CS движение мыши по горизонтали осуществляется свободно, в то время как движение мыши по вертикали ограничено (точнее, движение то не ограничено, просто камера "упирается" в ноги или в небо).

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.

* не соответствие точке возврата - мною имеется ввиду, отсутствие наличия точного позиционирования курсора по отжиму хоткея, хаотичные смещения от стартовой позиции после многократного посыла команды

;определяем интересующий нас цвет
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

Насчет PixelSearch утверждать не буду, вечерком проведу опыты.

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

Замена моделей...

Я так понимаю имелась ввиду замена текстурных карт у моделей. Приведу пример на CS:S, так вот если текстуры заменить (и не только текстуры моделей...), то подключиться к любому из серверов не получиться ввиду не соответствия контрольных сумм у заменённых файлов. Даже если цвет найден на экране, максимум, что можно сделать: нажать на нужную клавишу, подать звуковой сигнал. Координаты найденного цвета использовать в трёхмерной проекции не представляется возможным, потому как они соответствуют экрану.

Имхо, на АХК проще всего (из перечисленных в статье способов) сделать поиск по цвету/картинке.
Этот путь разделяется на 2 варианта реализации:
1. Замена моделей игроков на модели с более контрастными цветами, для упрощения поиска цвета. Проще говоря, цвета игроков должны быть такими, чтобы исключить возможность ложного срабатывания скрипта.
2. Написание заковыристого алгоритма для исключения ложного срабатывания скрипта.

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

Вывод: не стоит забивать гвозди микроскопом.

Попробуй PixelSearch, но не уверен что поможет.

Я в PixelSearch вообще ничего не умею. Дайте хоть пример, и укажите там где что указывать