Messages

1

Предложения / Re: [Alpha/Beta Testing] Тестируем сырые обновления (ссылки в первом посте)

« on: February 02, 2021, 06:36:36 PM »

Может всё таки десятка виновата?

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

если мне не изменяет память и $_time_t я раньше ↑↑ юзал без эксцессов - то это было на этом же бинаре, который сейчас, я его 100 лет не менял со времён какой-то нормально работающей беты 4.13, даже не релиза ещё.
больше похоже на костыль в функции (который, кстати, может быть в том на чём он написан, а не в самом кликере), высчитывающей unix ts, который раньше срабатывал, а теперь больше нет.

Может и с Unix временем есть несколько функций. Одна учитывает таймзону, другая нет. Или это параметры одной функции.

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

2

Предложения / Re: [Alpha/Beta Testing] Тестируем сырые обновления (ссылки в первом посте)

« on: February 02, 2021, 03:14:17 PM »

А вот $_time_t очень давно я проверял, всё было нормально. Сейчас проверил. Все и 4.14 и 4.13 и 4.11 и 4.8 и 4.6 (пропускал версии чтоб быстрее найти) выдают это вот сдвинутое на таймзону. Вот здесь не скажу кто виноват. Но давно, когда проверял ещё на XP было всё нормально, думаю версия была 4.8 и 4.11

да вот и мне кажется (но это неточно), что 2-3 года назад я опирался в скрипте на абсолютное значение $_time_t, чтоб определённые фрагменты отрабатывали только в рамках установленного отрезка времени, и всё работало как надо. с той поры не изменилось ничего - тот же ноут, та же винда, даже та же версия clickermann, изменился почему-то только сам $_time_t 

3

Предложения / Re: [Alpha/Beta Testing] Тестируем сырые обновления (ссылки в первом посте)

« on: February 01, 2021, 03:17:33 AM »

Win7 x64 SP1, 4.14.03 (пробовал так же .02, от .01 нашёл только анонс с чейнджлистом, но не нашёл самих файлов) при запуске сразу пишет в errorlog.txt:

Code: [Select]

01.02.2021 01:56:56 Access violation at address 0063C4FE in module 'Clickermann.exe'. Read of address 00000000
и затем после открытия редактора - циклически:

Code: [Select]

01.02.2021 01:57:03 Access violation at address 00000000. Read of address 00000000
01.02.2021 01:57:03 Access violation at address 00000000. Read of address 00000000
01.02.2021 01:57:03 Access violation at address 00000000. Read of address 00000000
01.02.2021 01:57:03 Access violation at address 00000000. Read of address 00000000
01.02.2021 01:57:04 Access violation at address 00000000. Read of address 00000000
01.02.2021 01:57:04 Access violation at address 00000000. Read of address 00000000

при этом нельзя передвинуть окно редактора и нельзя передвинуть открытое окно лога - они "прыгают" назад туда, где изначально появились. после попытки запустить скрипт - пропадает кнопка запуска, в логе снова access violation уже с ненулевыми оффсетами, скрипт не запускается. это у меня что-то? 4.13.х из того же места работают без эксцессов.

а чё, собственно, полез в бету: Clickermann любой версии, включая последнюю релизную 4.13, выдаёт неверный unix timestamp в $_time_t, а именно - смещает его соответственно установленному в системе часовому поясу. так быть не должно, поскольку это число - абсолютный отсчёт секунд от.. ну вы в курсе, и в любой момент в любой точке мира одинаков.
в последней 4.14, судя по тому что поиск по форуму "$_time_t" никаких подобных комплейнов не нашёл - наверное, так же, проверить, вот, не удалось.

4

Ошибки / Re: Привязка окон не коректна

« on: October 25, 2018, 02:12:39 AM »

там на самом деле изображение привязанного окна "ездит" вправо-вниз и назад, я уже писал на эту тему.

у меня такая же фигня, проявляется конкретно при привязке к flash. смахивает на то, что проблема не в CM, а в связке его с конкретным окружением (дрова видео, флэш, темы, ..).
поскольку окружение в моём случае менять не получится - выкрутился такого плана функцией:

Code: [Select]

sub(safegs,$sgs_cm)
 $t_sgs=0
 for($t_sgsi=0,(($t_sgsi<9)&($t_sgs=0)))
  waitms(100)
  getscreen
  $t_sgs=pxlxor(0,9,0,9)
 end_cyc
 colormode($sgs_cm)
end_sub

и юзаю её вместо getscreen+colormode. эти "прыжки" длятся доли секунды, эксцессов при использовании таким способом больше не было пока (но тут надо учитывать - у меня во флэше чёрный (точнее, монотонный) квадрат в левом верхнем углу "штатно" невозможен; если у вас не так - надо искать другую область сверху или слева, или другой способ).
как бонус - код затем компактнее выходит, одна строка вместо двух, чтоб получить экран в нужном цветовом режиме.

5

Общие вопросы / Re: Скан пикслей и отчет в процентах.

« on: July 20, 2018, 09:38:06 PM »

кстати.

давно хотел попросить, чтоб как-то можно было получать фактический процент совпадения после IF_PICTURE_IN/SCANPICTURE.
он всё равно высчитывается в процессе работы функций, остаётся его только положить в какую-то служебную переменную навроде $_return3.

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

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

6

Предложения / Re: [Alpha/Beta Testing]

« on: April 30, 2018, 08:29:35 PM »

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

ну, относительно окна редактора (откуда в 99.9% случаев и вызывается) - ога, появляется в одном и том же месте.
только вот не там где надо - перекрывает собой редактор и каждый раз мув+ресайз его приходится.
ваще здорово было бы тогда хотя бы "появлять" его под редактор, такой же ширины, и высотой строк в 5-10.
но наверное, просто запоминать где и каким его в последний раз закрыли - будет таки проще и практичнее

да и в "боевом режиме" окно лога не используется. в основном для отладки на стадии написания

в боевом режиме лог не нужен вообще, факт. но есть ещё один важный режим - ДОписания, который, как ремонт в доме, обычно не прекращается никогда.

7

Предложения / Re: [Alpha/Beta Testing]

« on: April 29, 2018, 11:44:44 PM »

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

8

Предложения / Re: [Alpha/Beta Testing]

« on: April 12, 2018, 12:19:58 AM »

Clickermann v4.13.13b
то же что 12b,

а где можно узнать, что было в 12 по сравнению с 11?

9

Предложения / Re: [Alpha/Beta Testing]

« on: February 12, 2018, 07:17:24 PM »

Hotfix

подтверждаю, в 010 снова всё в норме. спасибо!

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

главное на нём не заснуть под утро, как в том анекдоте   

10

Предложения / Re: [Alpha/Beta Testing]

« on: February 11, 2018, 10:26:00 PM »

Clickermann v4.13.009b x32

после захвата в оконный режим flash player (обоими способами) - ничего не в нём не видит (чёрная лупа, серые скрины).

проявилось после наката 007->009; откат решает проблему.

11

Ошибки / Re: Локальные переменные подпрограммы(параметры) вовсе не локальные

« on: December 05, 2017, 08:39:00 PM »

"Локальные переменные подпрограммы (параметры) при этом будут уничтожены."

это лишь про переменные, описаные в объявлении подпрограммы, внутри скобок sub(...). всё остальное - глобально.

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

12

Предложения / Re: [Alpha/Beta Testing]

« on: December 05, 2017, 07:23:59 PM »

до 006 getscreen с привязкой захватывал не целевой элемент (как воще т задумывалось) а все родительское окно. поэтому появлялись сдвижки графики равные всяким панелям, рамкам, заголовкам. в 006 захватывается только тот элемент интерфейса к которому была привязка.

заглянул ради интереса на 006 снова лупой редактора - так и скачет. выглядит это так (gif):



т.е. изображение на долю секунды "съезжает" вправо и вниз (чётко на расстояния от 0 до края флэша без привязки), затем "возвращается" обратно. закономерности во времени появления таких скачков не наблюдается, интервалы абсолютно разные.
а, и забыл сказать - без привязки никаких скачков нет, всё всегда где должно быть.

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

ага, плиз, а то страшно надолго оставлять стало

13

Предложения / Re: [Alpha/Beta Testing]

« on: December 05, 2017, 05:19:09 PM »

Как на счет решения проблемы "заголовка" в оконном режиме.

Починено. Там вообще не очень корректно работало.

сорри, в 006b что-то тоже "не тавой"..

было подобное, гетскрин привязаного внутри окна браузера flashplayer иногда давал результат как без привязки (браузер передвинут в 0,0), но размером с сам флэш, и где пространство браузера - пустота, т.е. изображение флэша сдвинуто вправо-вниз и обрезано нижним правым углом до размеров флэша без глюка. причём, если чуть подождать и повторить гетскрин - уже всё нормально. аналогичным образом "прыгало" изображение флэша и в лупе редактора при включенной привязке.
не был уверен, что случай не индивидуальный (в частности, у меня 125% скалинг интерфейса винды и во флэше включено аппаратное ускорение, чего делать вроде как не рекомендуется) поэтому не поднимал вопрос на форуме, а выкрутился обёрткой:

Code: [Select]

sub(safegs,$sgs_cm)
 $t_sgs=0
 for($t_i=1,(($t_i<15)&($t_sgs=0)))
  waitms(100*$c_slow)
  getscreen
  $t_sgs=pxlxor(1,10,1,10)
 end_cyc
 colormode($sgs_cm)
 if($t_i>10)
  print("=== warning, ",$t_i," getscreen tries")
  screenshot("bad-gs-")
 end_if
end_sub

до 005b спасало на ура, до bad-gs-ххх доходило ооочень редко, единицы за несколько месяцев.

поставил 006b, сделал один тестовый прогон - всё нормально. ок, оставил на ночь. на утро - 112 однотонных последовательных bad-gs-ххх размером 41736 х 2933 (и, соответственно 467 мб штука )
причём, судя по логам скрипта, он несколько раз таки отработал нормально, но в какой-то момент стал слепым и наплодил вот таких монстров.

P.S.: раз добрался, опишу ещё один недочёт, который стал наблюдаться с 005b - иногда не ловится hwnd по тайтлу. тайтл - абсолютно статический. тоже пришлось обернуть:

Code: [Select]

for($t_i=0,(($t_i<10)&($sw=0)))
 waitms(100)
 $sw = wndfind("заголовок")
end_cyc

по 004b включительно это не требовалось, глюк не проявлялся ни разу.

14

Предложения / Re: выгрузка и загрузка буфера анализа графики

« on: November 17, 2017, 04:27:19 PM »

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

да как бы вопрос не в размере, памяти у современных компов на всё хватит, и мощи пережевать это всё обходными путями тоже.
вопрос в том, что если так приходится делать - почему бы не отнести это всё поближе к железу, чтоб писалось красиво, и выполнялось быстро.

15

Предложения / Re: выгрузка и загрузка буфера анализа графики

« on: November 17, 2017, 04:21:56 PM »

Можно пример использования?

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

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

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

P.S. выгрузка и так есть - это SCREENSHOT, осталась загрузка.

ну тут уже уважаемому автору виднее, как лучше. может есть смысл буфера грузить-выгружать "как есть" в какой-нибудь .bin или .buf, чтоб не было лишнего оверхеда внутри СМ и лишней путаницы снаружи. хотя соглашусь, при грамотном использовании возможность грузить .bmp непосредственно в буфер анализа - более универсальна, и решила бы не только эту проблему.