Автокликер Clickermann :: Форум
Основной раздел => Общие вопросы => Topic started by: SimplY on June 24, 2022, 09:35:20 AM
-
Доброго дня всем!
Изучаю кликерманн (очень помогает автоматизировать работу) и много раз встречал потоки.
Как потоки помогают вам в кликере? Есть реальные примеры, где потоки реально принесли пользу? В чем они помогли?
Спасибо за ответ!
Прочитал статью http://crapware.aidf.org/forum/index.php?topic=1491.0 (http://crapware.aidf.org/forum/index.php?topic=1491.0) , но так и не понял смысл реального применения
-
Как потоки помогают вам в кликере? Есть реальные примеры, где потоки реально принесли пользу? В чем они помогли?
Если пока не понял, то тебе пока это не нужно. Как появится проблема которую решат потоки, так сразу и узнаешь. Ты узнаешь её из тысячи...
В группе ВК есть товарищи, которые пихают потоки везде, надо это или не надо. Нам с ними не по пути.
Часть примеров есть в справке и в той статье. Если обобщить и оставить только суть, то основных причин применять потоки две:
1. Нам нужно одновременное выполнение двух веток скрипта.
2. Нам нужно иметь возможность прерывать выполнение ветки кода в любом месте, с (или без) последующего перезапуска этого кода.
Чаще, но не всегда, эти причины ходят вместе.
Под "1" подходит пример с клавишами - из статьи. Где нужно нажимать кнопки клавиатуры каждую со своей периодичностью, а ля применение бафов/ударов со временем отката.
Можно сделать на паузах если они маленькие и не критично не точное выполнение периодов, ну будет чуть дольше, чем нужно. Если паузы большие, они будут мешать друг другу сильнее и может стать неприемлим такой подход. Здесь два варианта решения: на таймерах или на потоках. На потоках понятно как это будет выглядеть, плюс код будет меньше и менее сложный. На таймерах, каждому нажатию зададим свой таймер и все эти действия проверяем последовательно в цикле. Чей таймер вышел - то действие и выполняется. Точность меньше, чем на потоках из-за времени проверок и времени срабатываний вышедших таймеров.
Всё хорошо, если у нас действия простые, типа этих нажатий кнопок, а если более продолжительные? Допустим мы в цикле программы ожидаем какие-то признаки и в зависимости от признака выполняем довольно большой кусок кода. Но даже если один из признаков сработал и мы начали выполнять, нам требуется продолжать следить за другими признаками.
Пример - рыбалка на 2+ снасти. Нужно следить за разными поплавками - это можно делать и последовательно, даже именно лучше последовательно, но при клёве нужно выполнят действия по вылову. Вот действия лучше запускать в отдельном потоке. При этом может начаться клёв на другую снасть и нужно одновременно вылавливать и другой.
Здесь у нас к первой причине присоединяется и вторая.
Всё это сопровождается возможностью включать/отключать отдельные слежения (ветки кода) не городя кучу условий.
Другой пример: в давние времена, когда деревья были большими, а версия кликера маленькой, писал я скрипт на зомби ферму. Скрипт выполнял по кругу очень продолжительные и сложные действия. В основном всё работало нормально в пределах нескольких часов. Но если дольше, флеш сильно сжирал память уставал и начинал падать. Если сбои по причине интернета или браузера были очень редкими и на них писать код проверки было мало смысла, то с этим сбоем надо было решать. Решаем стандартно, следим за каким нибудь постоянным элементом игры который при падении пропадает или проверяем не появилось ли сообщение о падении (сбоев было несколько и каждый нужно ловить по своему). Написал подпрограмму проверки на сбой и при сбое действия по устранению и GOTO на старт скрипта с начала. Теперь вопрос когда и где вызывать эту подпрограмму проверки. Начал раскидывать её максимально по скрипту, внутри больших и средних по продолжительности циклов с действиями, после основных блоков. Мало. Внутри часто использующихся блоков... Стало легче, но полностью вопрос не решило.
Потому, что в скрипте было много циклов ожидания изменений на экране и с необязательным появлением картинки и с обязательным. С необязательным не так критично, а вот с обязательным нужно было добавлять вызов проверки ещё и внутрь всех этих циклов ожидания. Стало всё не очень хорошо и уж совсем не красиво и неудобно. Я до сих пор не уверен не пропустил ли я потенциальные места для проверки.
К тому же простой перезапуск всего скрипта с самого начала не подходил, он был не с самого начала, а после некоторой части инициализаций. К тому же пришлось перешерстить все переменные и задать им начальные значения не полагаясь на значения по умолчанию, ведь после перехода в начало переменные уже были использованы и там хранилось много разных значений которые нужно было сбросить.
Вот когда в кликере появились потоки эту задачу стало гораздо проще реализовать. И работала она намного надёжнее и перезапускала правильней без выпрыгивания по GOTO из десятка подпрограмм и нескольких вложенных циклов.
Вот такие дела.
Ещё пример на 2 причину: управление кнопками типа горячих клавиш. Разные кнопки запускают/останавливают разные части кода. Даже если не нужно их одновременное выполнение, особенно если не нужно!
И если реализовывать без потоков, просто по условиям запуск можно, то с остановкой проблема. Мы даже если вовремя поймаем нажатие кнопки управления (тоже вопрос как это сделать не раскидывая по скрипту капсулы из условий меняющих флаг или выпригивающих по GOTO), то если менять флаг нам всё равно нужно дождаться окончания действия или подпрыгнуть ближе к этому окончанию. С потоками же мы просто останавливаем или приостанавливаем нужный поток и всё.
-
3д шутер, поиск противников на экране по полоске хп.
Полоски бывают разных цветов, другой цвет под логом убийств.
Допустим всего 5 цветов, на поиск одного цвета 100 мс.
Если искать последовательно, то противника можно найти через 500 мс.
Если каждый цвет в отдельном потоке, то максимум через 100 мс.
Плюс в потоках сканируется своё хп и кол-во патронов.
После движения мыши на противника нужно время чтоб персонаж повернулся
Если делать это все в одном потоке, то частота сканирования получается секунда, представьте что вы играете с пингом в секунду
Через потоки информация поступает гораздо быстрее
-
Это ваша теория такая или проверено практикой?
дело в том что у НАС противоположно другие практические данные. Пять потоков обновляющие графический буфер программы будут просто вешать наглухо даже не самый старый комп.
А все команды программа выполняет ПОСЛЕДОВАТЕЛЬНО, даже если они в разных потоках.
-
Зачем в потоках обновлять графический буфер? Буфер обновляется в основном потоке, запускает потоки на анализ, после анализа потоки останавливаются, ждут обновления буфера. Если поток выполняется долго, то он может пропускать обновления буфера.
На счет последовательно и параллельно утверждать не буду, но то что с потоками работает в разы быстрее - факт.
-
Как потоки помогают вам в кликере? Есть реальные примеры, где потоки реально принесли пользу? В чем они помогли?
Если пока не понял, то тебе пока это не нужно. Как появится проблема которую решат потоки, так сразу и узнаешь. Ты узнаешь её из тысячи...
В группе ВК есть товарищи, которые пихают потоки везде, надо это или не надо. Нам с ними не по пути.
Часть примеров есть в справке и в той статье. Если обобщить и оставить только суть, то основных причин применять потоки две:
1. Нам нужно одновременное выполнение двух веток скрипта.
2. Нам нужно иметь возможность прерывать выполнение ветки кода в любом месте, с (или без) последующего перезапуска этого кода.
Чаще, но не всегда, эти причины ходят вместе.
Под "1" подходит пример с клавишами - из статьи. Где нужно нажимать кнопки клавиатуры каждую со своей периодичностью, а ля применение бафов/ударов со временем отката.
Можно сделать на паузах если они маленькие и не критично не точное выполнение периодов, ну будет чуть дольше, чем нужно. Если паузы большие, они будут мешать друг другу сильнее и может стать неприемлим такой подход. Здесь два варианта решения: на таймерах или на потоках. На потоках понятно как это будет выглядеть, плюс код будет меньше и менее сложный. На таймерах, каждому нажатию зададим свой таймер и все эти действия проверяем последовательно в цикле. Чей таймер вышел - то действие и выполняется. Точность меньше, чем на потоках из-за времени проверок и времени срабатываний вышедших таймеров.
Всё хорошо, если у нас действия простые, типа этих нажатий кнопок, а если более продолжительные? Допустим мы в цикле программы ожидаем какие-то признаки и в зависимости от признака выполняем довольно большой кусок кода. Но даже если один из признаков сработал и мы начали выполнять, нам требуется продолжать следить за другими признаками.
Пример - рыбалка на 2+ снасти. Нужно следить за разными поплавками - это можно делать и последовательно, даже именно лучше последовательно, но при клёве нужно выполнят действия по вылову. Вот действия лучше запускать в отдельном потоке. При этом может начаться клёв на другую снасть и нужно одновременно вылавливать и другой.
Здесь у нас к первой причине присоединяется и вторая.
Всё это сопровождается возможностью включать/отключать отдельные слежения (ветки кода) не городя кучу условий.
Другой пример: в давние времена, когда деревья были большими, а версия кликера маленькой, писал я скрипт на зомби ферму. Скрипт выполнял по кругу очень продолжительные и сложные действия. В основном всё работало нормально в пределах нескольких часов. Но если дольше, флеш сильно сжирал память уставал и начинал падать. Если сбои по причине интернета или браузера были очень редкими и на них писать код проверки было мало смысла, то с этим сбоем надо было решать. Решаем стандартно, следим за каким нибудь постоянным элементом игры который при падении пропадает или проверяем не появилось ли сообщение о падении (сбоев было несколько и каждый нужно ловить по своему). Написал подпрограмму проверки на сбой и при сбое действия по устранению и GOTO на старт скрипта с начала. Теперь вопрос когда и где вызывать эту подпрограмму проверки. Начал раскидывать её максимально по скрипту, внутри больших и средних по продолжительности циклов с действиями, после основных блоков. Мало. Внутри часто использующихся блоков... Стало легче, но полностью вопрос не решило.
Потому, что в скрипте было много циклов ожидания изменений на экране и с необязательным появлением картинки и с обязательным. С необязательным не так критично, а вот с обязательным нужно было добавлять вызов проверки ещё и внутрь всех этих циклов ожидания. Стало всё не очень хорошо и уж совсем не красиво и неудобно. Я до сих пор не уверен не пропустил ли я потенциальные места для проверки.
К тому же простой перезапуск всего скрипта с самого начала не подходил, он был не с самого начала, а после некоторой части инициализаций. К тому же пришлось перешерстить все переменные и задать им начальные значения не полагаясь на значения по умолчанию, ведь после перехода в начало переменные уже были использованы и там хранилось много разных значений которые нужно было сбросить.
Вот когда в кликере появились потоки эту задачу стало гораздо проще реализовать. И работала она намного надёжнее и перезапускала правильней без выпрыгивания по GOTO из десятка подпрограмм и нескольких вложенных циклов.
Вот такие дела.
Ещё пример на 2 причину: управление кнопками типа горячих клавиш. Разные кнопки запускают/останавливают разные части кода. Даже если не нужно их одновременное выполнение, особенно если не нужно!
И если реализовывать без потоков, просто по условиям запуск можно, то с остановкой проблема. Мы даже если вовремя поймаем нажатие кнопки управления (тоже вопрос как это сделать не раскидывая по скрипту капсулы из условий меняющих флаг или выпригивающих по GOTO), то если менять флаг нам всё равно нужно дождаться окончания действия или подпрыгнуть ближе к этому окончанию. С потоками же мы просто останавливаем или приостанавливаем нужный поток и всё.
Спасибо за очень доходчивый комментарий!
Из всего этого мне реально интересно несколько скриптов в одном, чтобы запускать каждый отдельной комбинацией клавиш.
Сейчас каждый день открываю 3 разных кликера, но в случае СТОП происходят проблемы. Было бы круто, чтобы одна комбинация клавиш гарантированно остановила скрипт. Тем более давно была идея создать больше команд для более мелких задач, но открывать каждый день по 5-8 кликеров из разных папок геморно.
Даже не знаю, как стабильнее, открывать один с помощью потоков или несколько как сейчас? Когда несколько кликеров, они молчат. В случае нажатия комбинации клавиш в активное состояние входит один. Но когда будет один с потоками, то я так понимаю, он всегда будет в активном состоянии, что может отразиться на быстродействии ПК. Верно?
Как это реализовать?
-
Когда несколько кликеров, они молчат. В случае нажатия комбинации клавиш в активное состояние входит один. Но когда будет один с потоками, то я так понимаю, он всегда будет в активном состоянии, что может отразиться на быстродействии ПК. Верно?
Кликер в принципе никогда не молчит если запущен. Скрипт всё равно выполняется в каком-то цикле. Цикл в котором будут проверяться только нажатие клавиш ни на что не повлияет. Главное только не допускать пустых циклов в которых нет хотя бы минимальной задержки.
-
но открывать каждый день по 5-8 кликеров из разных папок геморно.
Как это реализовать?
Перефразируя классика; " Гемор не в клозетах - гемор, в другом месте."
Что мешает запускать-закрывать, всё нужное одним запускающим-закрывающим скриптом и останавливать одним Сочетанием горячих клавиш?
-
Когда несколько кликеров, они молчат. В случае нажатия комбинации клавиш в активное состояние входит один. Но когда будет один с потоками, то я так понимаю, он всегда будет в активном состоянии, что может отразиться на быстродействии ПК. Верно?
Кликер в принципе никогда не молчит если запущен. Скрипт всё равно выполняется в каком-то цикле. Цикл в котором будут проверяться только нажатие клавиш ни на что не повлияет. Главное только не допускать пустых циклов в которых нет хотя бы минимальной задержки.
Как это сделать, если есть к примеру 3 скрипта?
Запуск первого:
ALT + Z
Запуск второго:
ALT + A
Запуск третьего:
ALT + 2
-
Когда несколько кликеров, они молчат. В случае нажатия комбинации клавиш в активное состояние входит один. Но когда будет один с потоками, то я так понимаю, он всегда будет в активном состоянии, что может отразиться на быстродействии ПК. Верно?
Кликер в принципе никогда не молчит если запущен. Скрипт всё равно выполняется в каком-то цикле. Цикл в котором будут проверяться только нажатие клавиш ни на что не повлияет. Главное только не допускать пустых циклов в которых нет хотя бы минимальной задержки.
То есть если кликер будет гореть зеленым, это не повлияет на работу ПК. Верно?
-
Верно?
Не верно, любая запущенная программа в какой-то степени влияет на работу ПК.
Как вообще кликер может гореть, на ещё зелёным?
-
Верно?
Не верно, любая запущенная программа в какой-то степени влияет на работу ПК.
Как вообще кликер может гореть, на ещё зелёным?
Так
(https://skr.sh/i/040722/P6PElyA5.jpg?download=1&name=%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%2004-07-2022%2013:02:19.jpg)
-
Когда несколько кликеров, они молчат. В случае нажатия комбинации клавиш в активное состояние входит один. Но когда будет один с потоками, то я так понимаю, он всегда будет в активном состоянии, что может отразиться на быстродействии ПК. Верно?
Кликер в принципе никогда не молчит если запущен. Скрипт всё равно выполняется в каком-то цикле. Цикл в котором будут проверяться только нажатие клавиш ни на что не повлияет. Главное только не допускать пустых циклов в которых нет хотя бы минимальной задержки.
Как это сделать, если есть к примеру 3 скрипта?
Запуск первого:
ALT + Z
Запуск второго:
ALT + A
Запуск третьего:
ALT + 2
Сделать поток для управления, который проверяет нажатые клавиши
if(iskeydown(#1)=1)
if($status1=0)
print("start 1")
else
print("stop 1")
end_if
$status1=$status1^1
wait(5) // задержка чтоб отпустить кнопку до следующего переключения
end_if
if(iskeydown(#2)=1)
if($status2=0)
print("start 2")
else
print("stop 2")
end_if
$status2=$status2^1
wait(5) // задержка чтоб отпустить кнопку до следующего переключения
end_if
-
А как насчет того что потоки нельзя перезапустить?То есть как я понимаю вариант годится только для скриптов в десяток строк.
-
А как насчет того что потоки нельзя перезапустить?То есть как я понимаю вариант годится только для скриптов в десяток строк.
В смысле нельзя перезапустить?
У меня вот так работает, останавливается и запускается
thread(scan_hp,0)
...
setthread(scan_hp,2)
end_thread
WHILE(1)
GETSCREEN
setthread(scan_hp,1)
setthread(scan_amo,1)
setthread(scan_enemy,1)
waitms(50)
END_CYC
-
как я понимаю
забудьте эту фразу и никогда не используйте, ничего, Вы не понимаете.
Потоки перезапускаются в любой момент, размер скриптов не ограничен, Вам должно быть мучительно стыдно! :-[
-
забудьте эту фразу и никогда не используйте, ничего, Вы не понимаете.
Потоки перезапускаются в любой момент, размер скриптов не ограничен, Вам должно быть мучительно стыдно! :-[
Дико извиняюсь за свою тупость.На крамольные мысли меня навели рассуждения одного из уважаемых мною пользователей программы.
Потоки пока еще очень сырые.
GETSCREEN не изолирован.
Переменные не изолированы.
Привязка одна на весе потоки.
Поток возможно поставить на паузу, но нельзя перезапустить.
Короче что то не сложное можно запихнуть в поток, но пытаться распихать 4 скрипта по потокам и чтоб все работало как 4 кликера пока рано.
Будем ждать дальнейших улучшений потоков.
-
Дико извиняюсь за свою тупость.На крамольные мысли меня навели рассуждения одного из уважаемых мною пользователей программы.
Поток возможно поставить на паузу, но нельзя перезапустить.
...
Будем ждать дальнейших улучшений потоков.
Это была, либо бета версия, либо, самая первая с потоками, на которую очень быстро вышел фикс по перезапуску.
-
Если Вас не затруднит,не могли бы подсказать пофиксили ли другие проблемы из этого списка?
GETSCREEN не изолирован.
Переменные не изолированы.
Привязка одна на все потоки.
-
Если Вас не затруднит,не могли бы подсказать пофиксили ли другие проблемы из этого списка?
GETSCREEN не изолирован.
Переменные не изолированы.
Привязка одна на все потоки.
Снова ошибаетесь, если вдуматься в суть, то это не проблемы, а ФИЧИ! ;)
-
Если Вас не затруднит,не могли бы подсказать пофиксили ли другие проблемы из этого списка?
GETSCREEN не изолирован.
Переменные не изолированы.
Привязка одна на все потоки.
Это не проблемы, а этапы. На том этапе сделали так, т.к. это требовало меньше изменений. В дальнейшем автор планировал разделить. Не срослось.
-
Если Вас не затруднит,не могли бы подсказать пофиксили ли другие проблемы из этого списка?
GETSCREEN не изолирован.
Переменные не изолированы.
Привязка одна на все потоки.
Снова ошибаетесь, если вдуматься в суть, то это не проблемы, а ФИЧИ! ;)
Попробую вдуматься.Передо мной стоит задача открыть 12 одинаковых окон с разными аккаунтами и воспроизвести в них одинаковый скрипт длительностью 7 минут.Ок включаю синхронизацию на эмуляторе и через 7 минут моя задача выполнена.
А что с потоками,сейчас подумаю.Открываю окна и начинаю по очереди перепривязываясь выполнять скрипт.Учитывая задержки на перепривязку у меня ушло 87 минут или 1 час 27 минут или почти полтора часа.
Да,это действительно фича.Дает время задуматься,а надо ли мне то,чем я занимаюсь.
Я ничего не упустил в своих размышлениях?
-
Если вопрос решается синхронизацией, не понимаю зачем сюда городить потоки.
Если время выполнения 7 минут, то очевидно есть какие-то паузы. Вместо пауз можно делать то же действие в другом окне.
Для эмуляторов делал без потоков. 9 эмуляторов на экране, делаем скрин и в цикле перебираем все 9 окон (смещения окон прописаны) все координаты идут с переменной смещения pxl(100+$dx,100+$dy)
Синхронизация не применима, тк матчи завершаются за разное время.
В принципе то же самое можно сделать с потоками, по потоку на окно, будет чуть быстрее (не будут суммироваться паузы wait, но это не критично)
-
Я ничего не упустил в своих размышлениях?
Ваши размышления, в очередной раз пошли своим путём, естественно получен результат далёкий от нужного и традиционно сделан неверный вывод, на основе собственной ошибки.
Вы хоть размышляете и пробуете, а есть пользователи признающие только готовый чужой скрипт, даже простая смена координат, для них задача непосильная. ;)
-
Если вопрос решается синхронизацией, не понимаю зачем сюда городить потоки.
Если время выполнения 7 минут, то очевидно есть какие-то паузы. Вместо пауз можно делать то же действие в другом окне.
Для эмуляторов делал без потоков. 9 эмуляторов на экране, делаем скрин и в цикле перебираем все 9 окон (смещения окон прописаны) все координаты идут с переменной смещения pxl(100+$dx,100+$dy)
Синхронизация не применима, тк матчи завершаются за разное время.
В принципе то же самое можно сделать с потоками, по потоку на окно, будет чуть быстрее (не будут суммироваться паузы wait, но это не критично)
В моем понимании синхронизация и есть потоки.Один скрипт в 12 потоков в моем случае.
Немного не понял как Вы избавляетесь от wait.В моем скрипте они везде нужны так как дают время на перезагрузку графики экрана.То есть если убрать wait кликер щелкнет по месту где,например только через секунду отрисуется кликабельная кнопка на которую нужно нажать.А в данный момент там просто серенький некликабельный фон
-
В моем понимании синхронизация и есть потоки.Один скрипт в 12 потоков в моем случае.
Немного не понял как Вы избавляетесь от wait.В моем скрипте они везде нужны так как дают время на перезагрузку графики экрана.То есть если убрать wait кликер щелкнет по месту где,например только через секунду отрисуется кликабельная кнопка на которую нужно нажать.А в данный момент там просто серенький некликабельный фон
Синхронизация может быть частным случаев потоков, а могут и разные действия выполнять. Вот только потоки выполняются параллельно, а вы почему то последовательно посчитали по 7 минут и получили более 84 минут.
При последовательном выполнении паузы заменются полезным действием в другом окне. Пока вы совершаете то же действие в 11 других окнах, в первом окне графика уже перезагрузится.
-
В моем понимании синхронизация и есть потоки.Один скрипт в 12 потоков в моем случае.
Немного не понял как Вы избавляетесь от wait.В моем скрипте они везде нужны так как дают время на перезагрузку графики экрана.То есть если убрать wait кликер щелкнет по месту где,например только через секунду отрисуется кликабельная кнопка на которую нужно нажать.А в данный момент там просто серенький некликабельный фон
Синхронизация может быть частным случаев потоков, а могут и разные действия выполнять. Вот только потоки выполняются параллельно, а вы почему то последовательно посчитали по 7 минут и получили более 84 минут.
При последовательном выполнении паузы заменются полезным действием в другом окне. Пока вы совершаете то же действие в 11 других окнах, в первом окне графика уже перезагрузится.
Привязка одна на все потоки.Последовательно посчитал основываясь на этом утверждении как я понимаю уже вылечили и привязаться можно одновременно к нескольким окнам в нескольких потоках?
по поводу разных действий в разных окнах идея тоже понятна.В первом окне графика не всегда успевает прогружаться.Да я могу разбить скрипт скажем на полсотни условных блоков и в разных окнах выполнять разные действия,для баловства.Скорости выполнения задачи это не даст.
ну и что самое печальное,по итогу мой скрипт длиной полторы тысячи строчек раздуло до плюс минус восемнадцати тысяч строк.
По большей части из за раздувшегося скрипта делаю свой вывод для многооконки лучше пользоваться синхронизацией.Ну а для потоков работы тоже хватает
-
В моем понимании ...
Немного не понял как ...
как я понимаю...
идея тоже понятна...
это не даст.
раздуло...
Наркотическая ломка понятийного аппарата, назло логике летом отморожу уши ;D
-
https://www.youtube.com/watch?v=XzelRT4MOJY (https://www.youtube.com/watch?v=XzelRT4MOJY)
-
В моем понимании ...
Немного не понял как ...
как я понимаю...
идея тоже понятна...
это не даст.
раздуло...
Наркотическая ломка понятийного аппарата, назло логике летом отморожу уши ;D
я бы сказал согласно логике а не вопреки.Так как своя проблема ближе к телу.
Вот и приходится свою проблему натягивать за уши на потоки циклы ифы и вайты.
И поверьте не зря.По новому подошел к выполнению нескольких блоков своего скрипта .
сократил его еще на 17 секунд.В идеале конечно хотелось бы сократить скрипт до одной секунды описав его одной строкой :)
-
как я понимаю уже вылечили и привязаться можно одновременно к нескольким окнам в нескольких потоках?
Где и кто это сказал? У вас часто появляются выводы непонятно на чём основывающиеся.
Исправили только перезапуск потока, ведь о нём упоминалось в начале. Даже, не исправили, а доработали по просьбе. Это было довольно просто.
А вот разные привязки, разделённые буферы, переменные и подпрограммы - это довольно сложные изменения. Потребовалось бы вводить области видимости по одной из схем. Вводить динамические буферы в памяти и научить с ними работать все существующие команды, чтоб они понимали с каким буфером нужно работать в данный момент. Там ещё вагон и тележка проблем, поэтому автор отложил до "лучших" времён. А сейчас времена не "лучшие" :D
-
как я понимаю уже вылечили и привязаться можно одновременно к нескольким окнам в нескольких потоках?
Где и кто это сказал? У вас часто появляются выводы непонятно на чём основывающиеся.
Исправили только перезапуск потока, ведь о нём упоминалось в начале. Даже, не исправили, а доработали по просьбе. Это было довольно просто.
А вот разные привязки, разделённые буферы, переменные и подпрограммы - это довольно сложные изменения. Потребовалось бы вводить области видимости по одной из схем. Вводить динамические буферы в памяти и научить с ними работать все существующие команды, чтоб они понимали с каким буфером нужно работать в данный момент. Там ещё вагон и тележка проблем, поэтому автор отложил до "лучших" времён. А сейчас времена не "лучшие" :D
Выводы я делал по ходу дискуссии.Не отрицаю,что в большинстве неправильные.Просто клещами приходится вырывать информацию по заинтересовавшей теме.Как вишенку на торте к концу дискуссии получил от Вас чуть более развернутый ответ,за что отдельное спасибо
-
Добавлю и я свои пять копеек про использование потоков:
1 Мониторит нажатие клавиш, запускает и останавливает другие потоки.
2 Считывает количество жизни, маны, дебафы, координаты персонажей и вычисляет расстояние до лекарей/маназаливалок во всех окнах
3 На основании данных из 2го потока определяет последовательность кого и кем лечить/маназаливать/снимать дебафы
4 Бег бота по контрольным точкам
5 Ищет цель, если находит, останавливает 4й поток, управляет боем
6 Осуществляет 2х минутный баф
7 Осуществляет 20ти минутный баф
Кроме этого есть еще отдельный процесс написанный на Дельфи, который определяет в какой зоне расположены объекты (не боевая, боевая) и трассировку луча от дамагера до цели.
А также выводит в титул каждого объекта доступную информацию.
-
Добавлю и я свои пять копеек про использование потоков:
1 Мониторит нажатие клавиш, запускает и останавливает другие потоки.
2 Считывает количество жизни, маны, дебафы, координаты персонажей и вычисляет расстояние до лекарей/маназаливалок во всех окнах
3 На основании данных из 2го потока определяет последовательность кого и кем лечить/маназаливать/снимать дебафы
4 Бег бота по контрольным точкам
5 Ищет цель, если находит, останавливает 4й поток, управляет боем
6 Осуществляет 2х минутный баф
7 Осуществляет 20ти минутный баф
Кроме этого есть еще отдельный процесс написанный на Дельфи, который определяет в какой зоне расположены объекты (не боевая, боевая) и трассировку луча от дамагера до цели.
А также выводит в титул каждого объекта доступную информацию.
коротко и лаконично.Огромное спасибо.подвести можно просто кучу игр так что работы потокам вагон и маленькая тележка
-
Как это сделать, если есть к примеру 3 скрипта?
Запуск первого:
ALT + Z
Запуск второго:
ALT + A
Запуск третьего:
ALT + 2
Сделать поток для управления, который проверяет нажатые клавиши
if(iskeydown(#1)=1)
if($status1=0)
print("start 1")
else
print("stop 1")
end_if
$status1=$status1^1
wait(5) // задержка чтоб отпустить кнопку до следующего переключения
end_if
if(iskeydown(#2)=1)
if($status2=0)
print("start 2")
else
print("stop 2")
end_if
$status2=$status2^1
wait(5) // задержка чтоб отпустить кнопку до следующего переключения
end_if
Прекрасно! Спасибо! Но Как указать СТОП для скрипта? Чтобы при нажатии клавиши скрипт отработал своё и снова выбор нажатия клавиши. Возможно ли сделать комбинациями клавиш?
-
Но Как указать СТОП для скрипта? Чтобы при нажатии клавиши скрипт отработал своё и снова выбор нажатия клавиши. Возможно ли сделать комбинациями клавиш?
THREAD(th1, 0)
//сюда ставишь первый сценарий
LOGWRITE("Сценарий 1 завершился")
$status1 = 0
SETTHREAD(th1, 2) // сценарий останавливается после прохода
END_THREAD
THREAD(th2, 0)
//сюда ставишь второй сценарий
LOGWRITE("Сценарий 2 завершился")
$status2 = 0
SETTHREAD(th2, 2)
END_THREAD
THREAD(th3, 0)
//сюда ставишь третий сценарий
LOGWRITE("Сценарий 3 завершился")
$status3 = 0
SETTHREAD(th3, 2)
END_THREAD
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IF(ISKEYDOWN(#ALT) & ISKEYDOWN(#Z))
$status1 = $status1 ^ 1
IF($status1)
SETTHREAD(th1, 1)
LOGWRITE("Сценарий 1 запущен")
ELSE
SETTHREAD(th1, 0) // или код 2 если нужен перезапуск
LOGWRITE("Сценарий 1 остановлен")
END_IF
WHILE(ISKEYDOWN(#ALT) & ISKEYDOWN(#Z))
WAITMS(10)
END_CYC
END_IF
IF(ISKEYDOWN(#ALT) & ISKEYDOWN(#A))
$status2 = $status2 ^ 1
IF($status2)
SETTHREAD(th2, 1)
LOGWRITE("Сценарий 2 запущен")
ELSE
SETTHREAD(th2, 0) // или код 2 если нужен перезапуск
LOGWRITE("Сценарий 2 остановлен")
END_IF
WHILE(ISKEYDOWN(#ALT) & ISKEYDOWN(#A))
WAITMS(10)
END_CYC
END_IF
IF(ISKEYDOWN(#ALT) & ISKEYDOWN(#2))
$status3 = $status3 ^ 1
IF($status3)
SETTHREAD(th3, 1)
LOGWRITE("Сценарий 3 запущен")
ELSE
SETTHREAD(th3, 0) // или код 2 если нужен перезапуск
LOGWRITE("Сценарий 3 остановлен")
END_IF
WHILE(ISKEYDOWN(#ALT) & ISKEYDOWN(#2))
WAITMS(10)
END_CYC
END_IF
WAITMS(20)
-
Но Как указать СТОП для скрипта? Чтобы при нажатии клавиши скрипт отработал своё и снова выбор нажатия клавиши. Возможно ли сделать комбинациями клавиш?
THREAD(th1, 0)
//сюда ставишь первый сценарий
LOGWRITE("Сценарий 1 завершился")
$status1 = 0
SETTHREAD(th1, 2) // сценарий останавливается после прохода
END_THREAD
THREAD(th2, 0)
//сюда ставишь второй сценарий
LOGWRITE("Сценарий 2 завершился")
$status2 = 0
SETTHREAD(th2, 2)
END_THREAD
THREAD(th3, 0)
//сюда ставишь третий сценарий
LOGWRITE("Сценарий 3 завершился")
$status3 = 0
SETTHREAD(th3, 2)
END_THREAD
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IF(ISKEYDOWN(#ALT) & ISKEYDOWN(#Z))
$status1 = $status1 ^ 1
IF($status1)
SETTHREAD(th1, 1)
LOGWRITE("Сценарий 1 запущен")
ELSE
SETTHREAD(th1, 0) // или код 2 если нужен перезапуск
LOGWRITE("Сценарий 1 остановлен")
END_IF
WHILE(ISKEYDOWN(#ALT) & ISKEYDOWN(#Z))
WAITMS(10)
END_CYC
END_IF
IF(ISKEYDOWN(#ALT) & ISKEYDOWN(#A))
$status2 = $status2 ^ 1
IF($status2)
SETTHREAD(th2, 1)
LOGWRITE("Сценарий 2 запущен")
ELSE
SETTHREAD(th2, 0) // или код 2 если нужен перезапуск
LOGWRITE("Сценарий 2 остановлен")
END_IF
WHILE(ISKEYDOWN(#ALT) & ISKEYDOWN(#A))
WAITMS(10)
END_CYC
END_IF
IF(ISKEYDOWN(#ALT) & ISKEYDOWN(#2))
$status3 = $status3 ^ 1
IF($status3)
SETTHREAD(th3, 1)
LOGWRITE("Сценарий 3 запущен")
ELSE
SETTHREAD(th3, 0) // или код 2 если нужен перезапуск
LOGWRITE("Сценарий 3 остановлен")
END_IF
WHILE(ISKEYDOWN(#ALT) & ISKEYDOWN(#2))
WAITMS(10)
END_CYC
END_IF
WAITMS(20)
ЭТО ТОП!!!!!!!!! ОГРОМНОЕ СПАСИБО!!!!!!!!!