Непонятки

[ЦИТРИН]

  Проблема возникнет не из-за оператора, а в тебе, когда уже перестанешь понимать 

Ок. Спасибо.
Опыт некорифея важная вещь.
 Кстати, на слабом компе сокращение скрипта  посредством сабов , приводит к спонтанным  ошибкам.
Еще хуже ошибки, если при этом сеть  перегружена.
Это мой опыт .
 А если не поставлю задержки  между командами по 50-150мс  скрипт и вовсе прекращает работу выделывая всё, что ему нравится.

[Vint]

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

Кстати, на слабом компе сокращение скрипта  посредством сабов , приводит к спонтанным  ошибкам.
Еще хуже ошибки, если при этом сеть  перегружена.
Это мой опыт .
 А если не поставлю задержки  между командами по 50-150мс  скрипт и вовсе прекращает работу выделывая всё, что ему нравится.

Не может такого быть, чтоб использование подпрограмм вызывало ошибки в работе скрипта. Ошибки скорее в неправильном использовании (как вышеописанная).
Это могу сказать точно, т.к. сам использую кликер в том числе на слабом компьютере. Хочу сказать только, что для использования на слабых компах нужен другой подход к логике и контролю. Возлагать синхронизацию работы только на задержки уже не получается. Точнее получается но не всегда. Тормоза компа непредсказуемы и нужно это всегда помнить и контролировать реакцию приложения.

[ЦИТРИН]

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

Кстати, на слабом компе сокращение скрипта  посредством сабов , приводит к спонтанным  ошибкам.
Еще хуже ошибки, если при этом сеть  перегружена.
Это мой опыт .
 А если не поставлю задержки  между командами по 50-150мс  скрипт и вовсе прекращает работу выделывая всё, что ему нравится.

Не может такого быть, чтоб использование подпрограмм вызывало ошибки в работе скрипта. Ошибки скорее в неправильном использовании (как вышеописанная).
Это могу сказать точно, т.к. сам использую кликер в том числе на слабом компьютере. Хочу сказать только, что для использования на слабых компах нужен другой подход к логике и контролю. Возлагать синхронизацию работы только на задержки уже не получается. Точнее получается но не всегда. Тормоза компа непредсказуемы и нужно это всегда помнить и контролировать реакцию приложения.

Сравнивал.
 Проверял
 Простая операция.  Изменить  увеличение  страницы в Хроме.
 
Так работает c  частыми ошибками --->

 

Code: (clickermann) [Select]

SUB(SIZE_0)
   WAITMS(RND(200,250))
   LCLICK(6,136)  // 
   KEYDOWN(17) //  РАЗМЕР  НОЛЬ
   WAITMS(RND(300,400))
   KEYDOWN(48)
   WAITMS(RND(300,400))
   KEYUP(48)
   WAITMS(RND(300,400))
   KEYUP(17)
   WAITMS(RND(1000,1250))
     KEYDOWN(17)
   WAITMS(RND(300,400))
   DEFINE($size_0 = 10)
   WHILE ($size_0 < 10) //  УМЕНЬШАЕМ РАЗМЕРЫ
      KEYDOWN(189)
      WAITMS(RND(300,400))
      KEYUP(189)
      WAITMS(RND(480,580))
      INC($size_0, 1)
   END_CYC
   // ПЕРЕХОД В ПОЛНЫЙ ФОРМАТ
   WAITMS(RND(300,400))
   KEYUP(17)
   WAITMS(RND(300,400))
   KEYDOWN(122)
   WAITMS(RND(300,400))
   KEYUP(122)
   WAITMS(4550) //  переход к работе
END_SUB
а так ни разу не ошиблась

Code: (clickermann) [Select]


   WAITMS(RND(200,250))
LCLICK(6,136)  // 
KEYDOWN(17) // РАЗМЕР   НОЛЬ
WAITMS(RND(200,250))
KEYDOWN(48)
WAITMS(RND(200,250))
KEYUP(48)
WAITMS(RND(200,250))
KEYUP(17)
WAITMS(RND(1000,1250))
///////////////////
KEYDOWN(17)   
WAITMS(RND(200,250))
//////////////
KEYDOWN(189)        //  УМЕНЬШАЕМ РАЗМЕРЫ
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
KEYDOWN(189)
WAITMS(RND(300,400))
KEYUP(189)
WAITMS(RND(480,580))
///////////////////
WAITMS(500)  //   В ПОЛНЫЙ ФОРМАТ F11
KEYUP(17)
WAITMS(RND(100,150))
KEYDOWN(122)
WAITMS(RND(100,150))
KEYUP(122)
WAITMS(4550)



[Vint]

Не зависит!

У тебя написано:

Code: (clickermann) [Select]

DEFINE($size_0 = 10)
  WHILE ($size_0 < 10) //  УМЕНЬШАЕМ РАЗМЕРЫ
  ...При этом весь цикл не выполняется т.к. $size_0 уже не меньше 10

[ЦИТРИН]

Не зависит!

У тебя написано:

Code: (clickermann) [Select]

DEFINE($size_0 = 10)
  WHILE ($size_0 < 10) //  УМЕНЬШАЕМ РАЗМЕРЫ
  ...При этом весь цикл не выполняется т.к. $size_0 уже не меньше 10

Да это как раз с  запасом взял , чтобы не меньше 7 шагов было.
 Там то уменьшает, то  не пропускает шаги уменьшения,  то не выйдет в полый формат по F11 итп
А вот  без саба все отрабатывает без сбоев.

[Vint]

Прочитай ещё раз. Цикл написан не правильно. 189 не нажмется ни разу.

[Oraven]

Лучше использовать цикл FOR

Code: (clickermann) [Select]

SUB(SIZE_0)
   WAITMS(RND(200,250))
   LCLICK(6,136)  //
   KEYDOWN(17) //  РАЗМЕР  НОЛЬ
   WAITMS(RND(300,400))
   KEYDOWN(48)
   WAITMS(RND(300,400))
   KEYUP(48)
   WAITMS(RND(300,400))
   KEYUP(17)
   WAITMS(RND(1000,1250))
   KEYDOWN(17)
   WAITMS(RND(300,400))
   for ($size_0, $size_0 < 10) //  УМЕНЬШАЕМ РАЗМЕРЫ
      KEYDOWN(189)
      WAITMS(RND(300,400))
      KEYUP(189)
      WAITMS(RND(480,580))
   end_cyc
   // ПЕРЕХОД В ПОЛНЫЙ ФОРМАТ
   WAITMS(RND(300,400))
   KEYUP(17)
   WAITMS(RND(300,400))
   KEYDOWN(122)
   WAITMS(RND(300,400))
   KEYUP(122)
   WAITMS(4550) //  переход к работе
END_SUB

[ЦИТРИН]

Прочитай ещё раз. Цикл написан не правильно. 189 не нажмется ни разу.

Да) Нашел.
Это огрызки  от боя методом "научного тыка" остались.
Скопировал не посмотрел.
Разумеется  было написано не 10 , а 0 , и не = а просто , между  переменой и нулём.

[ЦИТРИН]

Лучше использовать цикл FOR

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

[ЦИТРИН]

1. Подскажите  , кто в курсе , нормальная ли ситуация, когда скрипт  не запущен ,  но  в состоянии покоя программа  нагружает процессор  примерно  на 4 % ? Цифра все время колеблется.
Что там происходит?
При этом, не имеет значения размер скрипта. Можно пустой редактор  в кликере открыть ,-  те же 4 %.
2. Заметил, что мышь начинает ощутимо подтормаживать , при  отладке  больших скриптов (28 кб. 1600 строк). Работы скрипта нет. Просто редактирую.  Меняю запятые,  названия переменных итп .
 Смотрел через ProcessExplorer. Кликер.ехе дает 25-35 % всплесков по загрузке. 
 (в это время  колесом мыши крутил в редакторе скрипт вниз).
Это нормально, или что-то неправильно?

[ЦИТРИН]

Тишина.
 Ясно. У меня одного такой косяк. Из-за величины скрипта, вероятно.
 Пойдем дальше по непоняткам.
Написал для скрипта  саб,  внутри,  которого  было  два цикла  WHILE .
Скрипт  работал , но криво. ( Саб четко проходил первый этап,  а на втором все время  сбивался. Этапы однотипны . Порознь все работает без сбоев.)
Подумал и решил разбить 1 большой  саб на 2  саба поменьше.
 Забыл перенести переменную из одного саба,  в другой.
Так вот .
 Скрипт не стал отрабатывать  первый  саб, а побежал сразу во второй, после того,  как в первом сабе наткнулся на  "чужую"  переменную. Забытая переменная в первом сабе была такого вида
$dfg = 0
  Как только перенес её во второй саб, все заработало без ошибок.
Как зависит переменная от  расположения в сабе? Что  заставляет перепрыгивать выполнение  скрипта  в другой саб? Причем , похоже что прыжок  идет  в точку , где эта переменная появляется снова.
типа IF($dfg >0) ....
 
 

[Oraven]

Про нагрузку лучше конечно объяснит разработчик но в режиме редактора кликер как минимум показывает координаты мыши и определяет цвет пиксела, видимо от сюда и нагрузка у меня она 2-3%

Про саб ты видимо опять накосячил и вместо того чтобы показать свое "творение" начинаешь шоу "Интуиция"

[Johnny]

2-3% все верно изза частого обновления информации. что в редакторе что в главном окне
и то что при тысячах строк редактор задумывается это вполне естественно. в ыбудто в ворде ниразу не прокручивали документ. так же это зависит от хар-ки вашего пэка

>>Как зависит переменная от  расположения в сабе?

никак. они все считаются глобальными. если где то ошибки с этим то скорее в вашем алгоритме.

[Vint]

Тишина.
 Ясно. У меня одного такой косяк. Из-за величины скрипта, вероятно.

У меня на домашнем загрузка ЦП в редакторе 2-3%.
На рабочем... барабанная дробь!.. 62-65% 
Я конечно понимаю комп старенький, и всё такое, но 65% на определение координат мыши это многовато.
Я в принципе не жалуюсь, уже привык. Думал это из-за того, что SP2 стоит. Третий не разрешаю ставить принудительно. Опасаюсь, что мой portable MAX2009+Vray перестанет запускаться.

[ЦИТРИН]

1. кликер как минимум показывает координаты мыши и определяет цвет пиксела, видимо от сюда и нагрузка у меня она 2-3%
2. Про саб ты видимо опять накосячил и вместо того чтобы показать свое "творение" начинаешь шоу "Интуиция"

1. Спонтанные взлеты загрузки процессора до 25 % (график  в "ProcessExplorer"), в режиме простоя редактора. Может его НОД пасет как-то?
2. ) "Творение" на 1700 строк ( 38 кб ). Зачем я буду людям морочить голову?
Работал старенький вариант тупо по гото.
Дубово, не модно, но без сбоев.
 Решил подсократить.  Ввел WHILE и  разнообразные   сабы,  некоторые даже  менял  на инклуды (думал это поможет).
 Красиво!)
Тут я согласен с корифеями.
НО!
Начались ошибки. Вернее одна ошибка.
 Проскок, или возврат в скрипте по странному закону.
 Выявил  пока связь ошибок  с   одноименными переменными.
 Один скрипт наладил.
 И  WHILE и  сабы там идут без сбоев.