Possible to prioritize Finditem?

[Gemviper]

Heya,

Is it possible to prioritize what items #finditem locates from a list of item types? To be clear, I know I can tell it to look for a specific item type and it will look for that type first but that's not what I'm asking. If I SET a %list of item types, such as AAA_BBB_CCC_DDD_EEE_FFF_GGG_ETC is there a way to look for the first item type on the list  FIRST?? The the second etc?

From testing what's happening is that it scans for ANY item on the list so if it finds a GGG item first it performs the desired action with that and may find an AAA item next pass. I'd really like to specify a string of item types and have it search them in order until it finds one and then loops back to the start. I don't want it finding or dealing with a GGG item if an item before it on the list is available.

I *could* do a finditem AAA G for example, then a finditem BBB G and then finditem CCC G etc but that seems like a lot of code. Is there any way to get EUO to take my string of item types and fully scan them IN ORDER ??

Thanks in advance, I'll clarify further if needed.

[TrailMyx]

Unfortunately I don't think there's a way to do that in EUO.  That trys to peek into the internal workings of EUO that you don't have any control over.  That's sort of why I had priority lists in my IDOC looters because of that lack of control.

The word today is THAT apparently.... 

[Gemviper]

It's not TOO bad with lists but there gets to be a lot of lists to make and within each item type there are awesome items and junk. The order of your lists might mean that you grab a lower end item from one list instead of a 50m item right next to it from the next list.

Finding the items you want to grab first is a bit of a challenge, but who's not up for a good challenge

Thanks for letting me know what I was seeing was "working as intended".

[Crome969]

Heya,

Is it possible to prioritize what items #finditem locates from a list of item types? To be clear, I know I can tell it to look for a specific item type and it will look for that type first but that's not what I'm asking. If I SET a %list of item types, such as AAA_BBB_CCC_DDD_EEE_FFF_GGG_ETC is there a way to look for the first item type on the list  FIRST?? The the second etc?

From testing what's happening is that it scans for ANY item on the list so if it finds a GGG item first it performs the desired action with that and may find an AAA item next pass. I'd really like to specify a string of item types and have it search them in order until it finds one and then loops back to the start. I don't want it finding or dealing with a GGG item if an item before it on the list is available.

I *could* do a finditem AAA G for example, then a finditem BBB G and then finditem CCC G etc but that seems like a lot of code. Is there any way to get EUO to take my string of item types and fully scan them IN ORDER ??

Thanks in advance, I'll clarify further if needed.

Logical seen it would be a performance loss if euo need to first query items and then look logical.

You basicly have a list internal with all objects and it iterates through the objects and ask if metafields are matching.
So in order to sort this thing by priotizing you would need to sort out all results first (like you do on normal way) then order by your priorities and then push it to the result stack.
this would cost much more time as it does atm.

[Endless Night]

to translate all that  do a  finditem and then scan the results at high speed to determine most valuable item  you could set a time limit as well

Code: [Select]

finditem  massise_type_list  , G_3
if #findcnt > 0
   {
   set !LPC #lpc
   set #LPC 20000
   set !GrabItRanking 10000000
   set !Grabit N/A
   for #findindex 1 #findcnt
      {
       set %Ranking  1000000  ; 1 = best
       if #findtype = ???
          set %ranking  1
       if #findtype = ???
          set %ranking  2
       if #findtype = ???
          set %ranking  3
       if #findtype = ???
          set %ranking  4
       If %ranking <= !GrabitRanking
          {
           set !GrabitRanking %Ranking
           set !Grabit #findid
           If !GrabitRanking = 1  ; the best , + could add  ||  %time > endtime
              break   ; first time endless published code with break but feeling lazy today.             
          }
      }
   set #LPc !LPC
   If !Grabit <> N/A
      ; some code to grab the itemnum in !grabit
   }


[Biza]

I have a question about LPC and scripts like this one. Sorry but I have limited knowledge on what LPC exactly does to each command in euo. I know LPC ramps of the lines per cycle, I understand cycle as well. My question refers to this:

when ramping up the LPC is it wise to do that during a scan area? for instance if your looking for items in say a 2 tile radius, would setting the LPC up to 10k be ok. setting the LPC up to 10k during a drag/drop or any other action that has waits set in?

I have a script im writing that is a junk vacuum. it runs around the ratmen in the abyss and sucks up anything I have deemed useful, it does it while stealthed (or its suposed to -.- )
If i set the LPC up while walking around looking do I need to slow it back down during a drag, or can I leave it at 10k as long as I have the appropriate waits?

Sorry if this is a hijack but It seems to be some what similar to what gemviper is building.

[Endless Night]

I find the easiest way to think about LPC is that it only has effects on the commands that DO NOT  interface with the client.  ie it doesn't matter what you LPC is a FINDITEM still takes the same amount of time... an EVENT PROTPERTY ALSO   etc.

Therefor I primarily use it as a temporary solution for PROCESSING large amounts of data quickly.      In the above code after the finditem I don't use any client interfacing commands,  all the data from the finditem is in memory I am just iterating though it as fast as possible  LPC 20000 is basically max speed it will go no faster and probably doesn't even go that fast.

Now a word of warning.... You dont want to run any script permanently on LPC 20000 or anything above guess 150 as it will affect the operation of all other programs running on your machine and stress out by not giving it any rest cycles.    Default LPC is 10  and for 99.9% of scripts thats perfectly fine with the occasional ramp up to 100 1000 for select areas.     If you have a massive list and its time critical such as gemviper's  idoc looting well bursts of 20k are fine.

you question: So I would say why are you running your stealth script at 10k lpc  what sort of processing are you doing where you really need that speed over say lpc 100.  Drag and drop commands should work ok and waits still wait the same amount of time but you may wish to make them wait a bit longer as you didnt take as much time to get to that line of code (ie the overall wait is shorter due to short processing time executing your commands).    Also if you do run your script at 10k you should add some rest cycles by adding the occasional wait 1 to places.  Personally I would just run at 10k for actions that actual can use the ramp up in speed,  it doesnt sound like from the script description that you need the extra speed except for maybe processing the finditem list itself like above.  The stealthing, movements and checks sure dont need 10k lpc 10 is perfectly sufficient for stealth movement.

 The best thing you can do to speed up any script is to make sure you use as few FINDITEMS as possible.  Finditem is by far the slowest command .. instead of looping finditem thisitem  then finditem thatitem   do ONE finditem  thisitem_thatitem_theotherone     and then itterate throught the resulting using  #findindex =1.... #findcnt .

[Biza]

you question: So I would say why are you running your stealth script at 10k lpc  what sort of processing are you doing where you really need that speed over say lpc 100.  

Its euo I still havent got stealth to work on my pc. I want to ramp up the search section of my script, it walks around, ensures that I'm not poisoned, checks hps/debuffs ect then gets to an area in my rail and checks a massive list of items I have (clean up brit worth > 20 points). So when its doing its scan of the area It some times starts moving before its done. I need to condense this to one script and I think that will take care of my issues. I started crashing when I attempted raising lpc on the search script.

I find the easiest way to think about LPC is that it only has effects on the commands that DO NOT  interface with the client.  ie it doesn't matter what you LPC is a FINDITEM still takes the same amount of time... an EVENT PROTPERTY ALSO   etc.

Therefor I primarily use it as a temporary solution for PROCESSING large amounts of data quickly.      In the above code after the finditem I don't use any client interfacing commands,  all the data from the finditem is in memory I am just iterating though it as fast as possible  LPC 20000 is basically max speed it will go no faster and probably doesn't even go that fast.

That actually answered my question on LPC, thanks EN