Messages

1

Общие вопросы / Re: Не работает GOTO(RNDFROM ( 11, 15, 19, 23, 27) )

« on: June 04, 2014, 12:07:01 AM »

нет, " " не помогают
не работает ни
$var5 = RNDFROM ( "11", "15", "19", "23", "27")
ни
GOTO(RNDFROM ( "11", "15", "19", "23", "27"))

2

Общие вопросы / Re: Не работает GOTO(RNDFROM ( 11, 15, 19, 23, 27) )

« on: June 03, 2014, 11:41:59 PM »

Vint, спасибо, но я уже переделал в условия, это несложно
позже проверю вариант с " "

3

Предложения / GOTO не поддерживает подстановку имени через переменную и RNDFROM

« on: June 03, 2014, 09:45:56 PM »

соответственно, хотелось бы чтобы поддерживало, например GOTO($var5)
и GOTO( RNDFROM ( 11, 15, 19, 23, 27) )

тема здесь http://crapware.aidf.org/forum/index.php?topic=1232.0

4

Общие вопросы / Re: Не работает GOTO(RNDFROM ( 11, 15, 19, 23, 27) )

« on: June 03, 2014, 09:42:48 PM »

Oraven, огромное вам спасибо)
когда то делал подобное, но уже забыл как

кстати, неплохо бы попросить Джанни, чтобы GOTO поддерживало подстановку имени через переменную, пойду создам тему

апд. создал
http://crapware.aidf.org/forum/index.php?topic=1233.0

5

Общие вопросы / Не работает GOTO(RNDFROM ( 11, 15, 19, 23, 27) )

« on: June 03, 2014, 07:43:59 PM »

Не могу понять, почему не работает этот скрипт ((
Задумка - переход к рандомно выбранной строке, на деле выполняет только строку с меткой 11:  хотя $var5 = RNDFROM ( 11, 15, 19, 23, 27) работает и приваивает переменной рандомные значения

Кликерман версия: 4.5.

пробовал GOTO( RNDFROM ( 11, 15, 19, 23, 27) ) - не работает тоже ((

Code: [Select]

WAIT(1)
GOSUB(комб)


SUB(комб) 
$var5 = RNDFROM ( 11, 15, 19, 23, 27)
LOGWRITE("$var: ", $var5)

GOTO($var5)

11: // 53,49, 55,56
LOGWRITE("Ходим: ", 11)
GOTO(30)

15: // 53,49, 55,56
LOGWRITE("Ходим: ", 15)
GOTO(30)

19: // 53,49, 55,56
LOGWRITE("Ходим: ", 19)
GOTO(30)

23: // 53,49, 55,56
LOGWRITE("Ходим: ", 23)
GOTO(30)

27: // 53,49, 55,56
LOGWRITE("Ходим: ", 27)

30:
END_SUB
лог

Code: [Select]

20:07:21 $var: 11
20:07:21 Ходим: 11
20:07:22 $var: 11
20:07:22 Ходим: 11
20:07:23 $var: 15
20:07:23 Ходим: 11
20:07:24 $var: 15
20:07:24 Ходим: 11
20:07:25 $var: 15
20:07:25 Ходим: 11
20:07:26 $var: 27
20:07:26 Ходим: 11
20:07:27 $var: 11
20:07:27 Ходим: 11
20:07:28 $var: 15
20:07:28 Ходим: 11
20:07:29 $var: 27
20:07:29 Ходим: 11
20:07:30 $var: 19
20:07:30 Ходим: 11



6

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 26, 2014, 07:07:12 AM »

хороший вариант, будем надеяться, что Джонни увидит и реализует 

7

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 24, 2014, 01:01:24 PM »

не знаю, меня в принципе устроит любой формат, но наверное, вмп лучше

8

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 24, 2014, 06:09:08 AM »

Вот тут как раз бы и пригодился

Code: (clickermann) [Select]

SCREENSHOT($x1, $y1, $x2, $y2)

да, именно такой оператор и нужен

9

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 04, 2014, 03:35:01 AM »

Я использую просмотрщик xnviеw. Можно задать область и снимать горячей клавишей.

ух ты, круто, не знал про такие
она умеет сохранять скриншоты в области х1,у1, х2,у2  с перидичностью 50 мсек?
по крайней мере, я не нашел где можно задавать область захвата

Но на самом деле подход не правильный. Как это поможет учесть задержку? Ну высчитаешь среднюю, наступит выходной и нагрузка на сервера возрастет... Может ещё какой элемент меняется и его можно учитывать?

на самом деле не все так плохо, задержка как правило стабильная, равна десяткам или сотням миллисекунд, но желательно определиться, делать  ее 100 мсек или 500
хотя конечно, согласен что лагнуть может в любой момент, но другого способа определения я пока не вижу, а точнее его просто нет, если, конечно, не использовать чистое програмирование

Не нужно было ни разу знать точное значение

точное значение мне и  не нужно, точность условная, плюс минус 15%
к примеру, при полном здоровье число пикселей с цветом  10197915  в этой полоске 80, но беда в том, что почему то в первом раунде это число не 80 а 65, хотя полоска точно такая же визуально, и вообще непонятно, прямопропорциональна ли зависимость числа пикселов от заполненности полоски/числа хп

вот эта полоска
цифры здоровья могут быть разные, в зависимости от типа бота-персонажа
цифры нельзя выделить и скопировать, это графика
а также  та часть, которую я пытался анализировать, цвет 10197915

10

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 03, 2014, 08:51:15 PM »

угу, пока писал предыдущий пост, эта мысль тоже мне пришла в голову )
но остается проблема с необновлением полоски из за задержек, поэтому анализ скриншотов был бы нелишним

11

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 03, 2014, 05:54:40 PM »

хм
еще раз
есть полоска здоровья, при полном здоровье она полностью красно коричневого цвета, расцветка ее равномерная и не меняется в процессе боя, меняется лишь процент заполнения, при нанесении урона часть полоски становится белой у трупа она полностью белая
в ней есть доминирующие пикселы с цветом (условно) 123
когда полоска здоровья полная, этих пикселов (условно) 100 штук
если здоровье неполное, пикселов меньше, причем поскольку расцветка полоски не меняется, логично предположить, что при половине здоровья пикселов будет вдвое меньше,  но эксперименты показали что это не так
с функцией PXLXOR я прекрасно знаком и ее часто использую, но в данном случае используется функция  подсчета пикселов одного цвета в заданной области PXLCOUNT
у меня нет задачи определять изменилась ли картинка (после нанесения удара здоровье может не измениться из за промаха или попадания в блок) , но есть задача определять насколько она изменилась, а также выяснить, прямопропорционально ли число пикселей длине полоски / количеству здоровья, кроме того, есть интересный нюанс - при полном здоровье в первом раунде число пикселей в полоске меньше (примерно на 15%) чем при полном же здоровье во втором и последующих раундах
вот для этого мне и нужен анализ сохраненных скриншотов, и лучше не скриншотов по GETSCREEN а скриншотов области анализа

12

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 03, 2014, 04:08:50 PM »

4.5, и кстати, она работает быстрее чем 4.8 - возможно я не изучил доки, возможно, есть нюансы, но меня 4.5 вполне устраивает

GETSCREEN можно вызывать и совсем без задержек, это приводит к увеличенной нагрузки на процессор.

вижу, меня не понимают
проблема не в задержке самого GETSCREEN

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

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

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

13

Предложения / Re: Сохранять не весь скриншот а область поиска-анализа

« on: January 03, 2014, 02:06:43 PM »

вопрос не в цветокорекции, меняются не цвета а число пикселов одного цвета
конкретный пример - есть полоска здоровья,  вырезал ее верхнюю часть по всей длине, определил наиболее часто встречающийся пиксель, сосчитал его количество при полном здоровье
далее планировался анализ здоровья  по числу этих пикселов, но, как оказалось, при полном здоровье число пикселов в первом раунде всегда 70, а в последующих 100,  ходы делаются достаточно быстро, примерно 10 раз в секунду
но у меня нет полной  уверенности что это именно так, ибо обновление полоски здоровья происходит спустя некоторое время после хода, и есть шанс, что я анализирую еще не обновленную полоску, а увеличивать задержку между ходами нежелательно
да, можно сохранять скрины каждые 50 мсек, но скрины всего экрана имеют значительный вес, в отличии от веса полоски 100 х 7 пикселов, да и анализировать полный скрин не так удобно
в общем, думаю, функция была бы полезна, да и реализовать ее, как мне думается, не так уж сложно

заодно неплохо бы добавить функцию анализа картинок а не только областей экрана

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

14

Предложения / Сохранять не весь скриншот а область поиска-анализа

« on: January 03, 2014, 02:59:39 AM »

Столкнулся с ситуацией, когда в процессе действия область которая визуально не меняется на самом деле имеет разные значения количества пикселов искомого цвета.
Хотелось бы для анализа иметь воззможность сохранять не весь скриншот а только ту его часть, которая анализируется, например для
$count = PXLCOUNT (1088,232,1491,486, 2368548)
сохранять только область 1088,232,1491,486

и так далее

15

Общие вопросы / Re: Не работает команда SOUND

« on: December 26, 2013, 02:09:38 AM »

хм, спасибо
невнимательно читал справку, инерция мышления