Автокликер Clickermann :: Форум
Основной раздел => Предложения => Topic started by: LipsInc on January 03, 2014, 02:59:39 AM
-
Столкнулся с ситуацией, когда в процессе действия область которая визуально не меняется на самом деле имеет разные значения количества пикселов искомого цвета.
Хотелось бы для анализа иметь воззможность сохранять не весь скриншот а только ту его часть, которая анализируется, например для
$count = PXLCOUNT (1088,232,1491,486, 2368548)
сохранять только область 1088,232,1491,486
и так далее
-
Тебе надо использовать цветокоррекцию чтоб привести множественные оттенки к единому.
-
вопрос не в цветокорекции, меняются не цвета а число пикселов одного цвета
конкретный пример - есть полоска здоровья, вырезал ее верхнюю часть по всей длине, определил наиболее часто встречающийся пиксель, сосчитал его количество при полном здоровье
далее планировался анализ здоровья по числу этих пикселов, но, как оказалось, при полном здоровье число пикселов в первом раунде всегда 70, а в последующих 100, ходы делаются достаточно быстро, примерно 10 раз в секунду
но у меня нет полной уверенности что это именно так, ибо обновление полоски здоровья происходит спустя некоторое время после хода, и есть шанс, что я анализирую еще не обновленную полоску, а увеличивать задержку между ходами нежелательно
да, можно сохранять скрины каждые 50 мсек, но скрины всего экрана имеют значительный вес, в отличии от веса полоски 100 х 7 пикселов, да и анализировать полный скрин не так удобно
в общем, думаю, функция была бы полезна, да и реализовать ее, как мне думается, не так уж сложно
заодно неплохо бы добавить функцию анализа картинок а не только областей экрана
зы. мне кажется, что игра с числом пикселов есть один из способов борьбы с кликерами
уже не первый раз с этим сталкиваюсь
-
Какая у тебя версия кликера?
GETSCREEN можно вызывать и совсем без задержек, это приводит к увеличенной нагрузки на процессор.
-
4.5, и кстати, она работает быстрее чем 4.8 - возможно я не изучил доки, возможно, есть нюансы, но меня 4.5 вполне устраивает
GETSCREEN можно вызывать и совсем без задержек, это приводит к увеличенной нагрузки на процессор.
вижу, меня не понимают
проблема не в задержке самого GETSCREEN
проблема в том, что изменение картинки здоровья после нанесения удара происходит с некоторой задержкой, которая может быть от десятков миллисекунд до секунды и более (при лагах)
я наношу удар, через некоторое время делаю скриншот, чтобы проанализировать число оставшегося здоровья после нанесения удара и принять решение о нанесении или не нанесении следующего, но из за задержек сервера я могу заскринить картинку не изменившуюся, соответственно, принять ошибочное решение
увеличивать задержку с сотни миллисекунд до единиц секунд, чтобы перекрыть все возможные лаги я не хочу, хочу сделать серию скринов для анализа, чтобы узнать наиболее ожидаемый диапазон задержек сервера, для этого мне и нужна возможность сохранять не весь скриншот а только область анализа, ибо:
а) полный скриншот много весит
б) анализировать область на полном скриншоте неудобно из за несоответствия координат в игре и в редакторе, а также из за возможных искажений - я играю на виртуалках, а анализировать скорее всего буду на основной оси - а там возможно иксажения из за разности осей, настроек шрифтов и прочей лабуды
-
Есть функция PXLXOR складывающая пикселы, в зоне, в некое контрольное число, что можно использовать для анализа, изменилась ли картинка или нет.
Но она неидеальна, так как неучитывает положение пикселов.
По моему с 4.6 версии введена более надежная PXLCRC.
GETSCREEN
$count = PXLCRC (10,20, 100, 40) // получаем хеш сумму области
logwrite("Hash: ", $count)
По моему это то что тебе нужно.
-
хм
еще раз
есть полоска здоровья, при полном здоровье она полностью красно коричневого цвета, расцветка ее равномерная и не меняется в процессе боя, меняется лишь процент заполнения, при нанесении урона часть полоски становится белой у трупа она полностью белая
в ней есть доминирующие пикселы с цветом (условно) 123
когда полоска здоровья полная, этих пикселов (условно) 100 штук
если здоровье неполное, пикселов меньше, причем поскольку расцветка полоски не меняется, логично предположить, что при половине здоровья пикселов будет вдвое меньше, но эксперименты показали что это не так
с функцией PXLXOR я прекрасно знаком и ее часто использую, но в данном случае используется функция подсчета пикселов одного цвета в заданной области PXLCOUNT
у меня нет задачи определять изменилась ли картинка (после нанесения удара здоровье может не измениться из за промаха или попадания в блок) , но есть задача определять насколько она изменилась, а также выяснить, прямопропорционально ли число пикселей длине полоски / количеству здоровья, кроме того, есть интересный нюанс - при полном здоровье в первом раунде число пикселей в полоске меньше (примерно на 15%) чем при полном же здоровье во втором и последующих раундах
вот для этого мне и нужен анализ сохраненных скриншотов, и лучше не скриншотов по GETSCREEN а скриншотов области анализа
-
Тогда может тебе лучше анализировать белую полоску!
-
угу, пока писал предыдущий пост, эта мысль тоже мне пришла в голову )
но остается проблема с необновлением полоски из за задержек, поэтому анализ скриншотов был бы нелишним
-
Какая то надуманная проблема. Используй любую программу скриншотер. Я использую просмотрщик xnviеw. Можно задать область и снимать горячей клавишей.
Но на самом деле подход не правильный. Как это поможет учесть задержку? Ну высчитаешь среднюю, наступит выходной и нагрузка на сервера возрастет... Может ещё какой элемент меняется и его можно учитывать?
С подобными полосками обычно не всё сложно и достаточно проверять определенные пикселы, например соответствующие 50% или 30%. Не нужно было ни разу знать точное значение. И да, чаще удобней анализировать фон, а не саму полоску. Она часто с плавным изменением цвета. Хорошо если ещё цвет фиксирован в пространстве, а то ещё ползет вместе со значением.
-
Я использую просмотрщик xnviеw. Можно задать область и снимать горячей клавишей.
ух ты, круто, не знал про такие
она умеет сохранять скриншоты в области х1,у1, х2,у2 с перидичностью 50 мсек?
по крайней мере, я не нашел где можно задавать область захвата
Но на самом деле подход не правильный. Как это поможет учесть задержку? Ну высчитаешь среднюю, наступит выходной и нагрузка на сервера возрастет... Может ещё какой элемент меняется и его можно учитывать?
на самом деле не все так плохо, задержка как правило стабильная, равна десяткам или сотням миллисекунд, но желательно определиться, делать ее 100 мсек или 500
хотя конечно, согласен что лагнуть может в любой момент, но другого способа определения я пока не вижу, а точнее его просто нет, если, конечно, не использовать чистое програмирование
Не нужно было ни разу знать точное значение
точное значение мне и не нужно, точность условная, плюс минус 15%
к примеру, при полном здоровье число пикселей с цветом 10197915 в этой полоске 80, но беда в том, что почему то в первом раунде это число не 80 а 65, хотя полоска точно такая же визуально, и вообще непонятно, прямопропорциональна ли зависимость числа пикселов от заполненности полоски/числа хп
вот эта полоска
цифры здоровья могут быть разные, в зависимости от типа бота-персонажа
цифры нельзя выделить и скопировать, это графика
а также та часть, которую я пытался анализировать, цвет 10197915
-
Столкнулась с такой ситуацией. Необходимо сделать 170 скриншотов через кликерманн, потом в сторонней программе распознать текст, но не на всем снимке, а в определенной области. Вот тут как раз бы и пригодился
SCREENSHOT($x1, $y1, $x2, $y2)
-
Это у тебя скрипт такой или ты просто используешь кликерманн как скриншот-программу?
-
Небольшой скрипт, который перелистывает в окне страницы и делает снимки. В принципе объединив "Clickermann" и "Gadwin PrintScreen" задачу выполнила
-
Вот тут как раз бы и пригодился SCREENSHOT($x1, $y1, $x2, $y2)
да, именно такой оператор и нужен
-
Вот тут как раз бы и пригодился SCREENSHOT($x1, $y1, $x2, $y2)
Нужен, нужен, давно говорил. Только выглядеть он должен так:
SCREENSHOT(x1, y1, x2, y2, name)
Автор просто не делает, потому что не видит применения или думает что можно заменить другим кодом.
Приведу пример на зомби ферме. Нет надёжных средств узнать положение острова в окне программы, особенно если мы или скрипт его двигали. Просто не к чему привязаться. Все узнаваемые элементы которые мы заготовим в картинках могут не сработать если элемент закроется постройками/растениями/декором. А закрываются они очень часто, катастрофически часто. Нужно заготавливать десяток таких мест для каждого острова и то гарантии никакой. Плюс может быть разный масштаб (умножим ещё на 4).
Из-за разных разрешений экрана сдвиг острова может "упереться" в край и сбить весь процесс.
Даже простое возвращение в первоначальное положение становится трудной задачей. Здесь бы сделать 1-2 скриншота участков, а после действий/перемещений пытаться найти их поиском двигая остров.
Понимаю гарантии тоже нет если попал на динамический объект, но это можно обойти дублированием областей.
-
Что действительно нужно, так это указывать прямо в коде в каком формате выводить скриншот, в BMP или JPG!
-
не знаю, меня в принципе устроит любой формат, но наверное, вмп лучше
-
Не в этом дело, например в одном скрипте делаются скриншоты для того что бы потом посмотреть что происходило в тот момент. Здесь качество не важно и файлы должны быть маленькими JPG.
В другом скрипте делаются скриншоты с разной цветокоррекцией для последующего использования в функциях, и тут уже нужен именно BMP.
Вот и приходится вручную все время переключать. А если забудешь?
-
Обязательно в BMP, можно без вариантов.
Зачастую они будут использоваться этим же скриптом для поиска.
-
Может такой вариант?
SCREENSHOT(x1, y1, x2, y2, [name], [extension])
name - необязательный параметр; имя файла
extension - необязательный параметр; расширение файла; 1 - bmp; 2 - jpeg
Если параметр extension не указан, то снимок сохраняется, как указано в настройках программы
-
хороший вариант, будем надеяться, что Джонни увидит и реализует 8)