Yoko

Вот берем такой цикл:

Repeat
    Uo.FindType('0x171C','-1','0x40482bf4')
   Wait(4000)
Until UO.FindCount()>199

Вопрос: почему 3 из 5ти раз, этот цикл будет повторяться до бесконечности?

А у тебя в контейнере отдельные айтемы, или кучкующиеся?

Отдельные!

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

_________________
I'm Titanium [Dragon] from Nova UO Shard

Попробуйте так:

Until STR(UO.FindCount())> 199

uo.[yhlp_GetQuantity]('[yhlp_finditem]')

_________________
Сделал дело - флуди смело !!!

Причем тут получить количество айтема? GetQuantity('-1') тока если -)

Кто тебя учил сравнивать строку с числом? Не делай так никада![/quote]

Помоему инжекту пофиг, он всеравно обе части текста переводит в строки, а потом парсер переводит обратно.

Не-а... Не катит такой вариант... Скрипт продолжается...

Не, тоже не сечет фишку... Видать через While надежней будет!

Самоучки мы

Бред все работает...
Скрипт привебеный внизу будет повторятся если итемов будет >= 199

sub BugTest()
   Repeat 
       Uo.FindType(-1,-1,'my') 
         Wait(1000)
         uo.Print(Str(UO.FindCount()))
   Until UO.FindCount()<199 
end sub

И вообще лутше если не доверяешь фукуциям выводи данные которые эти функции должны проверить и сам проврея...
Дальше скрипт написаный тобой зациклится если найденых и томов <= 199
Антил полное противоположность вайлу... он крутит пока функция сравнения дает фальш и проверка условия в конце..

while true и until false

следовательно:

until uo.findcount()<199

равносильно (почти)

while uo.findcount()=>199

Разница между циклами на самом деле есть - while проверяет данные на входе, а until на выходе.

Destruction: Флуд потер, который не по теме, пост исправил, ошибся - не спорю.

Млин... А не может сама инжа глючить!? Через WHILE тоже самое - один раз все нормально, а дальше гонит без остановки! При чем на втором окне, где работал давно проверенный скрипт, тоже начались глюки! Скрипт типа запускается, что то делает, но как только доходит до любого условия, дык либо игнорирует его, либо скрипт останавливается! У меня версия инжи 505.16. А UNTIL мне был бы удобнее!

Да я уже сижу и мышкой тыкаю по мешку, где итемы(куда уж лучше проверка?) - не люблю всевозможное засорение экрана!

Видимо что то действительно глючит... После сбоя скрипта, перезагружаю клиент и все работает! Что бы это могло быть?

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

uo.Print(Str(UO.FindCount()))

2Grin
Попробовал и твой вариант... Когда идут сбои, то выдает 0... Хотя все остальное в скрипте работает!! Инжа видимо спотыкается (после какого то момента) на подсчете итемов в баге, не находящемся в паке... Как же с этим бороться? А главное ни как не могу вычислить момент, с которого инжа сбивается... При тестировании твоего предложения столкнулся с тем, что крысом тычу на баг - показывает 200, а скрипт выдает 0... Через десяток циклов Инжа вдруг обнаружила, что в баге действительно 200 итемов... Как с этим бороться ни фига не понимаю...

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

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