Pull to refresh

Comments 16

Жаль конечно что в статье нет ссылки на исходники, но хорошо что хотя бы в роликах она есть.


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

Но похоже что с gradle/maven вы не очень сильно знакомы.


И последствия внедрения gradle в проект сильно ударили по истории изменений всех классов :(

Благодарю за правку косяков, gradle добавил уже потом, когда появились проблемы с выявлением багов. Конфиги настроить все руки не доходили. Не предполагалось, что ядро вырастет на столько.
Жаль, что не получится использовать его для написания ботов ко всяким корейским ММО) Ведь почти все они накрыты какими-нибудь анти-читами и вряд ли такую эмуляцию клавиатуры/мыши они пропустят.
Инъекции в процесс нет, можно попробовать.
Один из вариантов запустить игру в песочнице(виртуальной машине), а бота запустить на основной.
Запуск в песочнице или в виртуальной машине помог бы скорее всего, если бы этот бот был запущен на хосте. Тогда да, для виртуальной машины это уже не эмуляция была бы. Только вот античит-системы редко разрешают запускать игру в виртуальной машине просто так. Защита от мультоводства.
Почти все античиты детектят скриншоты и вызовы мышки с клавой через API. Мышка с клавой эмулируются аппаратно через Arduino (на ATMEGA32U4: Micro, Leonardo и т.п., например через команды на COM порту). А снимок экрана если не ошибаюсь через D3D-буфер можно безопасно снимать.
Да можно и проще эмулировать клавиатуру, а вот с скриншотом не получится) Сёрфейс DirectX можно получить перехватив DirecxX Deivce, а вот перехват его уже спалить элементарно и почти все детектит. Ну или же искать его в памяти игры каким-то другим образом.
Странно, что про UOPilot не вспомнили. На данный момент много чего умеет. Правда исходники доступны только от совсем древней версии.
Добавить в статью забыл, но в 2016 году рассматривал его, когда начинал свою реализацию делать. Отбраковал по нескольким причинам, которые были для меня были критичны.
Необходимость привязывать к процессу
Недостаточный функционал в скриптовой части(нет потоков, кроссплатформенности)
Отсутствие поиска заранее заготовленных картинок

Но самое главное — неудобство написания большого скрипта. Для сравнения мой скрипт на своем движке имел 1300 строк кода с сортировками массивов обработкой чисел и короткого текста с экрана не имея возможности выделить и скопировать его, обработчиками статистических формул, которые обрабатывают информацию из истории в массивах, обработкой файлов и тд. На пилоте это вышло бы еще проблематичнее.
Ещё странно, что не рассмотрен Sikuli, который как раз под Jython заточен и весьма известен. Или я что-то пропустил спросонья. Под чистый CPython есть его аналог Lackey, который, впрочем, кривоват и плохо уживается с другими библиотеками. Не уверен, что Sikuli может юзать GPU, да и кэш скорее всего тоже пришлось бы писать.
Sikuli рассматривал, забыл добавить в статью.
Для моей первоначальной задачи требовалась именно скорость реакции, которую он не мог предоставить по большей части из-за Tesseract.
Вторая проблема — жесткая привязка к Java 1.6, которая не позволит перевести его на 1.7 или 1.8 например.
Более старая версия Jython тоже не особо радует, хотя 2.5.2 не на столько сильно устарела.

В остальном Sikuli отличный инструмент, советую всем!
Поиск происходит на 100% совпадение?
Но ведь может использоваться сглаживание, полупрозрачное меню и т.п. И картинка может немного отличаться.
В самом простом поиске да, 100% совпадение. По первоначальной задаче упор делался именно на скорость самого поиска.
Это решается через Tesseract, который был использован в том же Sikuli. Давно в планах добавить эту функцио.
Давным-давно в начале века писал себе бота на дельфи для spedia. До сих пор чек где-то не обналиченный на 30 баксов валяется. Делался скриншот, на нём искались кнопки, по которым жать надо, мышка плавненько подъезжала и кликала. Ничего не тромозило. Это саботаж какой-то с увеличением мощностей п.к. изобретать всё более тормозящие языки программирования.
Насчет Sikuli — гляньте в сторону SikuliX. Если не ошибаюсь, это его правопреемник, если можно так выразиться. Он обновляется, Python 2.7, Java 1.8, и на подходе SikuliX2 на Java 9.

Правда меня поднапрягло то, что они убрали try catch конструкции. Т.е. всюду надо пихать if: else: что не очень удобно.
Clickermann help.
getscreen
if_picture_in (0,0, 1024,768, «start.bmp», 0, 100)
Sign up to leave a comment.

Articles