Quick note, you are closing your While loops before you ever run anything.

LOL hahaha
so I like to make my waits variable rather than static... In my experience (may be different on OSI) after clicking the shovel button, you have to wait for the gump to reappear to close it, this takes somewhere beteween 1400 and 1800ms sometimes more (I also have to deal with 4 second saves every now and then, where the screen freezes)

I could use a wait 20 which would cover the gump reappearing most of the time, but that doesn't cover the server saves, so I'd have to go with a wait 90 to compensate, but that would be real lame as it wastes a lot of time, so writing my waits like:

while something not true || something true
{
}
allows for variable wait times that always wait the minimal amount of time (including lag) before performing the next action. I sometimes write gotos with ifs if the procedure calls for it:

set %propcheck #property
finditem * c
propwait:
event property #findid
if #property = %propcheck
   goto propwait
that's not really the best example, but I did use something like that for about 2 weeks, before I found a better way.

Keep it simple, after you are done making a shovel just click Exit ("click #contposx+30 #contposy+450" if a crafting gump on OSI). Don't forget to wait until the Gump returns after making the shovel before you move to the next one. I would also suggest eliminating #contkind.

I use a "ClickAndWait" sub which clicks where you want it to click and waits for the Gump to respond before moving on to the next line of code. Fell free to check out my standard subs in my script library, maybe it will help.

X

I use
 click #contposx #contposy f r
to close everything with no issues, though I haven't tried it on runebooks because of their oddball #contsize

I also use #contkind and #contsize quite liberally with no issues, and on my miner I have pulled the check values out and put them in the header, so any user could readily change their values if needed.

I agree it's not the simplest approach, but it's the only way I've found to achieve the performance I want

*edit*

PEBKAC at top

The issue actually turned out to  be EUO... or UO... or something... anyway, here's what I tried:

while #contkind <> gjz
   {
   }
   click #contposx #contposy f r
   set %timeout1 #systime
   while #contkind <> gjz && #systime - %timeout1 < 4000
   {
   }
   wait 20
   tinkerreturn:
   if #contkind = gjz
      click #contposx #contposy f r
I doubled down on the click r... no fix, so I added that 4 second wait in there to see what was going on. I have no idea why it was doing this, but it stored the gump, hidden, and as soon as the sub returned it opened the gump again... wth... anyway, adding a goto at the point of return seems to have fixed the problem. I have no clue, but it's closing now

That's odd for crafting gumps

I know bags do that, and nextcontpos x y only seems to work with the backpack, so my remedy has been to force the gump in question to where I want it for the clicks:

positioncraft1:
contpos %craftgumpposx %craftgumpposy
if #contposx <> %craftgumpposx && #contposy <> %craftgumpposy
   goto positioncraft1
I really only did this so I could pull the set click values out of the loop so people could readily change the clicks as needed.

Not really an answer to your question, but I would bet only cheffe/ the maker's of the UO UI could answer that.

-edit-

On reread, it sounds like you dragged the gump with your mouse at some point... Gumps can only PERMANENTLY be moved with the mouse, or using click x y D click MC r, or probably event drag/drop... (not exevent drag/drop)

Ok, I'd be reeaal interested to know how this works on OSI...

I've got "no metal" returning in under 200ms, but successful dig/ "you loosen" is another story.

This is what I have right now:

repeat
{
   ;dig action stuff
   set %digwait #systime
   ...
   jup:
   ;journalscan stuff
   ...
   if %jup + 1 >= #jindex
   {
      if #systime - %digwait > 750 <--- ;succesful dig/"you loosen" timeout/return
         goto stopdigging
      goto jup
   }
   stopdigging:    
}
until %1 = stop
I've set the succesful dig timeout to 750ms to combat the issue in question dealing with FS/OSI, and I'll try to explain as best I can.

Succesful digs seem to require some sort of server return, and here's why I think that's true (I'll add my sysmessage output to illustrate timing). Setting the timeout low, like 500ms, results in journal output of:

sys: mining at some spot
Where do you wish to dig?
sys: looptime = 520ms  <---- this return is the issue... nothing dug, just returned and tried again
sys: mining at the same spot
Where do you wish to dig?
You put some... <----- this is actually the return from the first dig, but it took too long and tried again
sys: looptime = 522ms

Setting the timeout higher results in less occurences of returns without ore, and setting it high enough eliminates those fails altogether. ;waiting for the journal to update after a succesful dig results in looptimes of over 1 second, so the timeout is faster

The point to setting it higher (or maybe extremely low if you don't mind spam, like 250ms just above the "no metal" return) is to not waste time, as in everytime it returns before having dug, the timeout is doubled:

sys: mining at some spot
Where do you wish to dig?
sys: looptime = 520ms  ;wasted time...
sys: mining at the same spot
Where do you wish to dig?
You put some...
sys: looptime = 522ms

total time to complete 1 dig = 1042ms, so setting the timeout a little higher (like 800ms) results in a faster return overall than setting it lower, as you get less of those "misses" that double the time, AND this is where it might differ on OSI.

sometimes you could dig faster than the result messages appeared, but the messages would eventually catch up

My interpretation of this looks like:

Where do you wish to dig?
Where do you wish to dig?
Where do you wish to dig?
You put some...
You put some...
You put some...

If you do in fact retain a 1:1 ratio of digs to ore, then yes OSI does allow you to dig faster than my FS, but if it looks something like:

Where do you wish to dig?
Where do you wish to dig?
Where do you wish to dig?
You put some...
You put some...
Where do you wish to dig?
Where do you wish to dig?
Where do you wish to dig?
You put some...
Where do you wish to dig?
Where do you wish to dig?
You put some...

you're wasting time with those "misses," as whatever your wait time is between attempts, it gets doubled for every return before success.

so, back to the original topic, I will try the dig smelt dig smelt thing (as it still may be possible), but the finditem return might take too long to make it efficient...

EN, I'd really appreciate some confirmation (if possible) on the journal output. ;don't worry about it too much

from the top...

I follow one guideline when it comes to working on my miner: The dig routine is king
Any action that's not either recalling to the next spot or dropping off at secure, like making shovels, smelting, etc. is time wasted on not mining. Yes, these are support functions that are necessary, but I believe this can be optiomized (and I know it can on my free shard, and would be willing to bet some actions will also work on OSI), and these functions can be absorbed into the actual dig routine.

Following the logic of "a tile may only be mined once per second," from what I've seen, most dig routines look someting like (semi-pseudo code):

dig:
finditem %shovel * c_ , #backpackid
set #lobjectid #findid
event macro 17 0
target
set #ltarget x/y/z
...
event macro 22 0

wait 20     <------------------  this is what i don't like

goto dig   

Using the same "once per second," logic, there is another way to set up a wait timer of 1 second (semi-pseudo code):

dig:
finditem %shovel * c_ , #backpackid
set #lobjectid #findid

digwait:
if #systime - %digwait < 1000    <---------------------   variable wait timer
   goto digwait

event macro 17 0
target
event macro 22 0
set %digwait #systime
goto dig
I initally switched to this variable style of wait timer because of the variance that I was seeing from finditem returns, and by setting it up this way, I'm able to ignore the finditem return time. But rather than ignore, I realized it's more like ABSORB. And once I realized this, I realized I could cram all sorts of functions into this loop as long as they don't push the dig routine past one second, and gain in efficiency.

... fast forward to this thread and the firebeetle....

But reading above it sounds like you smelt after every dig

This had sort of crossed my mind, but I didn't give it any serious thought, until EN posted this.

Now, back on topic...

My experience on my Free Shard is that smelting has no real cooldown, just ping related response, so I'm able to smelt ALL my ore like this:

      finditem %oretypes * c_ , #backpackid
      for #findindex 1 #findcnt
      {
         if #findcol notin 2219_1174_1152_1153_1272_1278 ; this is the skipper I currently use to not smelt valorite and bonus ore on the fly
         {
            set #lobjectid #findid
            event macro 17 0
            target
            set #ltargetid %firebeetleid
            set #ltargetkind 1
            event macro 22 0

            wait 6   <------------- 300ms... just over my ping

         }
      }
This is what I know about smelting on the Fire Beetle:

      if #weight > %carryweight
      {
         gosub firebeetle smelt
         wait %genericwait
         if #weight > %carryweight - 100
         {
            gosub firebeetle mount
            gosub travel home
            gosub secops
            gosub firebeetle mount
            gosub travel back
            gosub firebeetle dismount
         }
      }
writing my smelt routine like this resulted in a range from 700ms - 2100ms. ALL of the variance due to how many DIFFERENT ores there were at the time of smelting... so, 1 ore type = 700ms

so, I tried this:

repeat
{

   ...

     digwait:
     if %loopspeedcheck < %digloopupperbound
            goto digwait
      event sysmessage mining at Book %bookcnt Rune %runecnt Vein %onvein
      finditem %digtools * c_ , #backpackid
      set #lobjectid #findid
      event macro 17 0
      target
      event macro 22 0
      set %reploopcheck #systime
      set %digwait #systime

...

if There_is_no in #journal

...

finditem %oretypes * c_ , #backpackid
      if #findcnt > 0
      {
         for #findindex 1 #findcnt
         {
            if #findcol notin 2219_1174_1152_1153_1272_1278
            {
               set #lobjectid #findid
               event macro 17 0
               target
               set #ltargetid %firebeetleid
               set #ltargetkind 1
               event macro 22 0
               goto stopdigging
            }
         }
      }

...

   stopdigging:
}
until %1 = stop
and my mule is still pounding dirt every second (#systime checked)... so it's possible at least on my freeshard to dig smelt dig smelt continuously, and depending on the "use ore," cooldown on OSI, it may be possible on there as well.

I don't see how that would be possible. You're smelting many fewer times by only smelting when the pack is full.

true, but that time is time spent not digging. By incorporating smelting into the 1 second dig wait, there is literrally no time lost in the total operation of the script... that .7 - 2.1 seconds to smelt is now essentially 0 seconds.

Wait a sec you said on your  FS   as in free shard.....   well that might explain it.

Yes, this is always a possibilty, but I think you may be surprised. The ability to dig smelt dig smelt hinges on the fact that there is no real cooldown for smelting on my FS, and i didn't even write in a wait after it smelts in the digroutine... If you can spam smelt on OSI, this should be possible, but you'll have to check out the snippet about smelting in general up above.

How does that effect the % of ingots you get .

so my FS is a little weird. Valorite seems to be 100% smeltable at 105 mining. We have bonus ores Blaze, Electrum, Toxic, and Platinum. Blaze being the only one I can mine because my skill isn't high enough.

We also have another pair of leather mining gloves that are +20, so Blaze seems to be 100% smeltable at mining 120.. My miner with the +20 gloves smelts everything except the ores I can't get yet, and my miner with the +5 gloves smelts valorite and below, only... If I lost some I wouldn't know because I don't track ores, because I literrally have multiple 60k stacks of everything... but it seems to be 2 ingots per 1 ore, with incredibly low failure rate.

Thanks for the replies! ... was losing hope.  

Been busy with my lumberjacker, so I haven't messed with this yet, but was more a concern when I first got my firebeetles and didnt't set a secure drop limit, and watched all the efficiency burn up as they got close to maxweight.

But reading above it sounds like you smelt after ever dig

I don't actually smelt after every dig, just the maxweight approach. I haven't speed tested it, but if I could dig and smelt within 1250ms (reliably) I would, as that's currently what my dig cycle is set to after ping compensation, and there would litereally be exponential efficiency gain, but I don't think I can and therefore an efficiency loss.

On the other hand that is 2000 ingots you aren't going to have when you head home to dump.

LMAO

I'm pretty sure if you didn't set an upper limit, your miner could just stand in the same spot, continuously digging/smelting and the resource respawn would beat YOU.


So right now, it's set to weight. I WILL be setting it to time based as I described at the end of my first post, where I sum the time of smelts (after reaching maxweight), and when one more smelt would make the sum greater than the time to drop at secure, I head home. The variance is so high (.7s min - 2.1s max) that i think this is the best *simple* approach. I could create a calculus formula to compare the 2 growth rates (ingot growth vs sum of smelt time growth), but after discussing with some friends, that would only increase the efficiency by something like 5 mins (it's most definitely under 10mins) in a week of operation (168hrs, so <.001% )... not worth it, until I get other stuff done, then I might check my math, but I doubt it.

----------------------------

After thought.

Anyway, I appreciate the input and it's very nice having a place (thanks TM) to discuss these matters "outloud," (even if I do just end up talking/typing to my screen). I'm glad this was discussed, because one player keeps killing one of my mules and it's beetle (using a gargoyle's pick axe), so the math will apply when I switch to a portable smelter and a Greater Dragon or Cu Sidhe for defense.

So for EN and anyone else interested... I've figured out how I wanted to do my journal update wait.

If TM's sub is the "Advanced," version... then this is the "get a bigger hammer" remedial version of journal scanning:

     event sysmessage mining at Book %bookcnt Rune %runecnt Vein %onvein
      finditem %digtools * c_ , #backpackid
      set #lobjectid #findid
      set %jupdate #jindex + 1
      event macro 17 0
      target
      event macro 22 0
      set %digwaitbegin #systime

...

      jup:
      scanjournal #jindex
      if There_is_no in #journal
      {
         if #weight > %nrweight && %onvein = %veincnt && %stripmine = no
         {
            gosub travel home
            gosub secops
         }
         set %stopdigging now
         goto stopdigging
      }
      if You_have_worn in #journal
      {
         gosub checkingots
         gosub tinker shovel
      }
      if That_is_too in #journal || Target_cannot in #journal
      {
         event sysmessage Whoops, travel broke... HOLD ON
         gosub travel nextrune %runecnt
         set %stopdigging now
         goto stopdigging
      }
      set %endcheck #systime - %digloopwaitcheck
      set %digwaitend ( #systime - %digwaitbegin )
      if %digwaitend > 300 && %endcheck > 980
      {
         ;event sysmessage %digwatend | %endcheck
         goto keepdigging
      }
      goto jup

The only way I've broken it so far is if I spam event sysmessages during the update loop... I believe it should be fast enough to read through the global chat spam on my server... and if not, I'll just turn global chat off...

*edit* oh, and by moving to scanjournal dependant catches, I was able to improve my move to nextvein rate by about 30%... it catches the "no_metal" at about an average of 200ms (was a "wait 6..." ~315ms), and moves to the nextvein at an average of about 650-750ms.

Pretty happy with the results