To have 2 nested finditem based loops you have to keep track of your own version of #findindex and #findcnt.
There can be in issue if during the loop an item in the container (the ground can be a 'container' - so maybe it is better to think of it as "search confinement") disappears (is moved out of the 'container').
So it is definitely possible. I only do this when needed, not because it is so much slower (modern CPU and Easyuo 1.5 void the old thinking that 'finditem' is slow).
If you doubt the correctness of my comment on finditem isn't as slow as it is advertised, try it out for yourself. I did a test at a populated bank where I searched among 100 items in game in .005 seconds (5 ms).
finditem %items g_ , %distance
if #findcnt > 0
{
set %ItemsCount #findcnt ; keep the value for the %items #findcnt value
for %ItemsIndex 1 %ItemsCount
{
finditem %items %ItemsIndex g_ , %distance ; This has 4 parameters!
if #findcnt = 0
break ; this means an item was moved while we are processing the whole routine after the outer finditem above!
if #findtype = %doDad
{
finditem %stuff c_ , #backpackid
if #findcnt > 0
{
for #findindex 1 #findcnt
{
exevent drag #findid
exevent dropc %secureBox
wait 15
}
}
}
if #findtype = %thingaMajig
{
exevent drag #findid
exevent dropc #backpackid
wait 15
}
}
}
What has been added above:
1) check #findcnt > 0 after the finditem before doing the for loop, because if #findcnt is 0, then you do a loop when you have no data from values 1 counting down to 0.
2) keep track of the outer loop #FINDCNT
3) use your own variable - like how we would use #findindex...
4) reissue a finditem in the loop where we give 4 parameters which includes the index of the loop we want.
If you have moved out of the area an item in the ground search (or someone else has) then the logic breaks down. I wouldn't do this kind of logic for general population items in my script. Snicker7 did this in the original BodFiller script and that and a conversation with another scripter is how I learned about it. It is the way to keep track of more than 1 finditem in a loop.
There is a way where you could save all the data from the outer finditem loop and then try to process it all again in a second pass. That would allow you to skip over items that have been moved on you. This is only a valid issue if you have a list of 20 things you initially found and an earlier one in the list is moved (not by you) so that the list index changes. The above logic takes care of any future found items in the loop iteration being moved, because it bails if it gets to the end of the list too early.