Jump to content




MLG Mining: Circular Branch Mining


358 replies to this topic

#21 SuperBrian

  • New Members
  • 2 posts

Posted 15 December 2012 - 05:57 PM

View PostSuperBrian, on 15 December 2012 - 07:21 AM, said:

So I think this is pretty great. Only suggestion: Could you have the turtles drop torches periodically? Maybe pickup from the fuel chest? I'm finding myself spending a lot of time running behind the turtles cleaning up so i dont have creepers ruining my setup.

Also, the turtles need to handle mobs / other turtles. I suppose it wouldn't be too difficult to write either of these things in myself.

#22 Ulthean

  • Members
  • 171 posts

Posted 16 December 2012 - 12:23 AM

I will probably add an updated version tonight (CET, so in about 12 hours), planned features include:
  • Placing torches (optional)
  • Handling mobs/turtles
  • Improved command line parameters so the order no longer matters (example: digTunnels -torches true -length 16)
If anybody has any other suggestions (or comments about the planned features) I would love to hear them.

#23 Choumiko

  • New Members
  • 1 posts

Posted 16 December 2012 - 05:16 AM

Hi, great programm so far, and i also like the planned features.
But i think i have found a bug with the digOres programm.

When the turtle finishes digging the ores in one tunnel it gives an error like:

- attempting to compare string with int @digOres Line 300 (i broke the turtle. so no exact msg)
- digOres:300: attempt to compare string with number expected, got string

The turtle also digs 3 blocks gorward at the end of the 3x3 tunnel it just finished and then stops with above error
Parameters used: digOres 5 2 3 5 4
CC version: 1.47, MC: 1.4.5
I also have miscperipherals 2.1 installed, but the turtle is a standard wireless mining one.
I haven't gotten to analyze the code, but the error is in the function moveToNextTunnel and from the position the turtle is when the error is raised i assume it somehow didn't go back to the chests (ores where in it's inventory)

Hope this info helps finding the bug :D

Edit: Corrected error message

#24 Ulthean

  • Members
  • 171 posts

Posted 16 December 2012 - 06:21 AM

View PostChoumiko, on 16 December 2012 - 05:16 AM, said:

- digOres:300: attempt to compare string with number expected, got string
- The turtle also digs 3 blocks gorward at the end of the 3x3 tunnel it just finished and then stops with above error

I found the two bugs, thanks for pointing it out, it will be in the update released tonight.
(Attached the files for now, only changed the parameters at the start. (added: tonumber(...) around some variables))

Attached Files

  • Attached File  1.zip   7.81K   327 downloads


#25 Ulthean

  • Members
  • 171 posts

Posted 16 December 2012 - 06:02 PM

The code has been updated, features include:
  • Placing torches (optional)
  • Handling mobs/turtles
  • Handling bedrock/cobblestone generators (with a timeout)
  • Improved command line parameters so the order no longer matters (example: digTunnels -l 16 -torches -radius 4)
  • Removal of bugs
  • Introduction of other bugs (most likely)
The code hasn't been fully tested yet and unfortunatly I don't have the time to write an update manual in the original post.
Here's the gist of it:
  • Ingame: use digTunnels -help to get information about the command line parameters, same goes for digShafts and digOres
  • Always reserve the first slot for your torches.


#26 yarma92

  • Members
  • 11 posts

Posted 17 December 2012 - 02:57 AM

When using the following line to start digTunnels:
digTunnel -l 32 -torchs -torchS up

It returns the error saying invalid direction. This is happening regardless of the direction

edit: from some testing I have it seems the direction you specify after -torcheS is not being parsed through correctly

Edit 2: Found a fix my using a loca var to hold the direction and then passing the local var to the direction check.
elseif args[readParams+1] == "-torchS" then
	if not (readParams + 1 < #args) then
	  printManual()
	  return
	end
	local x=args[readParams+2] --This line is the declaration/assignament--
	if not isDir(x) then --originally if not isDir(dir) then--
	  printDirs()
	  return
	end
	torchSuckDir=args[readParams+2]
	readParams=readParams+2


#27 Ulthean

  • Members
  • 171 posts

Posted 17 December 2012 - 06:16 AM

View Postyarma92, on 17 December 2012 - 02:57 AM, said:

When using the following line to start digTunnels:
digTunnel -l 32 -torchs -torchS up

It returns the error saying invalid direction. This is happening regardless of the direction

You are correct, I accidentaly put isDir(dir) even though dir wasn't correctly declared/initiated.
Thanks for pointing it out, I will update the code immediatly

I guess I wasn't exactly my sharpest at 6 o'clock in the morning :)

#28 OreCruncher

  • New Members
  • 13 posts

Posted 17 December 2012 - 06:49 AM

lol - sounds like most mornings for me. :) One thing I came across was specifying the number of blocks to exclude from mining when using digOres. The turtle cranked along and when it went to deposit the ore into the chest it stopped with an error. Maybe the program can check each slot that is supposed to hold an exclusion block and terminate (with an error) if nothing is in the slot.

#29 Ulthean

  • Members
  • 171 posts

Posted 17 December 2012 - 06:54 AM

View PostOreCruncher, on 17 December 2012 - 06:49 AM, said:

lol - sounds like most mornings for me. :) One thing I came across was specifying the number of blocks to exclude from mining when using digOres. The turtle cranked along and when it went to deposit the ore into the chest it stopped with an error. Maybe the program can check each slot that is supposed to hold an exclusion block and terminate (with an error) if nothing is in the slot.

Do you still have the error message? And which version of the code you used? (the one I posted last night?)

#30 OreCruncher

  • New Members
  • 13 posts

Posted 17 December 2012 - 06:58 AM

Oh, forgot to make some requests. :) Would be nice if there was a way to specify which tunnel to "skip" to when executing a program. It takes a long time to complete something like digOres, and if the turtle croaks for some reason restarting is a pain. Skipping already completed work would speed things up. As for torch laying it would be good to have a separate program that could do it in addition to what you have done. This would allow us to "retrofit" the existing mines without having to re-run the mining scripts. The turtle would remove existing torches in spots it doesn't like, and place the ones it needs.

View PostUlthean, on 17 December 2012 - 06:54 AM, said:

View PostOreCruncher, on 17 December 2012 - 06:49 AM, said:

lol - sounds like most mornings for me. :) One thing I came across was specifying the number of blocks to exclude from mining when using digOres. The turtle cranked along and when it went to deposit the ore into the chest it stopped with an error. Maybe the program can check each slot that is supposed to hold an exclusion block and terminate (with an error) if nothing is in the slot.

Do you still have the error message? And which version of the code you used? (the one I posted last night?)
I haven't tried the one from last night. I am in the process of pulling those down. I will let you know what happens.

#31 Ulthean

  • Members
  • 171 posts

Posted 17 December 2012 - 07:33 AM

View PostOreCruncher, on 17 December 2012 - 06:58 AM, said:

Oh, forgot to make some requests. :) Would be nice if there was a way to specify which tunnel to "skip" to when executing a program.

Should be fairly easy. When I get around to cleaning up the code (commenting, checking for bugs, reengineering and updating the first post)
I will add the option to skip forward to a specific tunnel and to a specific shaft.

#32 OreCruncher

  • New Members
  • 13 posts

Posted 17 December 2012 - 07:59 AM

OK. I tested not having my exclude ores in the turtle and the program still executed. And before I forget yet again, I think what you have here is pretty cool. I prefer this over the Quarry. This method doesn't leave holes all over the landscape. :)

#33 Ulthean

  • Members
  • 171 posts

Posted 17 December 2012 - 08:21 AM

View PostOreCruncher, on 17 December 2012 - 07:59 AM, said:

OK. I tested not having my exclude ores in the turtle and the program still executed. And before I forget yet again, I think what you have here is pretty cool. I prefer this over the Quarry. This method doesn't leave holes all over the landscape. :)

I see, you mean if you say it should have 4 exclude blocks but you don't put in any items?
Should be easy to remedy, good call.

#34 OreCruncher

  • New Members
  • 13 posts

Posted 17 December 2012 - 08:25 AM

View PostUlthean, on 17 December 2012 - 08:21 AM, said:

View PostOreCruncher, on 17 December 2012 - 07:59 AM, said:

OK. I tested not having my exclude ores in the turtle and the program still executed. And before I forget yet again, I think what you have here is pretty cool. I prefer this over the Quarry. This method doesn't leave holes all over the landscape. :)

I see, you mean if you say it should have 4 exclude blocks but you don't put in any items?
Should be easy to remedy, good call.
Yep. That's it exactly.

#35 SciFiJunkie

  • New Members
  • 7 posts

Posted 17 December 2012 - 08:39 AM

Ok so far I love how this is working. But I did find a problem. digTunnels worked great. Once I figured out that it was not going to clear out the center part, That is what I get for assuming. But the digShafts I did find a problem. Every time I was having it do its thing and it ran in to gravel it will loose track of its location and finish the shaft short. This would then cause it to be off on the chest and every shaft from there on would only get worse if it ran in to more gravel.

I did a quick look through on your code but my old brain is not finding the issue.

But keep up the great work.

SciFiJunkie

#36 OreCruncher

  • New Members
  • 13 posts

Posted 17 December 2012 - 08:58 AM

New problem: "digOres:459: attempt to compare nil with number". The turtle arrived back to drop off it's load when this happened. I looked at the code and line 599 is suspicious to me. Other calls to refuel() appear different from this one. The code I am using was the one you posted last night.

#37 Ulthean

  • Members
  • 171 posts

Posted 17 December 2012 - 10:37 AM

View PostSciFiJunkie, on 17 December 2012 - 08:39 AM, said:

Ok so far I love how this is working. But I did find a problem. digTunnels worked great. Once I figured out that it was not going to clear out the center part, That is what I get for assuming. But the digShafts I did find a problem. Every time I was having it do its thing and it ran in to gravel it will loose track of its location and finish the shaft short. This would then cause it to be off on the chest and every shaft from there on would only get worse if it ran in to more gravel.

What do you mean when you say 'not clear the center part'?
The center block of the 3x3? With digSidesToo=true? This should be dug aswell, I will look into it and the gravel aswell, since I assumed both of these to be functional.

#38 Ulthean

  • Members
  • 171 posts

Posted 17 December 2012 - 10:40 AM

View PostOreCruncher, on 17 December 2012 - 08:58 AM, said:

New problem: "digOres:459: attempt to compare nil with number". The turtle arrived back to drop off it's load when this happened. I looked at the code and line 599 is suspicious to me. Other calls to refuel() appear different from this one. The code I am using was the one you posted last night.

599 it is, fuelSlot should be removed from the parameter list

#39 yarma92

  • Members
  • 11 posts

Posted 17 December 2012 - 12:21 PM

View PostUlthean, on 17 December 2012 - 06:16 AM, said:

View Postyarma92, on 17 December 2012 - 02:57 AM, said:

When using the following line to start digTunnels:
digTunnel -l 32 -torchs -torchS up

It returns the error saying invalid direction. This is happening regardless of the direction

You are correct, I accidentaly put isDir(dir) even though dir wasn't correctly declared/initiated.
Thanks for pointing it out, I will update the code immediatly

I guess I wasn't exactly my sharpest at 6 o'clock in the morning :)

Its seems to be running through all 3 updated programs with the torches etc. Also i dont know many who are at their best then.

#40 Ulthean

  • Members
  • 171 posts

Posted 17 December 2012 - 01:17 PM

Next update will be released around tuesday, I am busy until then.
The code is currently in a buggy state, and though it is functional you might want to wait until the next update unless you
are willing to accept that fact.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users