Как перезаписать последний труп ?

[Juicy Fruit]

Шо за Ад?)

это не ад, это кривописание )))
насколько велика разница и есть ли смысл переписывать, вот что интересно если там разница в 30 мс на весь скрипт, то и смысла не вижу. На лут 50+- итемов

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

[kobol]

Нет. Если у него 45 шлака + 5 нужных, то искать по типу будет только 5 раз.

Ты внимателнее читай, у тебя массив на 50 нужных тебе предметов, в трупе из этих 50 будет всего 5 но искать тебе нужно всё те же 50. Если массив на 5 то и искать будет 5 это понятно но говорили мы не об этом если что а о том почему плохо использовать поиск по массиву.

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

Ну и я о том же ). Если массив нужных предметов 50, а в трупе всего 5, то конечно он будет искать 50 раз, если искать по массиву, и 5 раз если искать все.
Плохо искать по массиву, когда он большой. А когда он маленький, то искать хорошо )
А вообще, кто-нибудь сравнивал скорость поиска с работой например функции instr?
Или скорость сравнения типов перебором массива со скоростью той же instr?
Хотя задержка 600 после каждого moveitem делает все это неактуальным.

[Incorrect User]

Написали же, FindList есть, это все что тебе нужно, какие массивы, какой instr, забудь про это

[kobol]

Написали же, FindList есть, это все что тебе нужно, какие массивы, какой instr, забудь про это

У меня теоретический интерес

[kobol]

Ну смотри, 50 итемов нужно найти, в случае неудачи задержку на файндтайп ставим 100, просто задержка в пустом цикле. 100х50 = 5сек крутится твой скрипт даже если инчего в трупе нет. Если же использовать FindList например в том же пустом контейнере то результат ты получишь сразу а не через 5 сек. А так же например в списке есть итем например он десятый, то скрипт сразу же на него среагирует а не будет крутить 9 проверок типов которые идут до него. В этом же и суть лута, полутать все максимально быстро пока не полутали до тебя)

Кстати задержку в пустых циклах можно ставит 1, wait (1). Виндузе этого достаточно, чтобы впихивать свои сообщения.
А как вообще в инже (внутри инжи) организован поиск предметов? Ведь все равно используются существующие команды UO, которые передаются на сервер, а затем обрабатываются ответы сервера?

[Incorrect User]

Дело не в том достаточно виндоусу 1 или нет, дело в том что инжект при задержке меньше 100 в пустов цикле имеет вероятность упасть И чем значение ниже тем выше шанс краша.

[Juicy Fruit]

А как вообще в инже (внутри инжи) организован поиск предметов? Ведь все равно используются существующие команды UO, которые передаются на сервер, а затем обрабатываются ответы сервера?

Все что приходит от сервера - фиксируется инжектом и сохраняется у него в памяти (в данном случае объекты).
При вызове uo.FindType и подобных - поиск ведется по сохраненным в памяти инжекта объектам, при поиске на сервер ничего не отсылается.

[kobol]

А как вообще в инже (внутри инжи) организован поиск предметов? Ведь все равно используются существующие команды UO, которые передаются на сервер, а затем обрабатываются ответы сервера?

Все что приходит от сервера - фиксируется инжектом и сохраняется у него в памяти (в данном случае объекты).
При вызове uo.FindType и подобных - поиск ведется по сохраненным в памяти инжекта объектам, при поиске на сервер ничего не отсылается.

Так это очень быстро должно быть!
Только эта.. Ведь коники-то скочут все время туда-сюда. Как часто происходит обновление данных об объектах ? При любом изменении количества объектов в пределах видимости сервер отсылает информацию клиенту автоматом?
Не, это и так понятно, что информация на клиенте всегда актуальная, иначе бы играть было невозможно.

А кнопка TWI тут как-то задействована?

Скорость исполнения цикла в скрипте и цикла внутри инжи сильно отличаются? Вроде говорили что не сильно. Хотя..)

[Juicy Fruit]

Обновление дисплея вроде бы только когда требуется.
Если только зашел в мир/прилетел на точку/вошел в портал/ресенд - сервер шлет инфу о все в зоне видимости.
Если уже всё обновлено - только о обновленном объекте (перешел на тайл, кастанул что-то и т.п.)

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

[kobol]

Понятно. По скорости получается сопоставимо, тем более задержка после moveitem всю разницу съедает.
В общем чтобы надуть конкурента по луту, надо дропнуть в труп 10-20 кучек по 6 гп. Пусть их подбирает )))

[Incorrect User]

более задержка после moveitem всю разницу съедает.

Ну, задержка после мув итем есть только тогда когда что-то нашел иначе задержка только 100

[Juicy Fruit]

Понятно. По скорости получается сопоставимо, тем более задержка после moveitem всю разницу съедает.
В общем чтобы надуть конкурента по луту, надо дропнуть в труп 10-20 кучек по 6 гп. Пусть их подбирает )))

Каким образом?) Если задержки на лут нет - лути с 50 задержкой Если есть теряешь время на дроп гп вместо лута нужного)

[kobol]

более задержка после moveitem всю разницу съедает.

Ну, задержка после мув итем есть только тогда когда что-то нашел иначе задержка только 100

Тогда получится все по- честному. Первый нашел -тянет, пока он тянет - второй нашел. Даниель-Леман, Даниель - Леман. )))

[kobol]

Понятно. По скорости получается сопоставимо, тем более задержка после moveitem всю разницу съедает.
В общем чтобы надуть конкурента по луту, надо дропнуть в труп 10-20 кучек по 6 гп. Пусть их подбирает )))

Каким образом?) Если задержки на лут нет - лути с 50 задержкой Если есть теряешь время на дроп гп вместо лута нужного)

На DRW задержка есть. И на drop тоже 600, поэтому не получится так обмануть)

[Mirage]

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

Code: Select all

UO.FindCount('finditem')

Шо за Ад?) У нее нет параметров)
И uo.FindType()/uo.FindList() теперь возвращают серийник, можешь сделать while uo.FindType(...)

ЭЭэ

Когда писали так надо было Просто если я щаз свой лут полностью обновлю на актуальную версию инжекта он не будет у многих работать ИМХО Хотя из вредности надо попробовать
Сам поиск типа занимает доли секунды. Другое дело что работает именно серверная пауза на перемещение. ТАк что найти можно сразу все а вот двигать только что нужно в первую очередь.
У меня в старом луте несколько сотен предметов. Он каждый раз начиная с 0001 0002 двигается до скажем 0004 лутит его потом опять с 0001 0002... Лут 10 предметов из сумки с 255 предметами занимает 10*300+ - 10 мсек
Скан вокруг чара зверьков с растоянием 20 тайлов работает на полсекунды дольше