Fire Beetle Math help please

[lydaan]

Been working on my miner. Then I hardcoded the use of a giant beetle in it.... THEN I got 2 firebeetles (for 2 accounts)... going to be a minute before I post my miner, but am hoping someone can help me set up an equation to min/max the use of the fire beetle. I've been smashing my face on my desk for a couple days on this one.

Here's what I know:
minus the occasional ping spike, my miner digs once every second (95% confidence).
I roll humans, and experience 80% or more pulls of 2 ore per dig @ 24 stones
My mules empty are about 60 stones, full 555 stones.
I haven't done the math to figure out exactly how much ingots weigh, but 9/10 stones is close enough, although I believe this to be irrelevant.
Based on an average of 112 readings, smelting on the beetle takes an average of 1.135 seconds (.7min - 2.0max)
Based on a small number of readings, trips to the secure with the firebeetle take roughly 20 seconds.

I currently have my mules set to go home at >405 stones (max-150), this is due mostly to only having my highest skilled miner smelting everything on the fly and the other dropping valorite+ ore in the secure to be smelted by my other miner. But, this is also due to the ever increasing diminishing return on smelting on the fly... which by its nature is always increasing (diminishing) after the first smelt since the bagweight increases.

So... I could try and set-up a growth curve taking into account the weight of the ingots, but I think a rough estimate is good ecough since lag and other outside influences are a factor, and I believe the weight of the ore and the time to smelt/drop are WAY more important.

My gut is telling me that MAXWEIGHT - 200 stones is really where I should be heading to secure, as that is roughly 10digs at ~20 stones per dig...

10digs = 10seconds + 1second for smelting > 1/2 the time to drop at secure (10 seconds)...

I just can't believe that digging once then smelting for a total of ~2 seconds percycle until I reach my %carryweight target to go to secure to be beneficial... that can't be right, can it? So if it's not... what is the target weight to head to secure???

It's been a couple years since I've had to do real math (not accounting), and I feel I'm just missing an important component.

Thanks,

Lydaan

*edit* - its late.. forgot something

The other way i was thinking of doing this was counting smelts. ie go to secure after the 18th or 19th smelt as the total additional time is <= the time to drop...

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

Feel like I'm talking to wall, but sometimes it's helpful to see things laid out in front of you. So this is what I'm going to do.

I'm just going to assume 20secs for a secure drop for the first run, then I'm going to setup a timer for secure drops to take an average of the time it takes. Then I'm going to setup a timer for smelts and sum the time for each smelt, and after the first run, it'll be variable based on an average of how long secure drops take.

something like:

Code: [Select]

if %smeltsum > %avesecdrop - 1000 ;1second....
   gosub securedrop

[Endless Night]

I cannot remember what I set in my miner for this.  But reading above it sounds like you smelt after ever dig.   I know for a fact that I only smelted when max weight is reached.

But maxweight--200 sounds like a good target.  You should have alot of ingots by then.    I think i also added a time limit.. as in after x-mins do a secure drop even if max-weight is not reached.. as i tend to mine in dangerous places sometimes.

[12TimesOver]

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

[lydaan]

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.

[The Ghost]

[Endless Night]

Recall miner
 1) You recall every 30 sec from bank to veins

This was one of the main reasons I went the firebeetle path.    Dropping off the product I consider the most dangerous part of the whole endeavor because of player paging and GMs etc.   Its pretty easy to find extremely remote places to mine where you will never see another player.   But even the most unused bank still has players at it.   If your popping in and out every 30+seconds or so or every few minutes with a blue-beetle the odds of getting paged on go up exponentially in my book.   Vs every 30-40mins with a fire-beetle   (adjust times long time since I've played/mined so not accurate).

[lydaan]

Well, speedtested and currently running... on my FS I CAN actually dig and smelt the dug ore in under 1000ms... (#systime checked)... my guess is about 600% efficiency gain  

not real sure on the math, but I know 10 ingots weighs 1 stone, and 11-20, 21-30, etc ... weighs +1 stone, each;
1 ore weighs 12 stones, so:

Code: [Select]

12 stones of ore =~ .2 stones ingots

I'll post up something later, going camping for a couple days

*edited* for coherency

[Endless Night]

So your saying its more efficient time wise to dig smelt dig smelt ...   than dig dig dig until max weight then smelt ?

That would be pretty interesting.   How does that effect the % of ingots you get .

[12TimesOver]

So your saying its more efficient time wise to dig smelt dig smelt ...   than dig dig dig until max weight then smelt ?

That would be pretty interesting.   How does that effect the % of ingots you get .

I don't see how that would be possible. You're smelting many fewer times by only smelting when the pack is full. Even if it's a tenth of a second to smelt after many rounds it would certainly add up. I think I've been a little lost most of this convo though so we can use the 3-beer rule on this reply LOL.

[Endless Night]

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

[lydaan]

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):

Code: [Select]

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):

Code: [Select]

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:

Code: [Select]

      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:

Code: [Select]

      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:

Code: [Select]

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.

[Endless Night]

Great solution ... for using up the dead time...

In my old miner I created an adaptable mining rate...  With OSI your mining speed is dependent on your ping rate, there is no 1 dig per second rule on OSI......  So my miner attempt to mine faster and faster until it gets the dreaded  action wait messages.  It constantly adjusts its mining rate up and down as your ping rate changes.....

I never ran any statistical numbers on this .. but the mining speed fluxes greatly at different times of day etc.

[lydaan]

well, this may be true on my fs as well... production seems to be down about 20% or more.

the 1 second rule, I've read all over the place, and I believe I've even seen TM post this on someone elses discontinued miner here.

so, should I really be looking for the "you must wait..." action cap? originally using wait 14 seemed to cause my miner  to dig really fast, but also skip a dig every now and then, going by the target click onscreen and the weight in the status bar.

*edit
need to add that wait 14, and even wait 10 did not produce "you must wait..."

[Endless Night]

Well I have no idea about freeshards but on OSI its defiantly not 1 dig a second.   I just created a var  eg %waittime   and defaulted it to say 20  and every time successful dig with no "must wait" messages reduced it (-1) .  Everytime get must wait increased it +1.  I probably added some other stuff so that maybe it only changed every 10/20 digs or something like that.  I would have to dig out my code again to see exactly what it did .... But the end effect was that it was always mining at or near max speed. (+/- 1ms)

You could try something like that so see if your freeshard is truely 1 dig a second.     If I remember correctly the only downside was that sometimes you could dig faster than the result messages appeared, but the messages would eventually catch up bu could throw off any journal scanning...

[lydaan]

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:

Code: [Select]

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