Recent Posts

Pages: [1] 2 3 ... 10
I use the 'for #findindex 1 #findcnt' all the time, but it doesn't work in the example I showed above, because #findcnt gets reset with each 'finditem' statement (when looking for the tools), and I had to keep track of how far through the list I was.

The ignoreitem method doesn't work when trying to see if I have enough tinker tools to craft more tinker tools to fill the bod; additionally this won't work when the item stacks.

Also when you issue the 'finditem TYPE Index location' method, #findcnt returns 1 each time because you said you wanted to search for only 1. (I expected it to give me back the same #FindCnt value as if I had looked for the whole list, but that was incorrect.)

So using a number value for the Index into the list behaves very differently from the other methods.

In another thread here, TrailMyx states that everyone gets the items back in the same order (suppose you stand in range of the same NPC's with me, we both get the same order of NPC's). I haven't tried to prove or disprove that, but take his word for it. It makes sense because the Index parameter allows subsequent execution of the 'finditem TYPE LOCATION' to actually iterate through the list. If this return was variable on each call, then the Index parameter would not really work.

Interesting nuances in the language that we can take advantage of in scripts...
everything without any filtering in your container/ground search

this is basically it. * isn't really a parameter, it's just a modifier for finditem when you don't want to define what you're searching for, but do want to define where you are searching,

Code: [Select]
finditem c_ , #backpackidfinditem assumes that is parameter 1 i.e. what to search for, and it will find your backpack on your paperdoll #findcnt = 1 #bagid = #charid

using the * mods finditem so that the first parameter in the call is where to search.

so for your example, you could have done something like:
Code: [Select]
;run this with an "empty" backpack... no bods, no extra stuff
finditem * c_ , #backpackid
for #findindex 1 #findcnt
   ignoreitem #findid
or made a list and added an if_not check in your finditem_check_for_craft
these are not necessarily better options... just other options, but in that last example finditem would return everything that is in your backpack.

as to your other point about keeping track of %sbodindex/cnt. I usually index at mnimum #findid as well, and just put everything in a big for loop, that way I don't have to finditem again every time I want to open a BOD.

Code: [Select]
for #findindex 1 #findcnt ​
  ​set %sbodid . #findindex #findid
set  %sbodcnt #findcnt
;then you just use your counter or a for() to set the id every cycle
if %sbod_index > %sbod_count
   set %current_sbod %sbodid . %sbod_index

what's the command for that EUO code output?

added: I'm actually working on a finditem sub for storing multiple finditem arrays with chosen #findresults to parse against, but all of a sudden it's started "eating" one of my passed values in the middle of the sub and I can't figure out why, yet.

edit. just wanted to add about my previous post. I sort of knew how * worked, but I've never tried to describe it before, and on top of that I haven't touched a script or talked to anyone abut scripting for about 3 years. out of practice, and a bit out of touch lol. sorry if I confused you or seemed like an idiot before.
from EUO wiki:
If * is used instead of an id or an index, all items of all types will be returned.

I really don't know. In my experience,
Code: [Select]
returns everything everywhere.

Code: [Select]
finditem *does as well.

I was just trying to read the script and see what it does. That extra parameter threw me, because I have only used that parameter location for a index into the FIND* array. Since the index parm is optional when you want all, I never included it.

Suppose you need to process more than 1 FINDITEM list in the same part of the script, using that INDEX parameter allows you to keep track of which one in the individual lists you have and increment through those.

I spent the summer with my head in the BOD system. So the script will issue the 'finditem' to get the SBOD, then determine how many to make. While crafting it checks does it have a tool to craft with, which requires a new finditem which refreshes the FIND* variables. I do not have to go back and re-sift through my SBODs to find the next one if I keep track of what index it was in the list, I can just increment my index and get the next SBOD. This is a useful tool when hiding (ignoreitem) all the items is not easy. Take the case where you are filling a Tinker's Tool SBod. The item is crafted with a tinker tool - so you can't ignore it and check for how many you have each time, without resetting the ignored items. I can leave these findable and use my own index on the finditem to keep searching for the next SBOD.

Here is a simplified example to show some of that kind of logic and how it is useful. We always look for the next EYM (BOD) by the index we keep (%sbod_index) until it exceeds the count (%sbod_count).

Code: easyuo
  1. finditem EYM C_ , #backpackid ; finditem to determine how many bods we have in total
  2. set %sbod_index 1
  3. set %sbod_count #findcnt
  5. while #true
  6.  {
  7.  finditem EYM %sbod_index C_ , #backpackid ; finditem for the individual bod
  8.  ; logic here to determine how many need to be made
  9.  repeat
  10.   finditem %toolid C_ , #backpackid ; finditem for the tool to use, resets the #find vars from the sbod...
  11.   if #findcnt = 0
  12.    {
  13.    finditem %tooltype C_ , #backpackid ; finditem to see if we have enough tools to use a different one or need to make a new 1
  14.    if #findcnt < 2
  15.     gosub craft_a_new_tool
  16.    set %toolid #findid
  17.    }
  18.   set #lobjectid %toolid
  19.   event macro 17
  20.   gosub ClickCraftIt
  21.   finditem %item2craft C_ , #backpackid ; finditem to test did we successfully make 1
  22.   set %craft_count #findcnt
  23.  until %craft_count >= %bod_count
  24.  gosub FillTheSBod
  25.  set %sbod_index %sbod_index + 1 ; increase the index to the find at the start of this loop will find the next one
  26.  if %sbod_index > %sbod_count
  27.   break
  28.  }

From reading the wiki doc that you quoted, it seems like including * for the index would give you everything without any filtering in your container/ground search and possibly ignore the filter of the item type. When a script keeps track of the index and count, then controls the index value, we have an efficient but rarely used feature of searching different lists at the same time.

(The 'A' parameter is about hidden items, like something you just dropped into a closed container - which is different.)

Anyway, I asked initially because I was hoping to learn something...
lol. I was hoping that wouldn't happen. now I need to write like 3 separate parts to test thing individually. I just wrote that up real fast last night hoping that wouldn't happen, but you know... Murphy's law never seems to fail haha.

well, thank you for taking the time.
Almost immediately
thanks for testing it. I might refine the output so I can figure out exactly where it failed, that output wasn't very precise.

did it fail immediately or after a little bit?
It failed :(

Scripting Chat / Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Last post by lydaan on September 17, 2021, 09:38:37 PM »
from EUO wiki:
If * is used instead of an id or an index, all items of all types will be returned.

I really don't know. In my experience,
Code: [Select]
returns everything everywhere.

Code: [Select]
finditem *does as well.

I just used the * when I first started writing scripts like 5 years ago, and have used
Code: [Select]
finditem %string * c/g_ , %modfor thousands of continuous hours, so I just stopped worrying about it.
it might add the A modifier if you just use the star. I really don't know lol.

*edit: I guess it if you don't use [parameter 1].
Code: [Select]
finditem * c/g_ , %modI have used it like that, but I always use it unless I just use
Code: [Select]

and thanks crisis. it's probably either going to fail in the wrong spot, or work as intended.
Scripting Chat / Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Last post by Gaderian on September 17, 2021, 09:31:44 PM »
What does the * do in each of the finditem statements?

Scripting Chat / Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Last post by Crisis on September 17, 2021, 08:56:52 PM »
I will test this out tomorrow and let you know.
Pages: [1] 2 3 ... 10