Обзор архитектуры ботов в EVE

[Insari]

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

История темы

Спойлер

Придя на данный раздел форума почти каждый имеет, или загорается желанием попробовать свои силы в написании ботов для EVE-Online.
Некоторые, приходят сюда, чтобы "нахаляву" найти здесь работающий бот и не прилагая дополнительных усилий использовать его.
К счастью, вторая категория, благодаря патчам ССР и содержащихся в них изменениям всё чаще стала "обламываться" в своих законных стремлениях
И хотя большинство целей начинающих ботоводов удовлетворит "косметический ремонт" уже представленных на форуме ботов, надеюсь, что наиболее активная часть сообщества "стремится к большему"
Чтобы осуществить это желание приходится задуматься об архитектуре своего проекта.

Глава 1. Соло-боты

Часть 1. Вермишель
Данная архитектура представляет собой последовательно заданную логику поведения системы, текущее состояние в которой определяется по тому участку в коде, где на данный момент сосредоточено управление.
Основное отличие "вермишели" состоит в том, что выходов из состояния в котором пребывает система, за исключением прописанных внутри уже имеющегося блока не предусмотрено.
Добавление новой логики, заключается в расширении ветвлений внутри тех или иных под-блоков путем написания нового кода для обработки слежения за этими ветвлениями.
Другими словами:
[list type=decimal]
[*]"вермишель" помнит свое состояние, потому что находится в нем физически (в коде)
[*]для перехода в другое состояние должно произойти событие которое ожидает "вермишель", иначе оно останется в текущем состоянии навсегда
[*]добавление в "вермишель" таймеров выхода не только сильно загромождает код, но и делает его поддержку и расширение достаточно трудоемким
[*]в случае возникновения ошибок интерфейса или аналогичных проблем бот неработоспособен или "бото-очевиден"
[*]"прозрачность" логики, зачастую, способствует легкому вхождению новичка в разрабатываемую проблему
[/list]

Часть 2. Сенсорный автомат
Данная архитектура относится к разновидности конечных автоматов, в котором отсутствует специфическая задача на запоминание текущего состояния системы.
Создается таблица (функция) переходов, каждая строка которой наполняется уникальным набором состояний датчиков и внутренних переменных.
В процессе бесконечного цикла сначала определяется состояние датчиков наблюдения, после чего выбирается (case) в таблице соответствующее поведение системы.
В случае, если текущее состояние не осознано функцией переходов, генерируется исключение, которое разработчик использует для дальнейшего наполнения таблицы.
Другими словами:
[list type=decimal]
[*]у нас нет специфического хранилища для состояния системы, т.е. мы не помним где мы были до этого конкретно
[*]у нас нет названий для состояний и соответствующей логики для обработки диаграмм переходов
[*]мы можем хранить состояния некоторый учитываемых нами в таблице переменных
[*]набор текущих состояний датчиков и учитываемых переменных влияет на выбор функцией переходов поведения системы в данный момент
[*]если запустить бот в произвольном местонахождении вероятность корректного поведения зависит от наполнения таблицы переходов
[*]в случае возникновения ошибок интерфейса или аналогичных проблем поведение бота зависит от наполненности таблицы переходов
[*]для адекватного наполнения и тестирования таблицы переходов, мы должны использовать дополнительные инструменты (иначе утонем в сотнях строк текста состояний системы)
[*]измененное состояние сознание для облегченного восприятия функции переходов не всегда доступно для новичка
[/list]

Часть 3. Гибридные боты
Вид пытающийся сочетать в себе перечисленные выше архитектуры.
Жизнеспособность, при учете затраченных усилий, вызывает сомнения в смысле подобного подхода.

Глава 2. Мульти-боты на одной машине
Глава 3. Мульти-боты в сети


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

 

[Belfigor]

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

 

[hikki]

также замечу, Гибридные боты, часто встречаются у тех кто учился в процессе написания бота, обычно это изначально простая лапша, и затем по мере ее усложнения приходит понимание о том как надо)) старое переписывать лень, да и работает же, новое пишется уже с учетом case логики, костыли для стыковки старого и нового занимают больше времени чем реальное наполнение функционалом.
В общем изначально делать гибрид не стоит, если только не с целью получить удовольствие сродни мазохистскому.

 

[luhta]

немного не потеме но тоже косаемо ботов увы невстречал на строницах этого форума но использую для написания своих ботов чтобы бот работал на любом компе я задаю настройку стондартного росполажения окон тоесть бот запускаясь C:\EVE\eve.exe /end /LUAFF" в первоначальном варианте, растовляет окошки и устанавливает расширение в стандартоном для меня варианте и уже зная где в какой точни какое окно я дальше делаю бота

 

[bugaj]

может проще все координаты считать относительно окна приложения? ) и тогда пофиг где находится окно. Перед кликом вытаскивать его на самый верх и профит! оно может быть даже за экраном, перекрыто другими окнами - все это не имеет значения )

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

А будут примеры того, как такое можно изобрести?

Совсем без вермишели, типа например функции по андоканью со станции, не получится. Иначе это просто искуственный интелект получается ) получается нужно изобретать какой то базовый ИИ который будет учится осваиваться в любой обстановке и уметь ее самому себе описывать как то. В таком случае в этой писанине создателю разобраться будет практически нереально и общение с ним должно осуществлятся на каком то более высоком уровне. Опять же встает вопрос о том, а не должны ли все таки быть тогда у робота какие то базовые "понятия"?

+ Тогда нужно очень продвинутое распознавание образов, т.е. это не автоит )

 

[Lexx98]

bugaj [?]

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

Даже это можно сделать. Это просто получается Конечный Автомат. Состояний у него будет прилично, да, и входных параметров сколько предусмотришь, но тем не менее...

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

Всем интересующимся рекомендую погуглить теорию конечных автоматов.

 

[bugaj]

Хорошо, тогда прежде всего стоит определиться с целями этой темы. Особенно в свете систем табу существующих на этом форуме. :laugh:

1. Эту тему нужно дополнить конкретной структурой описывающей общий алгоритм работы робота применительно к Eve Online например. (ну то есть например разработать общую структуру таблиц состояний и датчиков и переходов, в которую останется только вписать датчики для интересующей ситуации, да заполнить состояния и переходы)
2. Эту тему дополнить рассуждениями о сферическом коне в вакууме работающим по принципам конечного автомата (хотя зачем, ведь можно погуглить теорию конечных автоматов, там как раз об этом).
3. Эту тему дополнить новыми заголовками, а остальное халявщики пусть додумывают сами? ;D

 

[Belfigor]

за примером далеко ходить не надо, посмотри любого моего бота.

 

[bugaj]

не спасибо, я надеялся, что это что то поприкольнее.

 

[DJ_Tommy]

bugaj [?]

не спасибо, я надеялся, что это что то поприкольнее.

Вот если ты посмотришь темку про хантбота созданную Белфигором там ты как раз и увидишь набор датчиков, которые полностью описывают нахождение и состояние коробля при заданных конечных условиях.
т.е.
шаг 1: снимаем показания всех датчиков
шаг 2: на основании набора данных выполняем какие то действия(набор действий)
шаг 3: возвращаемся к шагу 1

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

 

[bugaj]

Вот если ты посмотришь темку про хантбота созданную Белфигором там ты как раз и увидишь набор датчиков, которые полностью описывают нахождение и состояние коробля при заданных конечных условиях.
т.е.
шаг 1: снимаем показания всех датчиков
шаг 2: на основании набора данных выполняем какие то действия(набор действий)
шаг 3: возвращаемся к шагу 1

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

Ну я конечно не видел этого бота ) Но я так понимаю, что все это прописано в коде программы, что как то не совсем то, т.к. чтобы чего то дописать или исправить опять нужно чего то кодить и чем больше ты кодишь тем менее наглядно все это выглядит и т.д. и т.п. да и универсальности тут неахти. По моим представлениям, для упрощения задачи (т.е. если в неупрощенном виде, то функции бот тоже должен делать сам, но это из раздела фантастики на данный момент), в коде нужно описывать только функции (переходы), т.к. например функция "Андок". А показания датчиков и соотвествующие им состояния и переходы по которым можно выйти из этих состояний и по которым можно в них войти хранить в таблицах во внешних файлах, которые можно редактировать как в Excell. Т.е. в итоге не нужно ничего кодить каждый раз, а просто заполнять таблицу. Перед началом работы робота ему задается состояние которое нужно достичь. Бот сравнивает текущее с требуемым и по таблицам "вычисляет маршрут" до требуемого состояния и выполняет все переходы, которые необходимо. Также если учесть то, что разные переходы могут делать одинаковые действия (например можно открыть ангар мышкой, а можно комбинацей клавиш с клавиатуры), то можно внести некоторый "рандом", чтобы уменьшить подозрения в ботоводстве. Т.е. в коде описываются только функции и механизм который будет интерпретировать данные этой таблицы. Кроме того встречая новую комбинацию датчиков незапланированную, бот может сам записать ее в таблицу, а пользователю нужно лишь придумать название, ну и прописать какие переходы для него возможны. Также если определится с тем что есть датчик и как его интерпретировать. То думаю также реально сделать чтобы датчики в эти таблицы также можно было бы добавлять в пользовательском режиме, на самом деле у меня уже что то в этом роде сделано по поводу "датчиков". Но это если считать за датчик картинку, которая если есть, то делаем то то, а если нет то не делаем. Т.к. всего 2 значения у "датчика". :wacko:

Как то так......я уже правда подзабыл чо хотел )

 

[DJ_Tommy]

на самом деле статусов у датчиков может быть сколько угодно. Например у меня на дронах несколько статусов:
1. дроны выпущены, светятся зеленым
2. дроны выпущены, светятся красным
3. ------------------------------------ желтым
4. дроны выпущены, группа дронов свернута
5. дроны собраны, групы свернуты
6.... ну и так далее

В т.ч. и на состояние ХП шипа, состояие скорости и проч.

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

 

[Belfigor]

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

 

[bugaj]

а если бы было так просто то я б и не писал даже тут ) показаниями датчика может быть скорость или расстояние например (


Добавлено:

Сообщение автоматически объединено: 11 Окт 2011

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


Добавлено:

Сообщение автоматически объединено: 11 Окт 2011

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

это как? Может просто эти датчики соотносить с разными состояниями? Вот у состояний иерархия точно напрашивается...

 

[Belfigor]

ну в смысле вот например у тебя есть датчик на кнопку дока, есть нет 1 пиксель по цвету
есть датчик например на овервью, есть нет 1 пиксель по цвету
есть датчик на варп, есть нет 1 пиксель по цвету
3 отдельных датчика, но по их данным можно сделать вывод в доке ли ты, в космосе ли ты, в варпе ли ты или ты вообще грузишься со станции в косомс.
Отдельно датчик на варп не скажет тебе 100% точно в варпе ты или нет
Отдельно датчик на кнопку андока так же не скажет тебе 100% точно в доке ты или нет
Отдельно датчик на овервью так же не скажет тебе видишь ли ты овервью или нет

Объединив эти 3 датчика воедино ты уже можешь делать полноценный вывод о состоянии корабля.

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

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

Case $ToCheck = "Location" ;ConCheck("Location")

            ;Returns: "Космос - вижу станцию", "Станция", "Космос - вижу астероиды", "Идет загрузка...", "Нахожусь в варпе"
;~             Global $Location
            #Region - Настройки функции проверки положения и состояния корабля
            Local $LogicState = "Location: "
            If Not IsArray($Location) Then
                Global $Location[6][7]=[[0,0,0,0,0,0],[61, 22,62, 23,0xCCCCCC,1,"Menu Button Col"],[19,720,19,720,0xFFDE42,20,"Undock Button Col"],[441, 549,500, 560,0xBDBDBD,10,"Warp Message Col"],[770,169,770,180,0xFFFFFF,2,"Station Icon Col"],[868,175,878,175,0xB6B6B6,50,"Asteroid Name Col"]];0 = Undock, 1 = MenuButton, 2 = OverviewStation, 3 = Asteroid
            EndIf
            #EndRegion - Настройки функции проверки положения и состояния корабля
            Select
                Case $AdvCheck = "Courier"
;~                     MsgBox(0,0,0)
                    For $i = 1 To 3 Step 1
                        PixelSearch($Location[$i][0],$Location[$i][1],$Location[$i][2],$Location[$i][3],$Location[$i][4],$Location[$i][5], 1, $CurWin_hwnd)
                        If Not @error Then
                            If $Location[$i][6] = "Warp Message Col" Then Return "Нахожусь в варпе"
                            If $Location[$i][6] = "Undock Button Col" Then Return "На станции"
                        ElseIf @error Then
                            If $Location[$i][6] = "Menu Button Col" Then Return "Идет загрузка...";Если не обнаружена кнопка меню
;~                             $Location[0][0] = "Идет загрузка..." ;Ситуацию когда идет загрузка мы обрабатываем даже не доходя до финального распознавания ситуации, ибо работа остальных датчиков этого модуля в момент загрузки бессмысленна.
;~                             Return $Location[0][0]
;~                             EndIf
                        EndIf
                    Next
                    Return "В космосе"
            EndSelect

            For $i = 1 To UBound($Location, 1)-1 Step 1 ;Проверяем последовательно все ячейки массива
                PixelSearch($Location[$i][0],$Location[$i][1],$Location[$i][2],$Location[$i][3],$Location[$i][4],$Location[$i][5], 1, $CurWin_hwnd)
                If Not @error Then ;Если текущий проверяемый цвет по заданным координатам обнаружен
                    If $Location[$i][6] = "Warp Message Col" Then ;Если обнаружено сообщение варпа
                        $Location[0][0] = "Нахожусь в варпе" ;Назначить возвратом сообщение "Нахожусь в варпе"
                        Return $Location[0][0]
                    EndIf
                    $LogicState &= $Location[$i][6]&": Found | " ;Иначе к текущему логическому циклу прибавить название проверяемого объекта и статус Found
                Else ;Иначе если текущий проверяемый цвет по заданным координатам НЕ обнаружен
                    If $Location[$i][6] = "Menu Button Col" Then ;Если не обнаружена кнопка меню
                        $Location[0][0] = "Идет загрузка..." ;Ситуацию когда идет загрузка мы обрабатываем даже не доходя до финального распознавания ситуации, ибо работа остальных датчиков этого модуля в момент загрузки бессмысленна.
                        Return $Location[0][0]
                    EndIf
                    If $Location[$i][6] = "Warp Message Col" Then ContinueLoop ;Если не обнаружено сообщение варпа, тупо продолжить цикл Next не доходя до его конца
                    $LogicState &= $Location[$i][6]&": NOT Found | " ;Иначе к текущему логическому циклу прибавить название проверяемого объекта и статус NOT Found
                EndIf
            Next
            Select
;~                 Case $LogicState = "Location: Menu Button Col: Found | Undock Button Col: NOT Found | Warp Message Col: NOT Found | Station Icon Col: Found | Asteroid Name Col: Found | "
                Case $LogicState = "Location: Menu Button Col: Found | Undock Button Col: NOT Found | Station Icon Col: Found | Asteroid Name Col: Found | "
                    $Location[0][0] = "Космос - вижу станцию"

                Case $LogicState = "Location: Menu Button Col: Found | Undock Button Col: Found | Station Icon Col: NOT Found | Asteroid Name Col: NOT Found | "
                    $Location[0][0] = "Станция"

                Case $LogicState = "Location: Menu Button Col: Found | Undock Button Col: NOT Found | Station Icon Col: NOT Found | Asteroid Name Col: Found | "
                    $Location[0][0] = "Космос - вижу астероиды"

                Case $LogicState = "Location: Menu Button Col: Found | Undock Button Col: NOT Found | Station Icon Col: Found | Asteroid Name Col: NOT Found | "
                    SetError(1)
                    $Location[0][0] = "Космос - вижу станцию"
                    #cs - Описание пресета
                        Вижу иконку станции но невижу в колонке с названием серого цвета. Мы находимся в космосе и видим станцию.
                        Возможно курсор мыши наведен на вторую строку овервью и всплывший внутриигровой тултип закрыл собой в первой
                        строке колонку Name. Надо более аккуратно учить бота работать мышью, а лечить эту ситуацию смещением мыши в
                        другое место от ее текущего положения. Так же эта ситуация может быть вызвана тотальным сбоем настроек, например
                        окно трюма заползло на окно овервью.
                    #ce - Описание пресета

                Case $LogicState = "Location: Undock Button Col: NOT Found | Menu Button Col: Found | Station Icon Col: NOT Found | Asteroid Name Col: NOT Found | "
                    SetError(2)
                    $Location[0][0] = "Работа невозможна: Я ничего не вижу кроме треугольника игрового меню"
                    #cs - Описание пресета
                        Вижу только кнопку меню, остальные проверки на цвета - дали отрицательный результат,
                        несуществующая для человека ситуация. Рекомендуется подождать и провести проверку снова.
                        Данная ситуация как правило встречается в момент андока когда экран игры плавно затемняется.
                        Далее после нажатия кнопки ABORT он начинает плавно светлеть и в конце этого процесса датчики
                        сбиваются и выдают тот пресет к которому комментарием идет эта строка.
                    #ce - Описание пресета

                Case $LogicState = "Location: Menu Button Col: Found | Undock Button Col: NOT Found | Station Icon Col: NOT Found | Asteroid Name Col: NOT Found | "
                    SetError(3)
                    $Location[0][0] = "Работа невозможна: Я ничего не вижу в овервью"
                    #cs - Описание пресета
                        Ситуация в которой бот видит кнопку игрового меню и не видит ни станцию ни астероиды в овервью мы будем считать нерабочей.
                        Так же такая ситуация можнт возникнуть при прокручивании овервью вниз или вверх. При проверки по одной точке или же горизонтальной
                        линии пикселей рано или поздно наступит такой момент когда при смещении овервью вверх или вниз по нашим координатам чками будет только
                        черный фон овервью. Лечится расширением области проверки на несколько пикселей по высоте.
                    #ce - Описание пресета

                Case $LogicState = "Location: Menu Button Col: Found | Undock Button Col: Found | Station Icon Col: Found | Asteroid Name Col: Found | "
                    SetError(4)
                    $Location[0][0] = "Работа невозможна: Все проверки прошли успешно о_О"
                    #cs - Описание пресета
                        Ситуация когда бот видит кнопку меню, кнопку андока, и данные с овервю одновременно. Ситуация возможна во время доккинга.
                        Нужно подождать и снова запустить проверку.
                    #ce - Описание пресета
                Case Else
                    ClipPut('Case $LogicState = "'&$LogicState&'"')
                    MsgBox(0,"Неописанная ситуация",$LogicState)
                    Sleep(100)
            EndSelect
            Return $Location[0][0]

Датчик стоящий на следующем уровне логики после низкоуровневого, правда в данной версии все низкоуровневые датчики вбиты сюда:

Global $Location[6][7]=[[0,0,0,0,0,0],[61, 22,62, 23,0xCCCCCC,1,"Menu Button Col"],[19,720,19,720,0xFFDE42,20,"Undock Button Col"],[441, 549,500, 560,0xBDBDBD,10,"Warp Message Col"],[770,169,770,180,0xFFFFFF,2,"Station Icon Col"],[868,175,878,175,0xB6B6B6,50,"Asteroid Name Col"]];0 = Undock, 1 = MenuButton, 2 = OverviewStation, 3 = Asteroid

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

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

 

[bugaj]

Ну а чтобы программа сама программировала себя, пока это ближе к фантастике .

Уж если ботить так ботить по полной ;D

 

[Belfigor]

Мы все дружно ждем когда тебя дадут нобеля за такого уровня ИИ

 

[bugaj]

ну в смысле вот например у тебя есть датчик на кнопку дока, есть нет 1 пиксель по цвету
есть датчик например на овервью, есть нет 1 пиксель по цвету
есть датчик на варп, есть нет 1 пиксель по цвету
3 отдельных датчика, но по их данным можно сделать вывод в доке ли ты, в космосе ли ты, в варпе ли ты или ты вообще грузишься со станции в косомс.
Отдельно датчик на варп не скажет тебе 100% точно в варпе ты или нет
Отдельно датчик на кнопку андока так же не скажет тебе 100% точно в доке ты или нет
Отдельно датчик на овервью так же не скажет тебе видишь ли ты овервью или нет

Так ведь есть таблица датчиков в которой например 3 колонки. Наименование, Наличие, значение. Т.е. датчиков можешь сколько хочешь делать. А также есть таблица состояний. В которой есть колонка "Наименование", "Соответствующие датчики", "Функции входа", "Функции выхода".... ну как то так вообщем например. И у тебя в таблице состояний будет состоянию соответствовать комбинация датчиков с уникальными значениями. Так что тут проблеммы то я не вижу. Более того эта схема вроде лучше соответствует, тому что в первом посте написано. :D

Кстати если датчиков хренова туча, и рассматривать ситуацию когда ты не помнишь где ты был, то выходит нужно все датчики опрашивать. Но в случае с таблицами можно идти по дереву состояний и смотреть датчики соотвествующие этим состояниям. Также можно запоминать последнее состояние и начинать искать с него. Чтобы по тыщу раз не опрашивать одинаковые датчики - уже опрошенные запоминать и потом просто смотреть значение. Тогда поиск по идее
будет быстрее. Но как представлю на что будет похожа таблица состояний тогда, что даже хз как к этому всему подступиться. Вообщем профит сомнителен, а трудоемкость высокая :(

 

[mornere]

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

Глава 2. Мульти-боты на одной машине
Возможны 2 принципиально разных варианта:
Запуск на виртуальной машине, что фактически приводит нас в главу 1, повторенную несколько раз или запуск всех ботов под одной операционной системой, на чем и остановимся подробнее.
Итак мульти-бот. Смысл такого бота заключается в том, что скрипт (вариант 1) или несколько скриптов (вариант 2) управляют несколькими клиентами игры, взаимодействуя в среде ОС, как минимум для получения ресурсов машины и фокуса окна в свое пользование.
Вариант 1: скрипт имеет данные о всех запущенных клиентах, хранит или каждый раз по датчикам определяет состояние окна и переключает окна по мере достижения неких стабильных состояний (например в процессе копки, в варпе, на доке/андоке), когда требуется ожидание и не требуется активное вмешательство бота.
Особенности: Единый скрипт для всех ботов, если нужно выполнять разные задачи - обрастает функциями и настройками, зато не имеет внешних генераторов ошибок, в виде файлов на диске или буфера обмена, в который попало что-то лишнее.
Вариант 2: каждый скрипт занят своим окном, обмениваясь информацией с помощью ОС (это может быть общий файл, буфер обмена или еще что-то, насколько хватит воображения) или с помощью скрипта-мастера, который явялется координатором скриптов-"рабов" (master-slave).
Особенности: проще для понимания, особенно при переходе от 1 клиента ко многим, каждый скрипт содержит только нужный набор инструментов, но есть шанс сбоев именно в передаче сигналов скриптами друг другу.
Глава 3. Мульти-боты в сети
Тут все предельно просто и максимально скиллоемко (как в Ив). Боты объеденены через сеть, обмен информацией и сбор статистики производится через сервер, который предоставляет информацию владельцу и дает возможность управлять ботом удаленно (а иначе какой смысл?). Как, по какому протоколу, как часто и много - каждый выбирает сам, ибо дойдя до этого этапа уже не ищут готовых решений.
Особенности: Возможность быть на работе/у друга/ с мобилы в сети и все равно рулить ботнетом (уже получается так). Возможность физически быть далеко от бота, разместив его в подвале/у бабушки/в серверной/на снятой специально квартире рядом с фермой из еще 10 таких компов :laugh:. Возможность неплохо поднять навыки программирования. И, немаловажно, возможность полностью изолировать ботов от "ручных" любимых персонажей, наверняка у 80% этой ветки есть такие. Другой IP, другая машины, ни единого входа с нее вашим любимцем. Так же позволяет практически бесплатным бонусом легко ретранслировать сообщения ботов/из игры в асю, смс и т. д.. Из минусов только риск падения сервера, если он участвует в управлении ботами (и ботам нужны его комманды, для нормального функционирования), решается хранением неких базовых/полученных настроек локально (время отключения, алгоритмы поведения).


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

 

[DJ_Tommy]

Мне кстати очень понравилась идея с выносом в виде отдельной таблицы комбинаций датчиков и реакций. Если буду переписывать своего бота - непременно так и поступлю. ИМХО это очень удобно получится, а главное очень удобно, главное в нужном порядке строки поставить и очень приятно что можно все колонки подписать - потом просто распечатываешь себе и перед глазами готовый select case лежит.