Здравствуйте, гость ( Вход | Регистрация )

71 страниц V « < 69 70 71  
Ответить в эту темуОткрыть новую тему
> Пожелания, Предложения по развитию сюда
AbsorbeR
сообщение 13.7.2018, 19:50
Сообщение #1401


***

Novice
Сообщений: 51
Регистрация: 22.11.2016
Группа: Пользователи
Наличность: 69
Пользователь №: 18.203



Цитата(Fors1k @ 13.7.2018, 17:49) *

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

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


--------------------
Выполняю скрипты на заказ.
e-mail: [email protected]
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 13.7.2018, 20:37
Сообщение #1402


***********

Модератор UOPilot
Сообщений: 7.690
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 24168
Пользователь №: 11.279



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

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

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

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

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

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


--------------------
Скрипты под заказ.
Консультации по UOpilot через ICQ, Skype, Ventrilo, TeamSpeak, TeamViewer 500р/час.
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 13.7.2018, 23:06
Сообщение #1403


***********

Модератор UOPilot
Сообщений: 7.690
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 24168
Пользователь №: 11.279



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

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

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


--------------------
Скрипты под заказ.
Консультации по UOpilot через ICQ, Skype, Ventrilo, TeamSpeak, TeamViewer 500р/час.
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Fors1k
сообщение 14.7.2018, 1:56
Сообщение #1404


**

Neophyte
Сообщений: 36
Регистрация: 19.12.2017
Группа: Пользователи
Наличность: 44
Пользователь №: 18.746
Возраст: 26



Цитата(DarkMaster @ 13.7.2018, 23:06) *

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

Ну если %, это-то само собой.
Суть в том, что если убрать ОК и 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
.......

Уже не прокатит.
Странно же было бы?)
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Cockney
сообщение 14.7.2018, 12:17
Сообщение #1405


*******

Adept
Сообщений: 1.018
Регистрация: 22.6.2013
Группа: Пользователи
Наличность: 10280
Пользователь №: 16.156



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

В случае с findcolor : если он возвращает отрицательные числа, то ошибка, иначе все норм. А если брать мат. операцию, например -4 - 16.7, то как понять что что-то пошло не так ? Ответ выше.
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 14.7.2018, 12:17
Сообщение #1406


***********

Модератор UOPilot
Сообщений: 7.690
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 24168
Пользователь №: 11.279



Цитата
Суть в том, что если убрать ОК и 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


--------------------
Скрипты под заказ.
Консультации по UOpilot через ICQ, Skype, Ventrilo, TeamSpeak, TeamViewer 500р/час.
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 10.8.2018, 14:34
Сообщение #1407


*

Registred
Сообщений: 2
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 1
Пользователь №: 19.007



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


***********

Модератор UOPilot
Сообщений: 7.690
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 24168
Пользователь №: 11.279



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

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


--------------------
Скрипты под заказ.
Консультации по UOpilot через ICQ, Skype, Ventrilo, TeamSpeak, TeamViewer 500р/час.
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
sutra
сообщение 11.8.2018, 4:10
Сообщение #1409


*

Registred
Сообщений: 2
Регистрация: 10.8.2018
Группа: Пользователи
Наличность: 1
Пользователь №: 19.007



Я понял, спасибо. Но всё-таки ... Я понимаю, что Вы хотите сделать как лучше и хотите в конечном итоге сделать функционально, всеобъемлюще, просто и понятно. Но всеобъемлюще сделать действительно непросто, да и при таком подходе мы все рано или поздно окончательно отупеем, оставьте нам возможность соображать и выбирать варианты и хоть что-то ещё делать самим. Кстати, именно при помощи этого замечательного кликера, сначала были написаны скрипты, которые подробно собрали нужную статистическую информацию, на основе которой был уже реализован основной скрипт, да ещё и с возможностью самообучения, все ошибки фиксировались и автоматически ужесточались параметры (время - цвет). Вот только анализ всего этого тоже отбирает время, что крайне напрягает, когда на всё про всё в реал-тайм даётся 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 , то ... только фантазия пользователя.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение 11.8.2018, 20:43
Сообщение #1410


***********

Модератор UOPilot
Сообщений: 7.690
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 24168
Пользователь №: 11.279



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

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


--------------------
Скрипты под заказ.
Консультации по UOpilot через ICQ, Skype, Ventrilo, TeamSpeak, TeamViewer 500р/час.
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
DarkMaster
сообщение Вчера, 20:15
Сообщение #1411


***********

Модератор UOPilot
Сообщений: 7.690
Регистрация: 2.12.2008
Группа: Супермодераторы
Наличность: 24168
Пользователь №: 11.279



Предисловие.
В луа есть фишка, что оператор ".." достаточно тормозной, т.к. после вызова приводит к путешествию строки по стеку, чтобы стек был упорядочен по длине строк. Для того чтобы избежать подобных проблем с многочисленными вызовами ненужной оптимизации, когда собирается строка типа:
Код
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 - Вчера, 20:17


--------------------
Скрипты под заказ.
Консультации по UOpilot через ICQ, Skype, Ventrilo, TeamSpeak, TeamViewer 500р/час.
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
WKnight
сообщение Вчера, 23:41
Сообщение #1412


********

Разработчик UO Pilot'а
Сообщений: 1.539
Регистрация: 9.1.2006
Группа: Модераторы
Наличность: 7076
Пользователь №: 4.688



Цитата
размер сообщения выводимого в лог достаточно сильно ограничен
А как сильно он ограничен фактически?
Пользователь в онлайне!Delete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения

71 страниц V « < 69 70 71
Ответить в эту темуОткрыть новую тему
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 

- Текстовая версия | Версия для КПК Сейчас: 18.8.2018, 0:31
Designed by Nickostyle