Пожелания, Предложения по развитию сюда Опции

[AbsorbeR]

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

Оно так и бывает зачастую. Не узнаешь грабли, пока до них не доберешься. (IMG:style_emoticons/default/laugh.gif) Много граблей, в частности, которые не имеют описания в Вики. Вон, например, в теме о findimage мне писали, что все команды работают от exe пилота, а потом оказалось, что dirCreate с багом. Напрягает такое.

[DarkMaster]

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

Фишка в том, что луа учится предельно быстро. Всмысле совсем предельно. Если не задаваться вопросоми тонкостей и экстрима, то за 1 день начнете писать на нем ровно в том же объеме. Для скорости написания и использованию хелпов больше проблема со знанием операторов и особенностей пилота/приложений. Все операторы пилота остаются с вами. В общих чертах разница в том, что теперь всегда нужно ставить скобочки в функциях ну и... вместо for end_for будет for do end вместо while end_while будет while do end. Это не те изменения, которые не дадут писать скрипты.

В моем скрипте все условия запускаются именно при нахождении цвета..

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

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

А зачем убирать то? Что мешает просто использовать только один элемент массива?

[DarkMaster]

В плане сделать ее результатом, при задаче set %a math.dbl (2,2 + 6,3)
...
По итогу не нужно будет обязательно делать обычное умножение через массив, а дальше уже вытаскивать из него первую строку..
log %a [1]

А вот это кстати невозможно ибо % - признак массива и обращаться можно только по индексу и никак иначе. Даже если там будет только один элемент.
Использовать числовую переменную, как этого требует логика, невозможно, т.к. это целочисленные переменные и использование символов точки/запятой не допускается. Т.е. альтернатива только одна - сохранять результат математической операции только в строковую переменную. Это изврат уже дикий - пусть уж лучше лежит в массиве.

// arr[1] - это не дергать первую строчку, а обращение по индексу, что ну совсем уж никак не страшное действо - это нормально, хотя в данном случае и используется костыль из-за невозможности использовать числовую переменную.

[Fors1k]

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

Ну если %, это-то само собой.
Суть в том, что если убрать ОК и Success из ответа, то тогда можно использовать не %, а $ или #.
Меня просто обуяло любопытство, зачем нужны это строки ( ОК и Success ) ?=)
Это как представить, что результатом
set #a findcolor (530 145 553 270 1 1 (16711680 ) workwindow -1 17)
log #a
было бы:

Код

2979
OK
Success
Color is finded
Vse srabotalo
Yra
ochen' kryto=))

Если так было бы, то тогда это:

Код

if #a > 0
.......

Уже не прокатит.
Странно же было бы?)

[Cockney]

Ok или(и) Success флажок. Устанавливается, если результат операции верен. Если бы это было не так, и не было бы флажков(как вы предлагаете их убрать), то как можно узнать правильность операции ? Вернется число, но верное ли оно ?

В случае с findcolor : если он возвращает отрицательные числа, то ошибка, иначе все норм. А если брать мат. операцию, например -4 - 16.7, то как понять что что-то пошло не так ? Ответ выше.

[DarkMaster]

Суть в том, что если убрать ОК и Success из ответа, то тогда можно использовать не %, а $ или #.

# - нельзя. Я уже написал почему. Это целочисленная переменная которая просто не может содержать в себе значение double. Оно даже по байтам не влезет.

Меня просто обуяло любопытство, зачем нужны это строки ( ОК и Success ) ?=)

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

Это как представить, что результатом
set #a findcolor

Очень плохой пример =) Финды в этом плане костыль еще похлеще. Что по факту мы имеем результат возвращающийся в два объекта (не в смысле ооп): в переменную и в массив. Причем переменная, как раз таки и содержит ошибки, точнее коды ошибок, которые потом нужно расшифровывать. Но эта же перемення можно содержать количество найденных изображений или если изображение одно, то его точность. По факту мы не можем определить, что реально содержится в данной переменной точность или количество не проверив размер массива. Сейчас произошли определенные положительные изменения, в частности можно узнать точность нахождения каждого изображения (содержится в массиве), тем не менее зоопарк еще тот. Это еще одна из причин, почему я предпочел бы переход на луа. В рамках луа это все делается просто и красиво:
local arr, error, error_text = find***
В итоге нам нужен только arr, если не происходит каких-то катастроф. Мы можем очень легко найти его размер без нагромождения вызовов size():
#arr - это размер.
Более того, WKnight, внимание! - arr, если мы ничего не нашли, должен быть не просто пустым, он должен быть nil, в отличии от того, как сейчас реализовано. При таком подходе нам в коде вообще перестают быть нужны вытаскивания размеров, если нас интересует непосредственно успешность поиска. Вместо пилотовских нагромождений из разных переменных и массивов:
if #a > 0
и
if size(%arr) > 5
set #sz size(%arr)
for #i 1 #sz 1
становится доступен нативный синтаксис:
if arr then -- then всегда пишется после условия. типа скобочки.
и
if #arr > 5 then
и
for i = 1, #arr do -- do точно так же типа скобочки
При этом error и error_text можно вообще не использовать даже при вызове финдов. Lua позволяет их просто опустить. Имея полный синтаксис:
arr, error, error_text = find***
следующая запись будет полностью корректной:
arr = find***

Сообщение отредактировал DarkMaster - 14.7.2018, 12:20

[sutra]

Замечательная программулина, спасибо разрабу! Почти всё устраивает, но пару моментов озвучу. Хорошую вещь сделали, когда добавили GetImage. Вот только почему эту фишку не использует также и FindColor. При необходимости анализа и контроля нескольких объектов тормоза иногда становятся критическими (у меня на каждый вызов Файнда используется почти 0,03 сек.) В большинстве критичных ко времени случаев просто получаю все пиксели (вызов с параметром типа R(0-255)) и потом "ручками" ковыряюсь с ними. И ещё по Файнду, было бы просто замечательно, если бы и ещё была возможность искать разницу по цвету, например Red - Green более 20 (для игр, где есть смена суток - это был бы подарок), а пока приходится городить огород, что тоже кушает ресурсы. Ну а если бы ещё и сделать проверку на нажатие клавиш, чтобы по ходу выполнения скрипта можно было бы им управлять, было бы просто супер, а пока приходится внешними примочками пользоваться. Извиняюсь за свою жадность. Всё равно кликер - супер.

[DarkMaster]

Red - Green более 20 (для игр, где есть смена суток - это был бы подарок)

Это старая история =) Я изначально предлагал deviation использовать в первую очередь для относительного смещения тона, т.е. цвет 100/100/100 и 200/200/201 при заданной погрешности 1% были бы идентичны. Именно для смены дня/ночи, теней и прочего, однако очевидно, что при такой реализации необходима абсолютная отсечка(то, как сейчас работает deviation). Получилось недопонимание и была реализована только абсолютная отсечка (хотя по правде говоря львиную долю выполняет, а относительный вариант гораздо более сложный). Данная тема поднимается с моей стороны регулярно, будем надеется у кнайта руки дойдут.

[sutra]

Я понял, спасибо. Но всё-таки ... Я понимаю, что Вы хотите сделать как лучше и хотите в конечном итоге сделать функционально, всеобъемлюще, просто и понятно. Но всеобъемлюще сделать действительно непросто, да и при таком подходе мы все рано или поздно окончательно отупеем, оставьте нам возможность соображать и выбирать варианты и хоть что-то ещё делать самим. Кстати, именно при помощи этого замечательного кликера, сначала были написаны скрипты, которые подробно собрали нужную статистическую информацию, на основе которой был уже реализован основной скрипт, да ещё и с возможностью самообучения, все ошибки фиксировались и автоматически ужесточались параметры (время - цвет). Вот только анализ всего этого тоже отбирает время, что крайне напрягает, когда на всё про всё в реал-тайм даётся 0,1 секунды. Всё-таки это не компилятор. Нужно просто реализовать эту возможность при вызове FindColor, с параметром типа (R-B(30)). Чтобы не городить конструкции типа set #tmp findcolor (#x1 638 #x2 639 1 1 (R(0-255)) %enr) и потом ещё раз не анализировать координаты и цвет пикселей конструкциями типа set #ts %enr[#i 3] ... set #RB #RB + colorToBlue(#ts) и т.п. Именно вопросы быстродействия тут являются решающими, когда нет времени на выполнение циклов и IF-ов. Именно по этой причине нужен также поиск пикселей в памяти, как это реализовано при поиске картинок, чтобы поставленная задача решалась одним вызовом таких "медленных" функций, как FindColor. Deviation я пристроить так и не смог, он просто расширяет границы поиска и не более того, что опять же легко заменить конструкцией хоть такого типа: set #s findcolor (508 248 535 248 1 1 (R(180-255)+G(0-160), R(160-255)+G(0-140), R(140-255)+G(0-120), R(120-255)+G(0-100), R(100-255)+G(0-80), R(80-255)+G(0-60)) %s 2 1) ... Разница в скорости обработки мизерная и не идёт ни в какое сравнение с повторным вызовом Find. Анализ пикселей и картинок - это главная фишка кликера и если будет качественная реализация - это даст колоссальные возможности его применения. И повторюсь, если будет реализована "горячая" клавиша для вызова скажем оператора Promt , то ... только фантазия пользователя.

[DarkMaster]

Эта тема поднималась неоднократно. Будем надеется ваше сообщение поспособствует реализации.

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

[DarkMaster]

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

Код

local str = ""
for i = 1, 1000 do
    str = str .. i
end
log(str)

рекомендуют поместить все строки в элементы массива и потом вывести через:

Код

table.concat(arr)

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

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

Код

--lua
log("mode compact")

t = os.clock()
for j = 1, 1000 do
    local a={}
    for i = 1, 80 do
        log(i)
    end
end
log(os.clock() - t)

Код 2 - буферизованный вывод:

Код

--lua
log("mode compact")
t = os.clock()
for j = 1, 1000 do
    local a={}
    for i = 1, 80 do
        a[#a + 1] = i .. "\n"
    end
    log(table.concat(a))
end
log(os.clock() - t)

Результаты:
Обычный / Буфферизованный выод
лог закрыт: 50.259 / 2.455
лог свернут: 121.858 / 3.389
лог показан: 165.289 / 4.676
Разница соответственно в 20, 36 и 35 раз. Прирост производительности гигантский.
Пользоваться и радоваться? А вот не получается.

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

Сообщение отредактировал DarkMaster - 17.8.2018, 20:17

[WKnight]

размер сообщения выводимого в лог достаточно сильно ограничен

А как сильно он ограничен фактически?

[DarkMaster]

247 символов с переносами.


Еще один момент.
a = {}

for i = 1, 20 do
a[i]= i
end
log(tostring(table.concat(a)))
Даже после конвертации в стринг пилот пытается воспринимать значение, как число и выводить соответственно. Слишком большие значения просто не выводятся.

[AbsorbeR]

Я придумал, как сократить команды нажатия кнопки мыши.
Нужно заменить [+x +y [-x -y]] на rand(#num) или просто #spread

Например #spread = 5, тогда мы имеем возможны разброс для каждой координаты в пределах от -5 до 5. Причём, работают они независимо, т.е. мы можем получить: -4 0, 3 -2, 0 5 и т.д.

[DarkMaster]

Например #spread = 5, тогда мы имеем возможны разброс для каждой координаты в пределах от -5 до 5. Причём, работают они независимо, т.е. мы можем получить: -4 0, 3 -2, 0 5 и т.д.

1) Что будет со старыми скриптами?
2) Каким образом мне сделать по этому синтаксису клик в область от 1 1 до 2 2?
3) Имхо там нужно задавать просто пару координат, как в финдах. Сейчас вместо пары кликов снимаешь все те же углы, ставишь клик от верхнего левого, открываешь калькулятор и считаешь смещения.

[cirus]

Я придумал, как сократить команды нажатия кнопки мыши.

Ни что не мешает написать свою процедуру/функцию.

[sutra]

Нашёл маленький косячок, старый стал, плохо соображаю, пришлось убить пару минут времени, пока сообразил что к чему.
Сравнение с "двойными" массивами не прокатывает, например:
if %con[2 %cfg[2 #sutki]] = %con[2 1]
Приходится делать так:
set #yCurrent %con[2 %cfg[2 #sutki]]
if #yCurrent = %con[2 1]

[WKnight]

Указание индексов массивов элементами массивов обычно не поддерживается. Теоретически, где-то может работать.

[DarkMaster]

Указание индексов массивов элементами массивов обычно не поддерживается. Теоретически, где-то может работать.

В луа работает (IMG:style_emoticons/default/tongue.gif)

[WKnight]

Имелись ввиду скрипты пилота (IMG:style_emoticons/default/smile.gif)