Jump to content




Advanced Mining Turtle - Ore Quarry

turtle

582 replies to this topic

#21 platinawolf

  • Members
  • 5 posts

Posted 30 December 2012 - 12:53 AM

Any chance to add a flag to make it just mine for those time's ya just needs everything "gone" and don't wan't to use a quarry?

#22 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 30 December 2012 - 01:14 AM

Hi PlatinaWolf,

I guess, but I would normally use the excavate program to do that.

#23 DiEvAl

  • New Members
  • 2 posts

Posted 30 December 2012 - 05:12 AM

"Every third row" needs to go much longer way to unload/refuel (about 45 seconds per unload) than "knight's tour".

When doing multithreading multiturtling, in "knight's tour" you don't need to predetermine which turtle will mine which area. So if some turtle had more air and finished quickly, it can go help other turtles. In "every third row" it will just sit doing nothing.

"Knight's tour" mines good ores slowly all the time, but "every third row" mines them in the very end. This is important when you are starting out and don't have many resources yet or if some of those resources are used to automatically craft more turtles.




BTW, this doesn't reflect real usefulness. Why would you want to mine all ores in a specific area in shortest time possible with 1 turtle? For example if a turtle misses 1/10 of the ores but is twice faster than yours, it's usually more useful because it can mine 1.8 times more ores per unit of time. IMHO much more realistic (but probably less fun) way to measure usefulness is a limtime -> infinity (oresMined / (time * nTurtles)).

#24 Cozzimoto

  • Members
  • 221 posts
  • LocationDallas, Tx

Posted 30 December 2012 - 05:58 AM

Spoiler

One thing that my knight quarry program does it i have 4 checks before it detects
and it goes the most common blocks to least common
IE stone dirt sand gravel

and if it compares and matches the very first one lets say its stone and it compares to the stone in the check list it then cant be anything else so it breaks the check list and returns false on my function. if its an ore its not going to return true to any of the checks so my function returns true and then mines it.

as far as moving i dont ever check the top or bottom till i get to bedrock where i only check the bottom because the turtle is already moving down. it just checks the walls and moves down.

another neat thing is when the turtle is returning he moves to its next spot in the knight move and digs up and checks all the walls that way till it reaches the surface.

i think my method is really fast compared to anything i have seen or tried. and uses of fuel is very low since my goal of this program is to do as much as possible in one move to conserve fuel

as for reaching a cave, if it detects a block then check it if not then must be a cave and continue to move down. so i dont lack that 1.6s comparison when he doesnt have to check anything because there is nothing there to check. so its a mixture of detecting if something is there to compare and finding caves

EDIT: another plus i like about the knights move theory is since it digs down every time it goes down you have a chance to find diamonds alot quicker than a standard quarry because you would have to wait for it to go down all the way to the bottom since it digs horizontally.

#25 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 30 December 2012 - 07:39 AM

Hi DiEvAl,

With multiturtles, I was thinking that each would mine out their own area, and talk to a central computer to determine where the next quarry area would be. That way they wouldn't sit idle.

You're right about starting from the top, and therefore not getting the best ores until later. It's a good point, so I may add an option whereby you would still mine every third layer, but start at the bottom rather than the top. You would then get the good ores more quickly than you would if you were using a Knight's Tour. It wouldn't take any longer overall, so maybe it should be the default.

I agree regarding the measure of usefulness. I was trying to outperform the quarry and not miss anything (particularly uranium), but finding 90% of the ores in half the time would be better. Have you got an example of this?

The other thing regarding usefulness vs speed is that the turtle digs into the bedrock at the moment, and perhaps this is an unnecessary luxury (it slows down the average ore rate). Given that it is not uncommon to find good ores amongst the bedrock, I'll probably leave this in for now. It's the same with checking for chests (although this is an option that you can already disable), but again, I just don't like the idea of missing anything in the mined area.

By the way, I've just updated the program to version 0.3 so it is now about 20% faster than the BC Quarry (rather than the original 10% faster). I'm also looking at what the optimal set of "noise blocks" are to maximise the speed.

#26 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 30 December 2012 - 07:47 AM

Hey Cozzimoto,

I definitely agree that a Knight's Tour approach is good if you want to use the minimum fuel. The program I wrote moves through 1 of every 3 blocks, whereas a Knight's Tour would only go through 1 in 5, and therefore will be much more efficient (especially as yours returns up the next shaft rather than returning to the top and digging down again).

Not sure I quite understand your point regarding caves. When you say "if it detects a block", do you mean checking for a block below? So if there is no block below you don't check the four surrounding blocks?

I agree with you point about the diamonds and it is a good one, see my post above that I might change the mining order to start at the bottom first.

#27 Cozzimoto

  • Members
  • 221 posts
  • LocationDallas, Tx

Posted 30 December 2012 - 08:37 AM

AustinKK:

i read your post above about starting from the bottom and i havent thought about that. lol.
but what i have found out is that if it doesnt match its junk list it will still return true if there is nothing there. because initially it was just comparing, but i added if turtle.detect() then check the junk list. but if there isnt anything there then just skip comparing the junk list

#28 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 30 December 2012 - 09:01 AM

Hi Cozzimoto,

yeah, you need to detect as well if all your compares are false. I've changed the order of compares in the latest version of my code so that it does the detect at the end (so check the junk list first, then compare rather than the other way round). It's a little bit quicker since it's more common to find junk than it is to find an air block.

#29 Cozzimoto

  • Members
  • 221 posts
  • LocationDallas, Tx

Posted 30 December 2012 - 09:15 AM

im trying to understand what you did, you do a compare then a detect. why not detect if the block is there in the first place before you take the nescessary time to check the junk list.

my check function does the following.

for i=1,4 do
selects slot
does a compare [then if it matches before the end of the loop it breaks it and returns false]
end

if the loop is finished must return true cause the block being compared must me an ore block


so while its doing the loop i need it to detect if a block is there because if it doesnt then its going to go through the list check it all and none of them are giong to match so it returns true when it doesnt need to becasue its an air block.

this is why my check is in the begining becasue the function that checks the walls i use its return arguments to dig the block if true in another function that loops it to check all 4 sides instead of one.

#30 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 30 December 2012 - 10:43 AM

I have something very similar to you (I have the same type of function to calculate if the turtle should dig), except I do the detect at the end.

My logic goes like this:

Typically, it is a lot more common that you will find a stone block than you will find an air block. Because of this, I want to get to the test that allows the function to return as quickly as possible. I think that finding a stone block (which would be the first junk block) is more than 4 times likely than finding an air block in most cases, therefore detecting for a junk block and then as a final resort checking for an air block should be quicker than doing it the other way round (does that make sense?!)

To put it another way, I guess if you wanted to be really clever, the most efficient way would be to do the following (assuming you agree that this is the order of likelihood of finding these things):

1) Check if the block is stone (compare)
2) Check if the block is dirt (compare)
3) Check if the block is air (detect)
4) Check if the block is gravel (compare)
5) Check if the block is sand (compare)

That would allow the function to return in the quickest possible time because you are checking the most likely case each time. As long as the junk list is small (I've done some tests that are starting to make me think that the optimal junk list might be just stone and dirt) then it should be the case that doing the compares first and the detects second is optimal.

If you have a long compare list then this no longer remains true, but as I say, I'm thinking that a junk list of 2 might be optimal (for my program anyway) in most cases.

#31 Cozzimoto

  • Members
  • 221 posts
  • LocationDallas, Tx

Posted 30 December 2012 - 10:51 AM

ok but an air block is untangable how would you do that in the middle of a junk list? i odnt have an actual spot to check if there is anything there or not. its just written in the code to check if it fails to check everything else.

and i like my junk list cause i dont need any sand or gravel, i hate gravel. lol

#32 platinawolf

  • Members
  • 5 posts

Posted 30 December 2012 - 12:07 PM

The normal excavate program just takes one row at a time though AustinKK, your program takes 3 row's at a time ^^* Though I suppose I could just put some glass in the first slot ^^* I'd lose a slot but its still faster than the normal excavate. Assuming ofcourse they havn't updated the excavate program.

#33 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 30 December 2012 - 09:24 PM

Cozzimoto,

I was thinking that you could somehow configure it to know (so for example, you could give it two junk lists, one to check before the compare, one to check afterwards). Or you could have two settings, one which is the number of junk blocks, one which is how many of them to check before looking for an air block.

Just an idea - not sure I'm going to implement it. As I say, I'm starting to think that 2 junk blocks is optimal (one stone, one dirt) - I'm not quite sure whether it's true in all cases, but if it is, in effect I'm going to get the 1) - 3) elements of the list above.

#34 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 30 December 2012 - 09:26 PM

Hi platinawolf,

Not sure I follow about the glass block. Are you suggesting you put glass in to indicate an air block?

Not sure I follow your point about mining three layers vs one layer either. Can you clarify?

#35 platinawolf

  • Members
  • 5 posts

Posted 31 December 2012 - 07:30 AM

Right ^^* Using glassblock to trick your program that it has noise blocks ^^* As for digging three layers vs one layer, 3 layers is faster due to less movement :P Sides, the normal excavate turtle doesn't open chests does it?

#36 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 31 December 2012 - 09:30 PM

Platinawolf,

Ah, I see what you mean. Yes, you do need to provide a noise block, so glass would do it. If you wanted to mine everything out though, I'm not sure it would be much quicker. I'd be interested to know how much faster it is than excavate (if it is at all).

#37 Ulthean

  • Members
  • 171 posts

Posted 31 December 2012 - 10:20 PM

Sure it is, using the values you pointed out earlier:
  • The normal excavate digs one block per move, so to dig one block it takes on average: 0.4s (dig) + 0.4s (move) = 0.8 seconds per block
  • Three layer excavations dig three blocks per move: 0.4s (dig) + 0.4s (dig) + 0.4s (dig) + 0.4s (move) = 1.6 seconds per three blocks = 0.533.. seconds per block
So three layer excavation programs are 1-(0.533../0.8) = 33% faster than the standard excavation program.

#38 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 01 January 2013 - 07:38 AM

Hi Ulthean,

Yes, I suppose when you put it like that...

It makes sense too because it is doing the same amount of digging, but only a third the amount of moving. Would be interesting to see if it actually works out that way (I'm just thinking that the excavate just digs rather than trying to determine if there is a noise block/chest first).

#39 Doyle3694

  • Members
  • 815 posts

Posted 01 January 2013 - 08:13 AM

I hope you know that 4 stirling engines isn't even half speed, because you said it would be full speed in the video. So I find your testresults..... obsolete.

#40 AustinKK

  • Members
  • 124 posts
  • LocationLeeds, UK

Posted 01 January 2013 - 03:02 PM

Hi Doyle3694,

Yes I now know that the 10Mj/t limit has been removed from the Quarry. I've commented on the video to that effect if you look on YouTube.

I'm going to re-record the video to set the record straight. Running the quarry from a redstone energy cell placed next to it mines the sample area in 39 minutes as apposed to the 1h 3m shown in the video.


It's not quite double the speed, but it's not far off.





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users