Автокликер Clickermann :: Форум
Основной раздел => Общие вопросы => Topic started by: Hito on October 14, 2016, 09:17:04 PM
-
Ребят, знаю, что Clickermann написан на Delphi. Этот код:
$x1=633
$y1=243
$x2=811
$y2=382
$ms = $_ms
GETSCREEN
FOR($y=$y1,$y<$y2+1)
FOR($x=$x1,$x<$x2+1)
$color = pxl($x,$y)
IF($color = 16777215)
PXLREPLACE($x,$y,$x,$y,$color,8372223)
END_IF
IF($color ! 11368191)
PXLREPLACE($x,$y,$x,$y,$color,0)
END_IF
END_CYC
END_CYC
SCREENSHOTFIX(0,0, $_xmax,$_ymax, "OutScreen.bmp", 0)
LOGWRITE ($_ms-$ms)
HALTреализуется за 10218 миллисекунды... Может я туплю в чем-то... Как ускорить процесс? Если написать на той же delphi прогу, которая будет делать то же самое и выдавать такой же скрин (один в один), то вся операция занимает всего 46 миллисекунд. Может какой-то другой алгоритм в Clickermann нужно прописывать...?
-
Или хотя бы как подгрузить в буфер Clickermann-а картинку не с экрана, а из файла? Ну, чтоб сам экран сканила другая прога, а кликер искал нужную картинку не на экране, а на картинке из файла.
-
Причем тут Delphi, кликер интерпретирует скрипт в исполняемые команды и тратит на это массу времени и ресурсов.
Судя по скрипту ускорять там нечего. И кликере нет возможности взять картинку в графический буфер из файла.
-
кликер интерпретирует скрипт в исполняемые команды
Неужели более 10-ти секунд уходит только на то, чтобы машина перевела скрипт в несколько строк, с одного языка на другой...? Тут в чем-то другом дело... В delphi-ж я тоже не на двоичном языке пишу... Однако в той проге на все операции уходит в 200 с лишним раз меньше времени... Только поймите правильно пожалуйста - я не пытаюсь сейчас дуться, как "мудрый карась". Просто реально заставила задуматься разница.
-
10 секунд это еще быстро. У меня выполнение твоего скрипта вообще заняло 43755 мс. ::)
Вот так на секунду быстрее отработал.
$x1=633
$y1=243
$x2=811
$y2=382
$ms = $_ms
GETSCREEN
FOR($y=$y1,$y<$y2+1)
FOR($x=$x1,$x<$x2+1)
$color = pxl($x,$y)
IF($color = 16777215)
PXLREPLACE($x,$y,$x,$y,$color,8372223)
ELSE
IF($color ! 11368191)
PXLREPLACE($x,$y,$x,$y,$color,0)
END_IF
END_IF
END_CYC
END_CYC
SCREENSHOTFIX(0,0, $_xmax,$_ymax, "OutScreen.bmp", 0)
LOGWRITE ($_ms-$ms)
HALT
Кстати не понятно,
IF($color = 16777215) допустим условие верно и сработало, произошла замена цвета
IF($color ! 11368191) но следующее условие тоже будет верным и снова цвет будет переписан :o В чем смысл?
-
10 секунд это еще быстро. У меня выполнение твоего скрипта вообще заняло 43755 мс. ::)
у меня он 20 сек отрабатывает :D .
дело в том, что можно схитроить, и не менять каждый пиксель поочереди, а запомнить координаты белых и розовых, а потом поместить их на место с заменой белого на оранжевый. выполнение ускориться значительно, но только если количество тех самых белых и розовых пикселей не велико.
$x1=633
$y1=243
$x2=811
$y2=382
$ms = $_ms
GETSCREEN
SCANPXL($orange, $x1, $y1, $x2, $y2, 16777215) //запоминаем все координаты с белыми пикселями
SCANPXL($pink, $x1, $y1, $x2, $y2, 11368191) //запоминаем все координаты с розовыми пикселями
COLORMODE(8,$x1, $y1, $x2, $y2) //делаем нашу область черной
PXLREPLACE($x1, $y1, $x2, $y2,16777215,0)
$size=ARRSIZE($orange)-1
FOR($a=0,$a<$size)
PXLREPLACE($orange[$a],$orange[$a+1],$orange[$a],$orange[$a+1],0,8372223)//отрисовываем заново все оражевые, вместо белых
END_CYC
$size=ARRSIZE($pink)-1
FOR($a=0,$a<$size)
PXLREPLACE($pink[$a],$pink[$a+1],$pink[$a],$pink[$a+1],0,11368191) //отрисовываем заново все розовые
END_CYC
SCREENSHOTFIX(0,0, $_xmax,$_ymax, "OutScreen.bmp", 0)
LOGWRITE ($_ms-$ms)
halt
-
У меня выполнение твоего скрипта вообще заняло 43755 мс. ::)
У меня просто Core-i7 ;)
В чем смысл?
Нужно один цвет получить. Даже если их там два.
Я тут еще и цвет спутал... Вместо 11368191, 8372223.
Просто там стрелка белая закрашивается другим цветом постепенно. Заготавливать уйму скринов с разной степенью закраски - сам понимаешь... А так закрасил ее сразу одним цветом и сверил с одним скрином.
Я сегодня набросаю маленькую прогу и скину - попробуешь разницу. Тоже наверное задумаешься...
-
можно схитроить
Мне кажется хитрость замороченная )) А выигрывает не много.
-
выполнение ускориться значительно, но только если количество тех самых белых и розовых пикселей не велико.
я проверял на рабочем столе, где белые пиксели это только названия ярлыков (их не много) - выполнение 485мс . да, если у тебя на в области количество белых пикселей больше половины, то разница не ощутима.
-
да, если у тебя на в области количество белых пикселей больше половины, то разница не ощутима.
Для меня любая разница не особо ощутима, если весь процесс занимает более 50 мс. Мне просто две такие области закрашивать нужно и с поиском пяти цветов в этих областях. А потом еще сравнивать заготовленные картинки с этими областями (их больше 15-ти). И все это нужно делать быстро...
P.S. - Чую, чтобы пройти эту игру, мне придется самому кликер писать под нее...
-
В общем вот программку набросал http://www.fayloobmennik.net/6636343 (http://www.fayloobmennik.net/6636343)
А вот образец картинки для работы http://www.fayloobmennik.net/6636320 (http://www.fayloobmennik.net/6636320)
Программка создаст папку для скринов и будет сохранять скрины в нее. На верхние три параметра можете не обращать внимания (это мне для работы). С координатами и цветом сами все поймете. Если не ставить галочку на чекбоксе, то прога сделает скрин всего экрана, на котором найдет цвет в заданных координатах и закрасит остальные цвета. После этого сохранит весь скрин. Если галочку поставить, то скрин будет сделан только обработанной области. Ну тоже заморочка для меня. В общем попробуйте без галочки и попробуйте сделать то же самое кликером и ощутите разницу...
Ааа! Забыл ;D Активируется все это дело по (Ctrl+F1) :)
Там горячие клавиши зареганы и прога сработает в свернутом виде.
У меня выполнение твоего скрипта вообще заняло 43755 мс. ::)
Прогой быстро? Я там таймер не поставил, но на глаз разница видна?
Могу в принципе таймер впихнуть. Все спешу просто... Голова у меня просто пухнет постоянно от всего этого ))
-
Прогой быстро?
Быстро, меньше секунды. Запускаю, тутже "тадам" и все скрин готов.
-
Прогой быстро?
Быстро, меньше секунды. Запускаю, тутже "тадам" и все скрин готов.
Ну вот... Вот с таймером http://www.fayloobmennik.net/6636385 (http://www.fayloobmennik.net/6636385) Побольше чуток получилось правда... - 75 мс у меня. Нужно подшаманить. Но все же... Кликер получается по каким-то другим своим внутренним алгоритмам все это делает...? В проге я использую практически тот же алгоритм, что и в скрипте кликера. Тоже перебираю по очереди пиксели в заданной области и сверяю. А вот какой алгоритм для этого использует сам кликер, на основе скрипта...? Но это только Джони известно...
-
А кто тебе сказал, что он переводит с псевдобейсика на делфи?
Он тупо интерпретирует построчно запоминая точки переходов в циклах и подпрограммах.
Каждая итерация фор (а они ещё и вложенные) интерпретируется заново. Наверно. К тому же код на делфи при компиляции стал хоть и замусоренным, но ассемблером. Пусть и не везде таким оптимальным как на чистом асм. А псевдокод скрипта КМ уже ни чем не стал и проходит двойную обработку.
Всё это в угоду универсальности команд и функций которых нет напрямую в делфи. Всё можно оптимизировать и даже не один раз. Но на это нужно время и стимул.
Как говорил Джонни, он начинает писать делфи на делфи. В чём тогда смысл?
-
А кто тебе сказал, что он переводит с псевдобейсика на делфи?
Он тупо интерпретирует построчно запоминая точки переходов в циклах и подпрограммах.
Каждая итерация фор (а они ещё и вложенные) интерпретируется заново. Наверно. К тому же код на делфи при компиляции стал хоть и замусоренным, но ассемблером. Пусть и не везде таким оптимальным как на чистом асм. А псевдокод скрипта КМ уже ни чем не стал и проходит двойную обработку.
Всё это в угоду универсальности команд и функций которых нет напрямую в делфи. Всё можно оптимизировать и даже не один раз. Но на это нужно время и стимул.
Как говорил Джонни, он начинает писать делфи на делфи. В чём тогда смысл?
Ты прости, но я ничего не понял из сказанного... Это не твой минус - мой ) Но уж так уж есть...
-
;D короче, жизнь - зло.
-
;D короче, жизнь - зло.
Согласен ))) Я просто эмулятор PS2 поставил на комп и очень хочется пройти игру, которую я когда-то на соньке играл )) - God of War и God of War II. Очень уж игруха прикольная )) Но она ведь под джойстик заточена, а там часто нужно вовремя нужные кнопки нажимать, особенно на боссах. На джойстике это сделать трудно, а уж на клаве... Я уже молчу, когда на клаве нужно сэмитировать вращение правого, или левого тригера джойстика в определенную сторону. Это даже не просто нажимать поочередно "W" - "D" - "S" - "A", а последовательно зажать "W", потом зажать "D", потом отпустить "W" и зажать "S", потом отпустить "D" и зажать "A" и так далее. Это попа... И на все это нужно среагировать быстро - в течении пары секунд. Но охота пройти еще раз игрушку... :)
-
Как говорил Джонни, он начинает писать делфи на делфи. В чём тогда смысл?
Ну, для примера приведу тебе ситуацию...
В Clickermann-е для того, чтобы сделать скрин экрана и поместить его в буфер, нужно прописать всего лишь "GETSCREEN".
В delphi для этого нужно прописать:
bmp1 := TBitmap.Create;
bmp1.Width := Screen.Width;
bmp1.Height := Screen.Height;
BitBlt(bmp1.Canvas.Handle, 0,0, Screen.Width,
Screen.Height, GetDC(0), 0,0,SRCCOPY);
Оххх...! Я уже молчу про поиск картинки в картинке...
Джони существенно облегчил язык скрипта для пользователей Clickermann-а.
-
В общем вот программку набросал http://www.fayloobmennik.net/6636343
А вот образец картинки для работы http://www.fayloobmennik.net/6636320
я так понимаю, что должно получиться чтото типа этого
(http://i.imgur.com/4BgPpWR.png)
на выполнение ушло 120мс. кликерман не сильно и отстает :D , всего в 5 раз дольше, 670мс (это с учетом, что SCREENSHOTFIX выполняется у меня ~100мс). значит у тебя будет гдето 350мс.
скрипт делает тоже самое, что и твоя прога.
$x1=135
$y1=690
$x2=222
$y2=755
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
SCANPXL($orange, $x1, $y1, $x2, $y2, 19404)
COLORMODE(8,$x1, $y1, $x2, $y2)
PXLREPLACE($x1, $y1, $x2, $y2,16777215,0)
$size=ARRSIZE($orange)-1
FOR($a=0,$a<$size)
PXLREPLACE($orange[$a],$orange[$a+1],$orange[$a],$orange[$a+1],0,19404)
END_CYC
SCREENSHOTFIX($x1, $y1, $x2, $y2, "OutScreen.bmp", 0)
LOGWRITE ($_ms-$ms)
halt
-
PXLREPLACE скорее всего был придуман для работы с областью граф. буфера, а не для замены отдельного пиксела. и существенной разницы по времени при замене одного пикселя или 10 000 пикс. нет. мне кажется, тут не хватает процедуры SETPXL(x,y,color), ну или чтото типа этого, чтобы независимо от цвета пикселя, кликер отрисовал в буфере нужный нам цвет.
-
мне кажется, тут не хватает процедуры SETPXL(x,y,color), ну или чтото типа этого, чтобы независимо от цвета пикселя, кликер отрисовал в буфере нужный нам цвет.
PXLREPLACE(100,100, 100,100, -1, 255) // если в параметре -1 то любой цвет будет заменен на указанный.
-
скрипт делает тоже самое, что и твоя прога.
Если честно, то у меня за весь день опухла голова и я сейчас туго соображаю, чтобы вникнуть в ваши примеры ) А моя прога вот, что делает:
for Y := 0 to bmp2.Height - 1 do
for X := 0 to bmp2.Width - 1 do
begin
Color:=bmp2.Canvas.Pixels[x,y];
if (Color<>19404) then
begin
bmp2.Canvas.Pixels[x,y]:=0
end;
end;
Практически то же самое, что я показал тут в скрипте кликера.
Только разница во времени исполнения огромная...
Я вот, что сейчас подумал... Может обрабатываемую площадь разбить на 4 части и пусть ее 4 потока обрабатывают...? ;D
Аааа... Тут же вроде GETSCREEN один на все потоки...
А если бы и не один, то тоже хз - как. Муть уже всякая в голову лезет )))
Просто в делфи это замутить можно как раз. Там есть возможность сохранить фрагмент картинки на рабочей форме и уже в несколько "смычков" ее обработать. А тут так не получится же...
Просто у меня не одна область такая, которую надо так обрабатывать. Их две. И в каждой до 15-ти разных вариантов действий может выскакивать.
Вот, например
http://shot.qip.ru/00R6pv-517zmt2ziI/ (http://shot.qip.ru/00R6pv-517zmt2ziI/)
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziJ/ (http://shot.qip.ru/00R6pv-517zmt2ziJ/)
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziK/ (http://shot.qip.ru/00R6pv-517zmt2ziK/)
Там куча вариантов разных...
-
Я вот, что сейчас подумал... Может обрабатываемую площадь разбить на 4 части и пусть ее 4 потока обрабатывают...? ;D
Аааа... Тут же вроде GETSCREEN один на все потоки...
А если бы и не один, то тоже хз - как. Муть уже всякая в голову лезет )))
разделив на потоки, скорость не вырастет, тоже когда-то была такая идея. но если разделить сложные расчеты на выполнение в разных кликерах, то скорость выполнения вырастет в количество разделенных процессов. с работай над графическим буфером это естественно не прокатит :(, так как в каждом запущенном кликере свой буфер.
Мне просто две такие области закрашивать нужно и с поиском пяти цветов в этих областях. А потом еще сравнивать заготовленные картинки с этими областями (их больше 15-ти). И все это нужно делать быстро...
и просмотрев эти скрины
Вот, например
http://shot.qip.ru/00R6pv-517zmt2ziI/
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziJ/
Или вот
http://shot.qip.ru/00R6pv-517zmt2ziK/
я начинаю подозревать, что тебе в игре дают подсказки, на какие кнопки жать, и что куда крутить.
а ты случаем не забыл, что в функции IF_PICTURE_IN есть параметр игнорируемого цвета? если использовать этот параметр, то все твои манипуляции с буфером отпадают. но даже если так, то всеравно, фрагмент такого размера будет искать оооочень долго. как по мне, тут к месту "PXLCOUNT (x, y, x2, y2, color) - числовая функция; производит подсчет количества пикселей заданного цвета в прямоугольной области буфера анализа "
хотя, возможно я ошибаюсь в поставленных задачах :D . и не все так просто как мне показалось.
-
я начинаю подозревать, что тебе в игре дают подсказки, на какие кнопки жать, и что куда крутить.
Ты прям - Догада! ;D (Это шутка не со зла) Ты видимо в приставки не играл никогда ))
Вот джойстик для PS2 - http://shot.qip.ru/00R6pv-117zmt2ziW/ (http://shot.qip.ru/00R6pv-117zmt2ziW/)
Естественно в игре дают подсказку - на какую кнопку жать, но игра подразумевает, что ты должен помнить, под каким пальцем у тебя какая кнопка. Под каким кнопка с треугольником - под каким с квадратом, и так далее. И в игре дается время на это действие столько, чтобы ты нажимал их по памяти. Там столько времени на это отпускается, что даже держа в руках джойстик, ты не успеваешь на него смотреть, чтобы визуально сориентироваться - где нужная кнопка.
А вот настройка эмулятора PS2, в которой кнопки джойстика переносятся на клавиатуру - http://shot.qip.ru/00R6pv-617zmt2ziX/ (http://shot.qip.ru/00R6pv-617zmt2ziX/)
Это тебе нужно не только помнить - где на джойстике какая кнопка, но и помнить - на какую кнопку клавы ты ее воткнул )) Кнопки, что выскакивают ближе к центру экрана, еще попроще. Они хоть и на прозрачных панелях, но с помощью цветокоррекции их еще можно отловить. А вот с теми кнопками, что в левом углу экрана появляются, ситуация сложнее...
https://www.youtube.com/watch?v=vYMdZGa8nSc&feature=youtu.be (https://www.youtube.com/watch?v=vYMdZGa8nSc&feature=youtu.be)
То есть, как мы видим, одну кнопку еще и в нескольких вариантах ловить нужно )) Это при том, что в этом видео я их жал в ручную и даже заранее положив палец на нужную кнопку, у меня не хватило моторики, чтобы прожимать ее с нужной скоростью, чтобы открыть проход дальше ))) И в этом варианте это еще не самые сложные кнопки выскакивают. Это не бой с боссами и все такое ))
а ты случаем не забыл, что в функции IF_PICTURE_IN есть параметр игнорируемого цвета?
Я скажу больше - я даже не знал о таком параметре )) Что он делает?
-
Я скажу больше - я даже не знал о таком параметре )) Что он делает?
пример:
будем искать фрагмент твоего скрина с использованием игнорируемого цвета. в моем примере это цвет черный "0". ищем прямо в браузере.
(http://i.imgur.com/UXdbliC.png)
$x1=94
$y1=650
$x2=262
$y2=786
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 0, 100) // при поиске будут игнорироваться все черные пиксели которые в "test.bmp". цвет ригнорирования можно использовать любой.
print($_return1,"x", $_return2)
END_IF
LOGWRITE($_ms-$ms)
halt
область поиска впиши свою, чтобы ускорить поиск.
"test.bmp" во вложении
-
О как...! Так это можно заготовить заранее таких картинок, на которых будет сохранен только нужный цвет, а потом искать его совпадение уже не закрашивая скрины "онлайн"...? :o Что-то в меня это надежду вселило прям... :)
$x1=94
$y1=650
$x2=262
$y2=786
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 0, 100) // при поиске будут игнорироваться все черные пиксели которые в "test.bmp". цвет ригнорирования можно использовать любой.
print($_return1,"x", $_return2)
END_IF
LOGWRITE($_ms-$ms)
halt
Только я не пойму - где тут указывается параметр, при котором будет игнорироваться цвет? Я что-то не вижу его... Это нолик перед 100 что ли...? Где обычно стоит -1?
-
О как...! Так это можно заготовить заранее таких картинок, на которых будет сохранен только нужный цвет, а потом искать его совпадение уже не закрашивая скрины "онлайн"...? :o Что-то в меня это надежду вселило прям... :)
именно так :D
но все равно, поиск картинки это както долго как по мне. тут всеже к месту был бы PXLCOUNT (x, y, x2, y2, color)
-
но все равно, поиск картинки это както долго как по мне.
Дак само сравнение разных картинок уже можно разбить на группы и запихнуть в разные потоки )) Думаю, что это уже проще и сократит время на поиск большого количества вариантов картинок )) Или я ошибаюсь...?
-
потоки прироста к скорости не дадут, я когда-то проверял. можно обойтись обычным перебиранием по очереди заготовленных картинок. прирост скорости даст только уменьшение области поиска, и уменьшение размеров заготовок. можно заморочиться конечно :D , для каждой искомой картинки (группы картинок) - свой кликер.... можно поэкспериментировать.
-
Только я не пойму - где тут указывается параметр, при котором будет игнорироваться цвет? Я что-то не вижу его... Это нолик перед 100 что ли...? Где обычно стоит -1?
да, это нолик, черный цвет. если-бы я вместо черного зарисовал к примеру красным 255, то было бы так IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 255, 100)
-
потоки прироста к скорости не дадут
Странно... Ведь по логике, если, скажем, 10 разных картинок разбить на два потока (в каждом по 5), то время поиска должно бы сократиться в двое... Ведь 5 картинок искались бы одновременно с поиском других пяти. Ну, это по логике. В ситуации с Clickermann это не так?
-
Кликер и в один поток напрягает процессор по полной. Две задачи будут просто выполняться в два раза медленнее.
У меня, кстати, кликер напрягает двух ядерный процессор на 50%, это значит что оба ядра не используются по полной а просто задача распределяется на два ядра. И тут чем больше ядер тем быстрее.
-
Кликер и в один поток напрягает процессор по полной.
Ну... Тут я могу пощеголять ;D
http://shot.qip.ru/00R6pv-617zmt2zj2/ (http://shot.qip.ru/00R6pv-617zmt2zj2/)
http://shot.qip.ru/00R6pv-617zmt2zj3/ (http://shot.qip.ru/00R6pv-617zmt2zj3/)
Это при том, что у меня открыто два браузера и в каждом по 50 вкладок )))) + работает эмулятор PS2, в котором игра на паузе стоит ))
А это с паузой в 10 мс ))
http://shot.qip.ru/00R6pv-317zmt2zj4/ (http://shot.qip.ru/00R6pv-317zmt2zj4/)
-
у меня тоже 8-ядерник, но не интел :D, . и как было видно ранее, кликер работает в 2 раза медленнее чем у Hito. проц почти не напрягается при работе - 5-10% при поиске картинки. так что от чего тут зависит скорость кликера я хз :D
а насчет разделения на потоки, то вот тест:
$x1=33
$y1=528
$x2=500
$y2=850
wait(22222)
THREAD(thr_1)
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 0, 100)
print($_return1,"x", $_return2)
END_IF
LOGWRITE("первый поток ",$_ms-$ms,"ms")
waitms(30)
END_THREAD
THREAD(thr_2)
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 0, 100)
print($_return1,"x", $_return2)
END_IF
LOGWRITE("второй поток ",$_ms-$ms,"ms")
waitms(30)
END_THREADв потоках ищет в этой области ~1200мс каждый поток
и без потоков, поочереди
$x1=33
$y1=528
$x2=500
$y2=850
$ms = $_ms
GETSCREEN($x1, $y1, $x2, $y2)
IF_PICTURE_IN ($x1, $y1, $x2, $y2, "test.bmp", 0, 100)
print($_return1,"x", $_return2)
END_IF
LOGWRITE($_ms-$ms)
waitms(30)примерно 600мс. тоесть, использование потоков для повышения скорости поиска картинов не имеет смысла.
но.... имеет смысл поиск каждой картинки в отдельном кликере, это действительно работает. работает на столько, на сколько хватит мощности процессора. а это очень много, на моем компе запросто можно запустить отдельно 20-30 отдельных кликеров, и каждый будет работать в максимум своей скорости, и при этом процессор даже и не заметит их.
-
Странная ситуация с потоками... Благодаря ей, потоки во многом теряют свой смысл... А дохрена кликеров открывать - конечно выход, но какой-то "грязный"... :) Пройти игру в конце концов поможет, но эго сцука унизит... ;D Да и больше двух кликеров открывать нет смысла - две обрабатываемой области.