[Drakensang-Online] Бот для игры

[Belfigor]

вон смотри на белфигора, молчит как рыба об лед, значит уже почти написал) с минуты на минуту монетизировать начнет
-1 ботовод же.

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


Добавлено:

Сообщение автоматически объединено: 7 Окт 2013

И да, иметь продукт не равно иметь схему реализации, если бы всё упиралось в наличие готового бота, я бы уже лет 7 продавал свой софт :whistle:. Но последний год я потратил именно на реализацию защиты, вот на её-то реализацию ушло 99.9999999999999999% времени
Вах вах, сколько же я знал людей, которые давали мне демку своего продукта, и на то чтобы его разлочить уходило максимум пару часов, чтобы лишь подменить проверочные значения на нужные. Потому Себуна я понимаю, сам раньше работал по принципу приватного написания ботов под конкретного юзера. Схема не прибыльна
Я уж не говорю про то, что программу можно тупо сунуть в декомпиллер и получить исходник. Последний год я работаю именно над тем, чтобы исхожник не представлял вообще никакой ценности


Добавлено:

Сообщение автоматически объединено: 7 Окт 2013

И еще по моим прикидкам уйдет минимум год - полтора соло

 

[Whited]

Belfigor [?]

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

. Но последний год я потратил именно на реализацию защиты, вот на её-то реализацию ушло 99.9999999999999999% времени

С чем я только что и столкнулся, и вот начался мой год поиска защиты приложения, я вот всерьёз подумываю перейти на С++,т.к. там проще склепать защиту, да и механизм свзяи с сервером проще мне кажется реализовать....

 

[bugaj]

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

Та я вообще не понимаю что за клиент там у себуна) под конкретного клиента можно только ради интереса писать, а не ради прибыли. Хотя может у него там олигарх ))

Меня заклинило на скорости поиска картинок )) Я даж ботов не пишу, а механизм постоянно оптимизирую этот. Скорость у меня уже умопомрачительная(приходится ставить паузы, т.к. между соседними поисками игра не успевает обновить картинку ), но никак не могу остановиться в процессе ее ускорения, все новые и новые идеи, если последние реализую, то время поиска одной картинки уже окончательно перейдет в микросекунды наверное :laugh:.

И это, писать ботов на С++ это задротство :-D

 

[C2H5OH]

bugaj,
ломают всё. Вопрос только в том сколько сил на это придётся потратить. И будет ли пригоден для использования результат взлома. Так вот взлом продукта написанного на AutoIt означает получение исходников в их первоначальном виде. Поэтому писать защиту для скриптов AutoIt - вот настоящее задротство. А перенос кода на c++ - это довольно таки эффективное решение проблемы, это решает задачу защиты кода от уровня "только ленивый".

Да, я тоже считаю что у себуна ничего интересного нет. А мифический буратино - это отмазка для тех кто просит показать хоть что-нибудь. ;D

Кстати, да, - чё хвастаешься непонятно чем? Рассказывай что придумал с распознаванием картинок.

И это, я в курсе шо я тролль.

 

[bugaj]

правила проклятого буржуйского мира не позволяют рассказывать :'( я тож может хочу монетизироваться, я столько времени на это убил ) вот так и живем :(

 

[nowost]

эх , хорошо вам, за деньги пишете ... я вот больше для души и когда время бывает ботом занимаюсь :whistle:

 

[bugaj]

по мойму тут все тока мечтают о том чтобы пописать за деньги, а не пишут белфигор никого не берет к себе, хочет все деньги себе забрать. :D

 

[sebun]

Да, я тоже считаю что у себуна ничего интересного нет. А мифический буратино - это отмазка для тех кто просит показать хоть что-нибудь.

А что у меня может быть интересного, если я изобретаю велосипед, только иной конструкции? А код - ну почему же, я показываю. Куски, которые имеют отношение к вопросу, задаваемому на этом форуме. Целиком объем бота больше мегабайта вместе с вложенными ресурсами и плюс, как ты выразился, буратино - это как раз то, что не позволяет выложить бота целиком, а вовсе не отмазки.

Меня заклинило на скорости поиска картинок )) Я даж ботов не пишу, а механизм постоянно оптимизирую этот. Скорость у меня уже умопомрачительная(приходится ставить паузы, т.к. между соседними поисками игра не успевает обновить картинку ), но никак не могу остановиться в процессе ее ускорения, все новые и новые идеи, если последние реализую, то время поиска одной картинки уже окончательно перейдет в микросекунды наверное :laugh:.

Вот вместо того, что бы хвастаться, показал бы нам хоть один пример. Мне как раз именно этой функции не хватает. Правда картинки мне не нужны, мне нужно движение, быстрое распознавание подвижных объектов и хотя бы приблизительно распознавание их формы. Я объясню свою позицию, почему была выбрана именно графика. Память игры меняется при каждом обновлении. Знаю, что и это легко обходится поиском нужных значений, но второй момент - защита, которой пока нет, но может быть введена в ближайшее время. Знаю, что можно отследить и программное управление клавиатурой и мышью, но обычно защищают в первую очередь память, поэтому я работаю пока исключительно чтением пикселя. Есть наработки - поделись. К тому же монетизировать можно продукт, а не отдельную функцию, имхо.

белфигор никого не берет к себе, хочет все деньги себе забрать.

Каждый волен распоряжаться своей работой на свое усмотрение. На мой взгляд Belfigor тут ни перед кем отчитываться не обязан. Если один смог сделать продукт, а два других не смогли, это не значит, что он должен их кормить из своего кармана только потому, что он смог, а они - нет.

эх , хорошо вам, за деньги пишете ... я вот больше для души...

С этого все когда то и начиналось... ;)

 

[bugaj]

норм подход, белфигор и себун успешные бизнесмены значит, а мну делись ;D я итак в этом топике прорывную идею выдал там выше где то, когда я себе ее внедрил, с сотен миллисекунд на поиск я перешел на десятки и нули)
Естественно это все не на автоите делается, о какой функции речь? ) Там километры кода )

 

[sebun]

Ты про обработку картинки в памяти? Так это еще со времен DOS-а все делалось, это не твоя идея. Кстати, была прога, DupDetector помоему, не помню. Искала дубликаты изображений на компе. Она за секунды тонны картинок обрабатывала, так что этот велосипед давно изобретен. А вот если бы ты научился движение определять, тебе бы тут многие каждый день репу плюсовали. Серьезно. :whistle:

 

[bugaj]

Ты про обработку картинки в памяти? Так это еще со времен DOS-а все делалось, это не твоя идея. Кстати, была прога, DupDetector помоему, не помню. Искала дубликаты изображений на компе. Она за секунды тонны картинок обрабатывала, так что этот велосипед давно изобретен. А вот если бы ты научился движение определять, тебе бы тут многие каждый день репу плюсовали. Серьезно. :whistle:

Репу на хлеб не намажешь. Если все так понятно, то почему еще не реализовали? Но если найти картинку так просто, то в чем собственно проблема? ищешь картинку периодически и фиксируешь ее координаты, а также изменения положения этой картинки (можно и ускорение считать, направление и все что хочешь) - вот тебе движение. Если поиск сделать 2-4 раза в секунду (да в отдельном потоке), я думаю вполне будет работоспособно, а все остальное время держишь поток на Sleep(); и тогда проц не будет сильно грузиться. ну при условии, что на поиск уходит до 100 миллисекунд )

В принципе, кроме расчета изменения координат, направления, ускорения и пр. у меня уже все это есть, но сам я движения фиксировать не пытался, не было нужды, но в релизе будет. :D



С поиском трехмерной модели думаю будут проблемы, причем при любом раскладе, пока на ум приходит только хранение и поиск всех возможных проекций модели на экран - что уж никак быстро работать не будет на обычном ЦПУ. А иначе как объяснить компу, что вот это моб вид сзади, а вот это моб вид спереди?

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

P.S. во! Число зверя 6 66

 

[sebun]

У меня немного иное представление поиска движения. Алгоритм примерно такой: делаем скрин в память, раскладываем картинку на куски (как бы накладываем сетку) и получаем контрольный цвет каждой ячейки данной сетки. Затем делается второй скрин, действие повторяется. На участок, где контрольные суммы сильно различаются, наводим курсор и проверяем, увеличился ли красный канал. Если да, то там моб. Но это самый простой вариант, применимый к таким играм, как та, под которую я писал бота. В идеале должен висеть второй процесс, типа радар, который будет непрерывно сканировать окно и в отдельной области памяти хранить координаты моба, его объем и т.д. Но опять же, память... где то в памяти самого клиента это все должно быть, и не надо ничего изобретать. Только я не умею ковырять память, ну по крайней мере я нашел все то, о чем раньше писал Делрок, а вот карту, мобов - это у меня не вышло. А трехмерная модель она нафик не нужна, это для глаза создается иллюзия объема, а так это та же самая плоская картинка, которую можно выделить из фона и обвести контуром. Имхо.

 

[bugaj]

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

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

 

[sebun]

Да нет, я немного о другом. Контур как таковой собственно не нужен, это был лишь пример, на основании которого можно построить математическую модель. Иметь кучу снимков каждой трехмерной проекции мягко сказать глупо. Давай возмем чайник из 3D Max. Эта модель может принимать какую угодно форму в зависимости от настроек, и как ты его не снимай, все равно точности определения ты не сможешь добиться. Верно? Теперь смотри что я предлагаю. Есть статичный фон (ну пусть условно он будет статичен), есть некий движущийся объек, пусть это будет тот же чайник, слегка поворачивающийся вправо-влево. Наша задача - определить этот чайник. Делаем, как я писал, два снимка и сравниваем по регионам. Именно по регионам, а не по пикселям, так как в dll эта функция работает шустрее, чем попиксельное сравнение. Но это не важно. Итак, мы определили некое движение по разнице пикселей на двух картинках. Далее нам нужно "обвести объект контуром", то есть определить его границы. Для точности можно сделать третий снимок, не всего экрана, а только того участка, где чайник. В определении замкнутых границ можно прибегнуть к кривой Безье, алгоритм на PHP работал шустро, но там у меня маленькие картинки были и стояла иная задача. Итак, мы уже знаем: 1 - координаты объекта, 2 - его объем, а так же имеем контур объекта, по которому уже можно построить математическую модель объекта. Что это за модель? К примеру берем цилиндр. Его модель - труба. То есть одна замкнутая плоскость и две окружности. Берем наш контур. Похож на цилиндр, но имеет носик, ручку. Значит чайник. Вот и все. Кстати на эту мысль наталкивает скелетная анимация - можно анализировать движение объекта на 3х-4х снимках и определить ключевые точки, в которых происходит вращение осей, и построить примерную скелетную модель объекта, а потом по ключевым точкам сравнить с шаблоном. Шаблон - как раз такая модель, содержащая лишь положение осей и длины "костей". Конечно, это пока лишь теория, возможно "наполеоновская", но я пока не знаю других быстрых средств определения объекта. Кстати, Кибор умеет вроде распознавать 3D объекты, правда иначе.

 

[bugaj]

ппц ( все уже придумано до нас :'(

 

[lirikmel]

Кибор умеет вроде распознавать 3D объекты, правда иначе.

Я уже разбирался с этим, кибор использует аналог FFLocalizeChanges , я бы сказал абсолютный аналог.

И действует так

#RequireAdmin
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Compile_Both=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
; Demo FastFind (officielle)
#include "FastFind.au3"
#Include <WinAPI.au3>


global const $DEBUG_DEFAULT = 3
global const $DEBUG_GRAPHIC = $DEBUG_DEFAULT + 4
global const $WINDOW_CLASS = "Notepad" ; CLASS of the target Window
global const $WINDOW_TITLE = "" ; TITLE of the target Window

FFSetDebugMode($DEBUG_GRAPHIC) 	 ; Enable advanced (graphical) debug mode, so you will have traces + graphical feedback
FFSetDefaultSnapShot(0)

HotKeySet("{F5}", "ShowChanges")
HotKeySet("{F6}", "PeriodicChanges")
HotKeySet("{F3}", "SelectWindow")

While (1)
	Sleep(10) ; 'til we press "Esc" to leave
Wend

Func SelectWindow()
	FFTrace(@lf&"   ** SelectWindow"&@lf&"") ; Put this in the different debugging channels as set with FFSetDebugMode
	local $hWnd = WinActivate("[CLASS:"&$WINDOW_CLASS&"; TITLE:"&$WINDOW_TITLE&"]", "") ; We try to find and activate the proper windows
	if $hWnd="" Then
		$hWnd = WinGetHandle("[ACTIVE]", "") ; If the proper set window can't be found, we use the current active window
	EndIf
	WinSetOnTop ( $hWnd, "", 1)

	FFSetDebugMode($DEBUG_DEFAULT)
	FFSetWnd($hWnd)
	FFSnapShot()
	TrayTip("Select Window","Title of the Window: "&WinGetTitle($hWnd)&" Class:"&_WinAPI_GetClassName($hWnd), 2000)
	FFTrace("   ** SelectWindow => Title of the Window: "&WinGetTitle($hWnd)&" Class:"&_WinAPI_GetClassName($hWnd)&@lf) ; Put this in the different debugging channels as set with FFSetDebugMode
EndFunc



Func ShowChanges()
	FFTrace(@lf&"   ** ShowChanges"&@lf) ; Put this in the different debugging channels as set with FFSetDebugMode
	FFSetDebugMode($DEBUG_DEFAULT) ; We keep traces in a file, but no graphical display, to avoid adding our own changes on the screen
	FFSetDefaultSnapShot(1) ; We select Slot N°1 as the default for next operations
	FFSnapShot()
	FFSetDebugMode($DEBUG_GRAPHIC)	 ; Include graphical feedback to see the area that have changed
	$Res = FFLocalizeChanges(0, 1) ; We're loonking for differences bestween SnatShot N°0 and N°1
	if @Error Then
		TrayTip("ShowChanges","No change detected",2000)
		FFTrace("   ** ShowChanges => No change detected !"&@lf) ; Put this in the different debugging channels as set with FFSetDebugMode
	Else
		TrayTip("ShowChanges","Change detected : ("&$Res[0]&","&$Res[1]&","&$Res[2]&","&$Res[3]&"), "&$Res[4]&" pixels are different",2000)
		FFTrace("   ** ShowChanges => Change detected : ("&$Res[0]&","&$Res[1]&","&$Res[2]&","&$Res[3]&"), "&$Res[4]&" pixels are different"&@lf) ; Put this in the different debugging channels as set with FFSetDebugMode
	EndIf
	FFSetDefaultSnapShot(0) ; Back on SnapShot N°0 by default for next operations
	FFSnapShot() ; And take New SnapShot (N°0)
EndFunc

; We continuously watch changes on the screen (or selected Window, if any), showing them when any occure (Graphical debug + Tray Message)
Func PeriodicChanges()
	while 1
		FFSetDebugMode($DEBUG_DEFAULT) ; Remove graphical debug

		FFSetDefaultSnapShot(0) ; Take a SnapShot in slot 0
		FFSnapShot()

		Sleep(300)				; wait 300ms (no need to eat to much CPU), the value here should be much higher compare to the other operations in the loop (less than 100ms alltogether)

		FFSetDefaultSnapShot(1) ; Take a second SnapShot in slot 1
		FFSnapShot()

		FFSetDebugMode($DEBUG_GRAPHIC) ; Activate graphical debug to show the result
		$Res = FFLocalizeChanges(0, 1) ; Search all differences between two SnapShots
		if @Error Then
			FFTrace("   ** ShowChanges => No change detected !"&@lf) ; Put this in the different debugging channels as set with FFSetDebugMode
		Else
			TrayTip("ShowChanges","Change detected : ("&$Res[0]&","&$Res[1]&","&$Res[2]&","&$Res[3]&"), "&$Res[4]&" pixels are different",2000)
			FFTrace("   ** ShowChanges => Change detected : ("&$Res[0]&","&$Res[1]&","&$Res[2]&","&$Res[3]&"), "&$Res[4]&" pixels are different"&@lf) ; Put this in the different debugging channels as set with FFSetDebugMode
		EndIf
	Wend

EndFunc

Func TheEnd()
	FFTrace("   ** Bybye"&@lf&@lf) ; Put this in the different debugging channels as set with FFSetDebugMode
	CloseFFDll() ; Unload the DLL, free the memory, close files... makes all the cleaning. Don't use FastFind anymore after this instruction.
	Exit
Endfunc

HotKeySet("{ESC}", "TheEnd")

Проблема тока в том что в FFLocalizeChanges кроме параметра ShadeVariation не хватает параметра цвета , вот по сути и вся разница

 

[nowost]

все круто, только в Вин7 Х64 крашится после того как покажет разницу :'(


Добавлено:

Сообщение автоматически объединено: 12 Окт 2013

заработало на версии 1.8.4, последняя официальная версия 2.2 не пашет на Х64

 

[bugaj]

не эт фуфло, потому что если фон движется (т.е. твой чар бежит) то эта функция ничего не найдет. а так я такую делал, но она мне не понравилась...

 

[nowost]

да, потестил тоже , если какието динамические объекты то всегда заданная область изменяется


Добавлено:

Сообщение автоматически объединено: 12 Окт 2013

например трава или деревья колышутся от ветра

 

[sebun]

Во первых замечу, что человек не ставил целью создание универсальной функции, однозначно определяющую только нужную динамику в окне игры. Что вам мешает сделать, скажем, геодату текстур и уже на основании этой геодаты отсеивать те участки, где находится, скажем, трава? Или же забить какие нибудь данные искомых объектов, которые и будет искать данная функция? Лично я уже плюсанул репу (тем самым сказав спасибо) lirikmel, который работал над этим кодом (пусть и написано Demo FastFind (officielle)) и выложил его как базу, как пример, а не как готовое решение. В моем случае динамика проверяется не в момент движения, то есть фон неподвижен. После того, как что то динамичное обнаружено, я использую особенность самой игры - навожу в то место курсор и смотрю, меняется ли в той точке градация красного, так как при наведении на врага курсора он подсвечивается. Если градация на том же уровне - зона добавляется в исключение. И все прекрасно работает.