Author Topic: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.  (Read 172 times)

0 Members and 1 Guest are viewing this topic.

Offline lydaanTopic starter

  • Jr. Member
  • **
  • Posts: 70
  • Activity:
    1%
  • Reputation Power: 3
  • lydaan has no influence.
  • Respect: +6
  • Referrals: 0
    • View Profile
OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« on: September 17, 2021, 06:47:20 PM »
0
I was wondering if someone with an OSI account with a miner and a fire beetle could try a little bit of test code for me? I was sort of asking about this a few years ago when I was working on my miner for my FS, and I am still curious. The whole test will take roughly 5 minutes if you have a miner and fire beetle ready to go. Let me know if there are any issues with script execution.

Test code:
Code: [Select]
;just copy this code, grab a shovel and your fire beetle
;and head to the nearest cave.
;hit the dirt once, and if you pull up some ore, press play
set #lpc 100
set %oretypes TVJ_EWJ_DWJ_GWJ

finditem OHP * g
set %fireBeetleID #findid

set %shovel #lobjectid
set %mtile #ltargettile
set %mkind #ltargetkind
set %mx #ltargetx
set %my #ltargety
set %mz #ltargetz

finditem %oretypes * c_ , #backpackid
 if #findcnt > 0 6
   set #lobjectid #findid
   event macro 17
   set #ltargetid %fireBeetleID
   set #ltargetkind 1
   target
   event macro 22

wait 30
   
loop:
   set #lobjectid %shovel
   event macro 17
   set #ltargettile %mtile
   set #ltargetkind %mkind
   set #ltargetx %mx
   set #ltargety %my
   set #ltargetz %mz
   while #targcurs <> 1
      gosub scan journal
   event macro 22
   finditem %oretypes * c_ , #backpackid
   if #findcnt > 0 6
      set #lobjectid #findid
      event macro 17
      set #ltargetid %fireBeetleID
      set #ltargetkind 1
      while #targcurs <> 1
         gosub scanjournal
      event macro 22
   repeat
      gosub scanjournal
      finditem %oretypes * c_ , #backpackid
   until #findcnt > 0 || you_loosen in #journal
goto loop

sub scanjournal
   scanjournal #jindex
   if you_must in #journal 2
      display Test failed! you cannot dig>smelt>dig>smelt>... on OSI
      halt
   if there_is_no in #journal 2
      display Success! you can dig>smelt>dig>smelt>... on OSI
      halt
return

Offline Crisis

  • Global Moderator
  • *
  • *
  • Posts: 2561
  • Activity:
    2.8%
  • Reputation Power: 37
  • Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.
  • Gender: Male
  • Scripting well enough to break things!
  • Respect: +190
  • Referrals: 2
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #1 on: September 17, 2021, 08:56:52 PM »
0
I will test this out tomorrow and let you know.

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 347
  • Activity:
    4.6%
  • Reputation Power: 8
  • Gaderian has no influence.
  • Respect: +40
  • Referrals: 1
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #2 on: September 17, 2021, 09:31:44 PM »
0
What does the * do in each of the finditem statements?

"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Offline lydaanTopic starter

  • Jr. Member
  • **
  • Posts: 70
  • Activity:
    1%
  • Reputation Power: 3
  • lydaan has no influence.
  • Respect: +6
  • Referrals: 0
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #3 on: September 17, 2021, 09:38:37 PM »
0
from EUO wiki:
Quote
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]
finditem
returns everything everywhere.

apparently
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]
finditemalone


and thanks crisis. it's probably either going to fail in the wrong spot, or work as intended.
« Last Edit: September 17, 2021, 09:59:33 PM by lydaan »

Offline Crisis

  • Global Moderator
  • *
  • *
  • Posts: 2561
  • Activity:
    2.8%
  • Reputation Power: 37
  • Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.
  • Gender: Male
  • Scripting well enough to break things!
  • Respect: +190
  • Referrals: 2
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #4 on: September 18, 2021, 10:11:57 AM »
0
It failed :(


There are 1 attachment(s) in this post. You must register and post an acceptable introduction to download
fail.jpg

Offline lydaanTopic starter

  • Jr. Member
  • **
  • Posts: 70
  • Activity:
    1%
  • Reputation Power: 3
  • lydaan has no influence.
  • Respect: +6
  • Referrals: 0
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #5 on: September 18, 2021, 10:17:29 AM »
0
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?

Offline Crisis

  • Global Moderator
  • *
  • *
  • Posts: 2561
  • Activity:
    2.8%
  • Reputation Power: 37
  • Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.Crisis has a powerful will.
  • Gender: Male
  • Scripting well enough to break things!
  • Respect: +190
  • Referrals: 2
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #6 on: September 18, 2021, 11:13:07 AM »
0
Almost immediately

Offline lydaanTopic starter

  • Jr. Member
  • **
  • Posts: 70
  • Activity:
    1%
  • Reputation Power: 3
  • lydaan has no influence.
  • Respect: +6
  • Referrals: 0
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #7 on: September 18, 2021, 11:16:51 AM »
0
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.
« Last Edit: September 18, 2021, 11:20:27 AM by lydaan »

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 347
  • Activity:
    4.6%
  • Reputation Power: 8
  • Gaderian has no influence.
  • Respect: +40
  • Referrals: 1
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #8 on: September 18, 2021, 01:35:15 PM »
0
from EUO wiki:
Quote
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]
finditem
returns everything everywhere.

apparently
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
  4.  
  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.  }
  29.  

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...
"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Offline lydaanTopic starter

  • Jr. Member
  • **
  • Posts: 70
  • Activity:
    1%
  • Reputation Power: 3
  • lydaan has no influence.
  • Respect: +6
  • Referrals: 0
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #9 on: September 18, 2021, 02:09:49 PM »
0
Quote
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,

Example:
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
  break
else
   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.
« Last Edit: September 18, 2021, 02:50:00 PM by lydaan »

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 347
  • Activity:
    4.6%
  • Reputation Power: 8
  • Gaderian has no influence.
  • Respect: +40
  • Referrals: 1
    • View Profile
Re: OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« Reply #10 on: September 18, 2021, 03:17:58 PM »
0
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...
"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Tags: