Пауза бота или как сбросить тело программы

[running-frag]

Итак смысл таков.
Бегает алгоритм по циклу While (). Паралельно (или как он там пашет) бегает

AdlibRegister ("_script_checkLocal", 500)

который проверяет локал и записует в глобалы вот что ($stNeutral)

Func _script_checkLocal ()
	$stNeutral[0] = _local_neutralInLocal ()
	
	If $stNeutral[0] Then $stNeutral[1] = TimerInit ()	; стартуем таймер если нейтрал замечен после проверки
	Local $_min = 5										; глобалка в минутах
	Local $_differ = $_min * 60 * 1000					; конверт в милисекунды
	
	If TimerDiff ($stNeutral[1]) > $_differ Then		; если прошло нужно кол. времени с посл. появления в локале нейтрала, меняем флаг
		$stNeutral[2] = True							; таймаут прошёл	
	Else
		$stNeutral[2] = False							; таймаут не прошёл
	EndIf
	
	
EndFunc

После такой проверки значение $stNeutral[2] это "можем ли мы идти дальше хантить\майнить"

Сам алгоритм выглядит примерно так

Func _anomaly_startAnomalyMaker ()		; MAIN LOOP AND START FUNCTION
	
	_anomaly_warpAllToPos ()
	
	While True
		$stNpcInOverview = True
		$stLootInOverview = True
		
		_anomaly_warpToNextAnomaly ()
		_anomaly_doAnomaly ()
		
		_anomaly_ignoreDoneAnomaly ()
				
		_anomaly_warpAllToPos ()
		
	WEnd
	
	
EndFunc

Приблежаемся в к вопросу. У нас есть датчик который обновляется каждые пол секунды (можно и секунду, не суть). Есть алгоритм выполнения дейтсвия. Вопрос такой как сделать так что б "как только сработал датчик на нейтрала" тело алгоритма сбрасывалось на начало?

Есть несколько вариантов о каких я думаю
1. везде перед функциями писать

If $stNeutral[2] then Return

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

Какие мысли на этот счёт?

 

[Belfigor]

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

 

[running-frag]

Belfigor [?]

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

Если речь идёт о Select и Case то это ничего не изменит. Всё равно придётся каждый раз тыкать проверку после каждой функции, а то гляди и внутри её.

Если не правильно понял покажи плз в банальном примере.

 

[C2H5OH]

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

Можно подробнее? Какими косяками это чревато?

 

[running-frag]

Т.е. я вообще о чём. Можно тупо прописать в датчике если сработал флаг на нейтрала - отварп на пос и паузу. Но тогда нужно ж как то это передать нашему "циклу" (алгоритму) что нужно либо выйти вообще с функции либо ContinueLoop сделать. Т.к. прописывать во всех функциях (а как вы понимаете это всего лишь вершина айзбегра) это очень проблематично.

 

[Belfigor]

While 1
Select
	;А всё что будет написано тут, будет выполняться всегда, перед тем как перейти к перебору ситуаций
	MsgBox(0,0,"Оп")
	;If $neutral = true then Krisi_s_Korablja()
	;Ваще всегда
	Case Условие 1
		_anomaly_warpToNextAnomaly ()
		;Это выполнится при условии 1
	Case Условие 2
		_anomaly_doAnomaly ()
		;и тд и тп
	Case Условие 3
		_anomaly_ignoreDoneAnomaly ()
	Case Условие 4
		_anomaly_warpAllToPos ()
	Case Условие 5
		чонить еще
EndSelect
WEnd

Добавлено:

Сообщение автоматически объединено: 16 Мар 2012

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


Добавлено:

Сообщение автоматически объединено: 16 Мар 2012

Кинул бы пример, но не могу найти на компьютере папку со скриптами

 

[running-frag]

Т.е. получается по выполнению Case будет в глобалку записываться что то типо "Условие 1 сделано, можно делать Условие 2", после чего срабатывает условие 2. Так?

Но опять же, мы проверяем на нейтрала перед началом выполнения Case. А если у нас там кода на 30 секунд (образно), это в теле Case тоже нужно делать проверки, от чего я собсно и хочу уйти. :(

 

[C2H5OH]

Я бы сделал два экзешника, типа вот так

While 1
	
	If Not ProcessExists(_anomaly_startAnomalyMaker () ) Then ShellExecute(_anomaly_startAnomalyMaker () )
	
	Do
		Sleep(500)
		_script_checkLocal ()
	Until $stNeutral[2]
	
	ProcessClose( _anomaly_startAnomalyMaker() )
	
	_Hunting()
	
WEnd

 

[running-frag]

C2H5OH [?]

Можно подробнее? Какими косяками это чревато?

Хороший вопрос. Надо подумать....

По поводу двух ехе, да это выход скорей всего. Но я пока не готов резать код на ехе. Поэтому хочется в одном скрипте.

PS: В идеале конечно да, два ехе это гуд.

 

[Belfigor]

Т.е. получается по выполнению Case будет в глобалку записываться что то типо "Условие 1 сделано, можно делать Условие 2", после чего срабатывает условие 2. Так?

Но опять же, мы проверяем на нейтрала перед началом выполнения Case. А если у нас там кода на 30 секунд (образно), это в теле Case тоже нужно делать проверки, от чего я собсно и хочу уйти. :(

Посмотри мои примеры в других темах. На каждый Case отводится действие максимум в несколько секунд. Глобально ничего не кроме начальных настроек. Прочитали датчики, стартовал выбор ситуации по полученной с них информации, перед которым проверился нейтрал. Если ситуация занимает больше нескольких секунд. Надо пересматривать алгоритм т.к. он уязвим. К твоей же конструкции нет гибкости, единственный вариант - дописывание костылей, чем ты сейчас и пытаешься заниматься

 

[C2H5OH]

В идеале конечно да, два ехе это гуд.

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

OffTopic:
Вот не хватает в AutoIt команды Restart

 

[running-frag]

C2H5OH
В автоит не хватает ООП. :( Был бы он, многие бы проблемы ушли бы сами собой. :(

Belfigor
Увидел код с Select и Case в твоём исполнении. Да определённая гибкость есть. Но я пока не знаю как он будет себя вести с несколькими окнами. Точнее как его реализовать. И будет ли это лучше под мои задачи. Как ты понимаешь я не одно окно контролю алгоритмом.



Добавлено:

Сообщение автоматически объединено: 16 Мар 2012

Belfigor Есть мысли как преобразовать или изменить алгоритм (Select) на несколько окон?



Добавлено:

Сообщение автоматически объединено: 16 Мар 2012

На самом деле меня мой устраивает на 101%, проблема была только в проверке. Раньше я делал иначе, прописывал везде проверку с Return из функции. Таким образом что функция "падала" в другой цикл и там крутилась пока не будет условие выполнено (наш таймаут от нейтрала) и работало это дело как часы. Потом патч все дела, переписал немного бота (была такая необходимость) и тут снова встал вопрос. По поводу гибкости ещё скажу "опять же, это всего лишь вершина айзберга", ботоводы (кодеры) должны понимать это.

 

[Belfigor]

Этот алгоритм и разрабатывался для работы с несколькими окнами, у меня так майнеры рыли в 20 окон с танками орками рорками и тд и тп


Добавлено:

Сообщение автоматически объединено: 16 Мар 2012

Но хантеры столько окон не потянут.

 

[running-frag]

Хм, где то читал что ты сам грил что мол "пора уходить от Select'ов"... По сути да, сейчас прикидывая это возможный вариант выхода из ситуации. Но нужно проверить практическим способом... :D

 

[running-frag]

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

 

[Belfigor]

Хм, где то читал что ты сам грил что мол "пора уходить от Select'ов"... По сути да, сейчас прикидывая это возможный вариант выхода из ситуации. Но нужно проверить практическим способом... :D

пруф на то что я говорил уходить от селектов, и в каком виде я это говорил. Самый пресловутый селект - это панацея для многооконности.


Добавлено:

Сообщение автоматически объединено: 17 Мар 2012

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

 

[running-frag]

Пруфа может и не найду. Где то я читал, возможно и не ты писал, my bad.

На счёт Select'ов, есть сомнения. Надо попробывать потом скажу подойдёт ли мне такой алгоритм. Ибо при такой схеме нужно описывать все возможные варианты. Допустим в локе должно быть N целей и агра включена. Получается условие (Case) должно быть очень длинное что бы захватить все "зоны" для проверки. Плюс я пока не пробывал переписать код. И соответсвенно ещё не знаю как он будет работать.

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

На данный момент у меня почти такая же схема. Исключени только в том что глубже в одной функции я переключаюсь по дейтсвию относительно "типа" окна (т.е. это майнер\лутер\дамаге) и прохожу по действию от начало до конца с проверками.

Т.о. если в локе у меня меньше чем N целей и есть в овере нпц - лочу новые. Если нет агры - кидаю агру. Если вижу врек - лочу. Пробегаюсь функцией лута - притягиваю, агр сальвагера. Ну в общем то же что и на Select'ах только я делаю это за одну функцию с проверками согласно типу окна. (но это всё занимает явно больше чем 2-3 секунды)

Я к чему, как будет реализована задержка в цикле Select'a если нам нужно сделать несколько действий? Ну допустим.... Залочить, сагрится пушки, сагрить модули, проверить лок, проверить овервью. Если брать в расчёт алгоритм Select'ов то там нужно какие то доп. флаги или делать (как у тебя это реализовано в имперском хант боте) бааааальшая строка с перечнем контрольных "моментов" по которым собсно и делается вывод (Case). Т.е. это нужно прогонять все датчики каждый раз... Да и не очень то это удобно, это ж нужно будет на каждое новое дейтсвие прописывать все возможные варианты Case с этим действием и это код будет простынёй. :(

В общем надо пробывать...

 

[Mdsanta]

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

 

[Belfigor]

Так же формируя датчики, надо формировать их так, чтобы в ситуации когда датчик не может работать он возвращал информацию о том, что он бездействует, тогда количество ситуаций сокращается в разы. А пробег по окнам, тут всё просто:

Global $WinMax = 5 ;Максимальное количество окон с которыми мы будем работать
Global $windows[$WinMax] = ["EVE - 1", "EVE - 2", "EVE - 3", "EVE - 4", "EVE - 5"] ;Массив содержащий имена окон с которыми мы будем работать
Global $WinCount = 0;или любое другое значение в пределах массива $windows
While 1
II()
WEnd
Func II()
    $LogicState = GetLogicState();записываем в переменную всю инфу о датчиках
    Select
        ;тут у нас идет выбор необходимого действия
    EndSelect
    If $WinCount >= $WinMax Then $WinCount = 0 ;Если текущий счетчик окна больше максимального их количества, сбрасываем его значение на минимальное
    WinActivate($windows[$WinCount]) ;Активируем заданное счетчиком окно
    WinWaitActive($windows[$WinCount]) ;Ждем активацию
    $WinCount =+ 1 ;Прибавляем единичку. Или как то так, точно не помню как там прибавляется единица, можно тупо написать $WinCount = $WinCount + 1
EndFunc

Хелпа нету, автоит тоже не установлен, возможны ошибки в синтаксисе, но концепция должна быть ясна.



Добавлено:

Сообщение автоматически объединено: 20 Мар 2012

running-frag [?]

Я к чему, как будет реализована задержка в цикле Select'a если нам нужно сделать несколько действий? Ну допустим.... Залочить, сагрится пушки, сагрить модули, проверить лок, проверить овервью. Если брать в расчёт алгоритм Select'ов то там нужно какие то доп. флаги или делать (как у тебя это реализовано в имперском хант боте) бааааальшая строка с перечнем контрольных "моментов" по которым собсно и делается вывод (Case). Т.е. это нужно прогонять все датчики каждый раз... Да и не очень то это удобно, это ж нужно будет на каждое новое дейтсвие прописывать все возможные варианты Case с этим действием и это код будет простынёй.

Действия нужно дробить, активировал окно, нет цели, начал лочить, пошел в следующее. Чтобы не пришлось описывать максимальное количество действий нужно задать пару базовых датчиков (например состояние корабля варп/космос/космос у станции/в станции/в белте) по которым даже если другие датчики будут опрашиваться, они будут тут же возвращать какое-то дефолтное значение в том случае, если в ситуации когда к ним обратились, они не нужны.
В такой системе еще удобно на полуавтомате описывать всякие ситуации, когда бот тупо наткнулся на незнакомый момент, у меня он просил внимания и генерил эту саму ситуацию, мне лишь оставалось открыть код, ткнуть Ctrl+V и задать действие. Единственный минус, при таком раскладе придётся потратить несколько часов описывая с его помощью различные ситуации прежде чем ты сможешь его пустить в свободное плавание до первой неописанной ситуации. Так же можно написать генератор этих самих ситуаций.