ScriptUO
Official ScriptUO EasyUO Scripts => Scripting Chat => Topic started by: Cerveza on February 22, 2010, 05:45:04 AM
-
Just a short quip about something I discovered. You real scripters probably already know about it, so this is for the nubs.
When you are cycling through items you normally use a standard flow:
finditem
do whatever to item
ignore item
I was using that flow for Detecting Hidden on boxes. If I had 20 boxes on the ground, the script would find one, detect on it, ignore it, the find the next one. Once all were detected I did a ignoreitem reset to clear the ignore list and start over again.
The problem is how I had my ignoreitem. It was before the Detect portion, so if I had a count of 0 items (and reset the ignoreitem list) it would still try to detect the "unfound" item, which results in a #findType and #findID of X.
findItem %boxes G_6 ; find all boxes within 6 that are on the ground
if #findCnt = 0
ignoreitem reset ; if it doesn't find one, because I've ignored them all, then reset the ignore list
detect hidden ; detect on the found ones
ignoreitem #findID ; ignore the one I just detected
See how when I ignore the last box, the script will #findCnt 0 and reset the ignore list THEN it will try to detect hidden, but the item is that X because the count was 0.
This is how I got around it.
findItem %boxes G_6
set %findCnt #findCnt ; so I'm setting a variable to keep track of how many are found
detect hidden ; detect on the found one
ignoreitem #findID ; ignore the one I just detected
if %findCnt = 1 ; so the last one I detected on was the LAST ONE FOUND
ignoreitem reset ; since I just checked the last one found, reset the ignore list
This works well. Scripts that cycle through stuff and ignores items should have some type of safety like this to ensure you don't waste one cycle trying to do something to an item thats not found.
-
-Ive found it best never to use the ignore item command at all.
- Its also good practive to use as little finditems as possible as they are very cpu intensive and are one of the causes of crashes when multiscripts are running.
So my solution is issue finditem command once... load all the results into my own array.. then itterate through that array doing what ever i needed to do. To reset just set the counter back to 1
Ie for your detect example
Finditem <boxes> G_5
set %MYArrayCount #findcnt
IF #findcnt > 0
{
For #findindex 1 #findcnt
{
set %MyarrayFindid . #findindex #findid
; save other findstuff you want
}
}
If %MYArrayCount > 0
{
Repeat
For %Count 1 %MyArrayCount
{
gosub PerformDetectHiddenActionon %MyArrayFindid . %Count
}
Until %ExitScript
}
Halt
The above also presumes that you are doing other finds thus invalidating the finditem array... if your not doing other finds you can make it even simpler
Finditem <boxes> G_5
IF #findcnt > 0
{
Repeat
For #findindex 1 #findcnt
{
gosub PerformDetectHiddenActionon #Findid
}
Until %ExitScript
}
(If someone comes along and picks up your boxes you might get an error.. but can compensate for that in the action sub)
-
I suppose a #findCnt then "for/next" would work as well. The problem is, as you stated, sometimes they move.
If you #findCnt and find 6 crates, then begin detecting on them, the full cycle will take ~60 seconds. In that time one, or more of the crates may have been removed. So a #findCnt has to be done each cycle.
By using the variable %findCnt I can ensure that when there's only 1 (or 0) left the ignored list will be reset and the cycle started over.
I wish I could reduce the amount of #findItem, but in the case of the Detect script I can not.
-
Something I've also Noticed........
Finditem %Whatever
Ignoreitem #findid
Ignoreitem #findid
finditem %whatever
when you do the same ignoreitem Twice, they seem to cancel each other out..... This gets very frustrating when you try to add certain circumstances for ignoring things, and then just a universal ignore. So, if you are having issues with ignoreitem Not actually ignore something, pay attention to how many times you ignore that object.
-
So it's like a double negative? LOL
findItem MySenses
ignoreItem MySenses ; ok, your senses won't be detected and are ignored
ignoreItem MySenses ; ok, ignore the fact that your suppose to ignore my senses...
move to MySenses ; please, bring me to my senses
-
Exactly!!!!
-
I suppose a #findCnt then "for/next" would work as well. The problem is, as you stated, sometimes they move.
If you #findCnt and find 6 crates, then begin detecting on them, the full cycle will take ~60 seconds. In that time one, or more of the crates may have been removed. So a #findCnt has to be done each cycle.
By using the variable %findCnt I can ensure that when there's only 1 (or 0) left the ignored list will be reset and the cycle started over.
I wish I could reduce the amount of #findItem, but in the case of the Detect script I can not.
In the case of Detect Hidden you really don't want/need to ignoreitem anyhow. Once a trunk spawns you want to detect on it until it's gone then find another.
Not to deter from this excellent discussion on the use of these functions though, just wanted to mention that.
X
-
Depending on if you're in a location that spawns with the right type of chest for your skill level... :) If chests are spawning probly a good idea to scan them all and detect each one so you gain off of the ones that are the higher level and lower level... variety speeds up gains imho.
-
I disagree 12X... ;)
I think cycling through the chests improves your chances for gains. There must be varying levels of chests, so using the same one might not be optimal for gains. If it's at a level that your not going to gain on, would you want to just detect on it?
I say NAY! Lets check them all so that if 50% of them are "gainable" at least we have the opportunity to gain!
-
I disagree 12X... ;)
I think cycling through the chests improves your chances for gains. There must be varying levels of chests, so using the same one might not be optimal for gains. If it's at a level that your not going to gain on, would you want to just detect on it?
I say NAY! Lets check them all so that if 50% of them are "gainable" at least we have the opportunity to gain!
We should have a "Detect-off" to test each of our logics. Start new char with 50 Detect, I fire up mine and you fire up yours in the same room at Vesper bank. Hit play and see who's right ;) I'm confident you will gain faster by not ignoring targets after a single attempt. I agree that there is a risk of getting "stuck" on a trunk at a level too low to gain from any longer thus wasting a bit of time but the trunk refresh rate is slow enough that I know for a fact you'll waste a lot more time waiting for new trunks to spawn after only one attempt each.
Let's do this!! :D
Now what would be cool is if there was a correlation between container type and the difficulty but unfortunately three different small wooden boxes could be three totally different skill levels.
X
-
I know I would win this event. No doubt. More targets = More chances to gain.
It doesn't take any longer to change targets, yet even as you stated "there is a risk of getting "stuck" on a trunk".
I know for a fact you'll waste a lot more time waiting for new trunks to spawn after only one attempt each.
Wrong! I don't wait for new boxes!!
Remember, my method doesn't wait for new ones to appear. It cycles through whats there, ignoring each one it detects, until it detects the last one it finds, then it clears the ignore list and begins the cycle again.
-
Aka, For #findindex 1 #findcnt
But with a refresh Rate :)
-
I know I would win this event. No doubt. More targets = More chances to gain.
It doesn't take any longer to change targets, yet even as you stated "there is a risk of getting "stuck" on a trunk".
I know for a fact you'll waste a lot more time waiting for new trunks to spawn after only one attempt each.
Wrong! I don't wait for new boxes!!
Remember, my method doesn't wait for new ones to appear. It cycles through whats there, ignoring each one it detects, until it detects the last one it finds, then it clears the ignore list and begins the cycle again.
Ahhh I misunderstood. Ok, now I can agree with you that this would be faster :P Strike all that and let's return to the regularly scheduled program, already in progress...
X