Snap and Box - The dynamic duo of mining turtles - Expandable mining well quarry without frames

UPDATE 1:

Hi everyone,

Here's the update video with some new features.

They include:

• Launcher with automatic updating of launcher and snap/box programs
• Works in new Misc Peripherals
• Overflow protection
• Works in worlds with fuel turned off now.
• Stopping after x blocks
• NxN rectangle mining

[media]http://www.youtube.com/watch?v=kIsqkObG4qE[/media]

————————
ORIGINAL:

Hi Guys,

I had this idea of using turtles to replace the Redpower 2 mining well frame quarries with turtles.

I used an engineering turtle and a mining turtle to move mining wells and energy tesseracts across the map to great effect.

This setup is very fast and expandable.

Here is a youtube video of the idea in action:
[media]http://www.youtube.com/watch?v=BOP0W-EK8_k[/media]

Here is the git repository in case anyone wants to contribute:
https://github.com/p...torm/SnapAndBox

Here are the pastebins:
http://pastebin.com/7dzX0PF8
http://pastebin.com/qfE5pBvq

Let me know what you think.

Thanks

That is really well done. The idea is great! What about changing some variables, before you let them go and start mining? For example ask the player if he wants to change the variables and if not it just skips it and uses the standard ones or it let the user tipe in the number he wants to e.g. let the turtle wait before keep going or the charge level.
Also a variable, which lets the turtle move just a given amount of blocks would be nice. So that you dont have to chase the turtle or come back in a hour if you dont let them mine trough a neighbor's base :P/>

I quickly run over the code (to check how you made them sync :P/> ) and it was well done!
The only mistake i saw was at line 166 (rechargeBox). it would print "Received: .. msg".

Thanks for the feedback. I do need to redo a part of that syncing code - If you boot snap first you don't get that error - but I just have to have box handle the nil broadcast that snap sends out if you boot box first.

This is version 1.0 so I do have lots of ideas for future features. I'm working on session persistance/resuming right now and having them stop after a certain number of blocks. I want to give them the ability to turn/mine a set rectangular area also. I also have code to give the user the option of opting into automatic updates so if I change the code people can get updates when their turtles next reboot.

Definitely been a fun project so far and I've got another cool one in the works.

-Psyestorm

Great! Nice to hear that are keep going with the program.

Very nice. Pretty fast.
Can it auto-refuel turtles ?

psyestorm, on 28 May 2013 - 01:35 PM said:

Thanks for the feedback. I do need to redo a part of that syncing code - If you boot snap first you don't get that error - but I just have to have box handle the nil broadcast that snap sends out if you boot box first.

This is version 1.0 so I do have lots of ideas for future features. I'm working on session persistance/resuming right now and having them stop after a certain number of blocks. I want to give them the ability to turn/mine a set rectangular area also. I also have code to give the user the option of opting into automatic updates so if I change the code people can get updates when their turtles next reboot.

Definitely been a fun project so far and I've got another cool one in the works.

-Psyestorm

Really nice idea.

Hey psyestorm,

Nice idea well implemented. :D/>

Have you tested its performance against frame quarries? How does it get on?

Awsome i've set up so many of them in my world can i use it in my os which will be released soon and of corse i will add credits

Can you share exactly what the turtles are? I know they are mining and engineer, and chunkloading, but what else?

This is awesome. Question though, how can you communicate wirelessly if they have chunkloaders in their other peripheral slot? And would it be difficult to modify this program to dig out a square?

D3matt, on 30 May 2013 - 09:19 PM said:

This is awesome. Question though, how can you communicate wirelessly if they have chunkloaders in their other peripheral slot? And would it be difficult to modify this program to dig out a square?

Chunk Loaders work as Wireless Modems too.

To OP: This is incredible!

CreeKsx3, on 30 May 2013 - 02:35 PM said:

Awsome i've set up so many of them in my world can i use it in my os which will be released soon and of corse i will add credits

Sure, I'd be happy to be included. I'm working on a new version that supports resuming and other features so just wait for that one please.

Look here or reddit for updates.

I'm not sure if you noticed but you're gonna need 4 turtles for this to work in the future. Chunkloaders no longer are crafted with the wireless modem.

You need:

Wireless mining turtle
Wireless Engineering turtle
2 Wireless Chunk Loading Turtles

I didn't realize chunk loaders were also wireless modules. Too bad they are splitting that. Should be left together. Armor modules are kind of worthless as are expanded cargo mods because there just isn't enough slots left to make them useful.

You can use MJ's to power the charging stations?

This could really use some path control. Maybe 3 options:

Simply how far to go in a line
spiral out creating an ever expanding quarry pit
a pit of a fixed size in 2 directions.

Hey what mod pack in ftb is this cause I would like to know how to get that import bus cause right now im only using gates. Also what is that machine next to that me importbus pipe thing

jakemg, on 02 June 2013 - 01:05 AM said:

Hey what mod pack in ftb is this cause I would like to know how to get that import bus cause right now im only using gates. Also what is that machine next to that me importbus pipe thing

This is not necessarily FTB. Anyway, the mod that gives the import bus and all that, is called Applied Energistics.

I'm also curios what that thing next to the "importbus pipe thing" is.

Also, love this program, but for 1.5.2 it needs some more stuff as mentioned earlier, a chunk loader turtle to follow (if radius is increased in config, else you need 2)

Next to the importbus pipe is the ME drive if i am not wrong. It accually is all from the allready mentioned Applied Energistics mod, which makes storing your items very effective in a small area of space.
If you dont have Applied Energistics installed, you can put a Redstone Energy Cell next to an Autarchtic Gate and it will dump items out in notime, depending on how high you set the Redstone Energy Cell Output.

CrissHill, on 31 May 2013 - 06:46 PM said:

I'm not sure if you noticed but you're gonna need 4 turtles for this to work in the future. Chunkloaders no longer are crafted with the wireless modem.

You need:

Wireless mining turtle
Wireless Engineering turtle
2 Wireless Chunk Loading Turtles

Thats sad news.. staying with 1.4.7 seems more and more a better idea to me. heh

Anyone know if engineering turtles can place chunk loaders? They could place one
down at the start then just before exiting the range place a second down and go pick
up the first and repeat this.. Just depends if they can drop and activate them I guess.

That or just have a third chunkloader turtle tag along behind hehe Rename it the 3 stooges
hehe Or 3 musketeers ;)/>

CrissHill, on 31 May 2013 - 06:46 PM said:

I'm not sure if you noticed but you're gonna need 4 turtles for this to work in the future. Chunkloaders no longer are crafted with the wireless modem.

You need:

Wireless mining turtle
Wireless Engineering turtle
2 Wireless Chunk Loading Turtles

I'm working on a more elegant solution. Updates later this week.

Very nice setup . I think you can give up the complicated msg sending and pulse signal on the back of the mining turtle to make the back turtle understand what to do . it still complicates things a bit

I think there is a single turtle approach that can be taken but it would limit the mining area . You can use energy conduits which can be broken with a pick without side effects .you can make it mine a larger area if you can make it handle multiple conduit slots (shouldn't be hard)

edit: fixed and debugged the script - seems to work, may need some tweeks
This is a simple code snippet that does this

local miningwell=1
local chest=2
local conduit=3

for j=1,30 do

for i=1,30 do

turtle.select(miningwell)
turtle.placeDown()
turtle.back()
turtle.select(chest)
turtle.placeDown()
turtle.select(conduit)
turtle.place()
sleep(5) --don't remember how long
turtle.select(chest)
turtle.digDown()
turtle.down()
turtle.select(miningwell)
turtle.dig()
turtle.up()

end
turtle.select(conduit)
--- retract the conduits might need another approach
while turtle.detect() do  turtle.dig(); turtle.forward(); end;

turtle.turnLeft()
turtle.back()
turtle.placeDown()
turtle.turnRight()
turtle.back()
turtle.place()
turtle.back()
turtle.place()
end

http://pastebin.com/UxCywPyS

notes:
retracts pipe at 1:21
next line setup at ~1:48

edit : doh I was watching a stream when recording this so I deleted the audio and reuploaded it

[media]http://youtu.be/1ZL3oaYuu0g[/media]


edit2: changed the script to default 10 second sleep and take sleep time as first parameter (only updated in pastebin) .
I tested a low tech setup with 5 magmatic engines fed by waterproof pipes and using gold conductive pipes and it seem to work but energy propegation is slower in gold pipe . the 5 engines provide 20/mj which seem to give the turtle enough time to retract the pipe .

edit3: Don't use gold conductive pipes the turtle destroys them :(/>/>/>

Bump - New Update - Info in OP.

Really nice update! Snap & Box might be better then a real quarry allready :D/> This programs needs more attention!
Just two things i want to have changed in this program :P/>

First, i would like to press a key e.g. 1 and then the turtle recognizes it instead of having me tipe it in and hitting enter.

Spoiler

local event, key = os.pullEvent("char")
if key == "1" then
-- do stuff
elseif key == "2" then
-- do stuff
end

What about letting them walk back to their startin position? Then the player would know where he finds the turtles if they finished their job.

UNOBTANIUM, on 07 June 2013 - 11:18 AM said:

Really nice update! Snap & Box might be better then a real quarry allready :D/> This programs needs more attention!
Just two things i want to have changed in this program :P/>

First, i would like to press a key e.g. 1 and then the turtle recognizes it instead of having me tipe it in and hitting enter.

Spoiler

local event, key = os.pullEvent("char")
if key == "1" then
-- do stuff
elseif key == "2" then
-- do stuff
end

What about letting them walk back to their startin position? Then the player would know where he finds the turtles if they finished their job.

Thanks for the feedback. Returning to starting position is planned for the next update, but I need to figure out how I want to handle it since it's 2 turtles. Normally Box tells Snap what to do, but it might be easier to have them both track their movement to return home.

Good idea with the pullEvent - I'll have to make that change in the next update too :)/>

Also - I've posted this here, youtube (obviously), and reddit. Any other places I should look to post to get more exposure? :)/>

Allright. In the video you sound like you are allmost done with it ^^'
Good to hear that you still want to work on it tought :P/>

You can try and post it on the feed the beast forums. However, most threads wont exists long before falling on side 2 and never seen again :D/>
There also exists a site called TurtleScripts.com i recently discovered, but it seems to be allmost dead :S

This looks very cool and elegant. I can't wait to get home and test it out on my test world. I am interested in how you solve the chunk loading problem. This solution solves an issue I was having with using turtles to wipe out the end world. Persistence is key in my environment. I am constantly losing my mining turtles when the server at home gets shut down.

Good job.

Even programs with session persistent can fail. If you are saving a variables before the turtle moves it should be 99% fine. But if the variable gets saved and the chunk gets unloaded right in that milisecond before the turtle starts moving the turtle messed up by one block. However it is the best way to do it for right now :S

I don't know if you saw the bug report I put on Reddit, but there seems to be a bug with Minecraft 1.5.2, CC version 1.53, MiscPeripherals version 3.3d, Thermal Expansion version 2.4.3.0, and OmniTools 3.1.3.0. The bug is that Snap (the wrench turtle) isn't picking up my Tesseract. The animation of the wrench moving is playing, so I think that something in either TE or OmniTools changed how the OmniTool works. Is there an anything in the code that can I can edit to fix this, or am I just setting my Tesseracts up wrong?

I didn't understand how to lock the tesseract I might start a new separate thread for my script. it's very similar to yours but it takes a slightly different approach to solve the same problem. I developed it to a point I can easily make it session persistent and if I add robustness it can handle the environment better . I personally dislike "wireless" things because I think they add too much complexity to the end user. Adding an extra turtle might be a good approach but it's also complex. I prefer simple programs with simple parameters :)/>

btw did you try breaking the locked tesseract with a pick? it should work and then you can get rid of that second turtle.

UNOBTANIUM, on 07 June 2013 - 07:21 PM said:

Even programs with session persistent can fail. If you are saving a variables before the turtle moves it should be 99% fine. But if the variable gets saved and the chunk gets unloaded right in that milisecond before the turtle starts moving the turtle messed up by one block. However it is the best way to do it for right now :S

If you save both before and after, you'll be able to narrow it down to a smaller window of potential failure. Either way, since snap & box follow so closely you should be able to use them to tell if your move/turn succeded.

The problem with session persistent programs is mainly on servers . What happens is that the server save of the turtle position is usually older than the file save on the turtle. This cause the turtle to think it's more ahead than it actually is . in unobtanium's tree cutter that caused the turtle to sometimes dag down more than it should especially when it crashed when going up the tree . That caused the turtle to read a counter with unsaved progress and continue going up the tree .

in this program session persistent may be ok because what would happen is that the program would mine less than it should.

in this program session persistent may be ok because what would happen is that the program would mine less than it should.

That's true. Wouldn't be a big deal in this case ;D

If you save both before and after, you'll be able to narrow it down to a smaller window of potential failure.

How should that work either? In this case you have doubled the amount of variables safed. In my eyes that has more potential to fail :P/>
It is allways better to use as less variables as possible.

in this program session persistent may be ok because what would happen is that the program would mine less than it should.

That's true. Wouldn't be a big deal in this case ;D

What if the turtle was in the middle of a turn for the spiral option? Snap could end up going a different direction than box. But since you have two turtles to work with, you should be able to figure out if you turned based on what side the redstone signal comes from.

If you save both before and after, you'll be able to narrow it down to a smaller window of potential failure.

How should that work either? In this case you have doubled the amount of variables safed. In my eyes that has more potential to fail :P/>
It is allways better to use as less variables as possible.

The bit it helps with is if you have the after save, you know for sure you made the move. If you have a before but not an after, and you don't have a way to determine if you moved our not, for some programs it might be better to bail than take the chance that you carry on doing the wrong thing. And it's not necesarrily more variables, it's just more states. Instead of just a "I meant to move, but maybe didn't state" you get a "I really did move" state (although the "I meant to move" state is still there, but hopefully it won't be that common). KISS is good, but keep in mind the simplest program is "exit()". :)/>

In this case since you have two turtles to work with, and they're within a block or two of each other, you should be able to use their positions to figure out if you moved or not, so you probably don't need the extra save.

You have to understand this about turtles:
If the turtle moves forward, it shows us a smooth animation. But what really happens is, that the turtle moved allready when starting the animation. That means in real the turtle teleports, but shows us the moving animation and after this animation is finished it goes on with the next command in the program.
Most of the time the turtle will shut down while making these animations. That's why you should save the position (the one after it moves) before.
It is really just the millisecond after saving the new position into the file and the start of the animation. Saving it afterwards wouldnt change anything, it would make it even more difficulty to set up.

UNOBTANIUM, on 10 June 2013 - 10:03 AM said:

You have to understand this about turtles:
If the turtle moves forward, it shows us a smooth animation. But what really happens is, that the turtle moved allready when starting the animation. That means in real the turtle teleports, but shows us the moving animation and after this animation is finished it goes on with the next command in the program.
Most of the time the turtle will shut down while making these animations. That's why you should save the position (the one after it moves) before.
It is really just the millisecond after saving the new position into the file and the start of the animation. Saving it afterwards wouldnt change anything, it would make it even more difficulty to set up.

That's pretty much what I thought was happening, but I see what you're saying. For a lot of these programs, you'll end up saving your next move within a few millies, so little chance you program get's interrupted with with the after still saved instead of the next before.

ToLazyToThink, on 10 June 2013 - 09:50 AM said:

in this program session persistent may be ok because what would happen is that the program would mine less than it should.

That's true. Wouldn't be a big deal in this case ;D

What if the turtle was in the middle of a turn for the spiral option? Snap could end up going a different direction than box. But since you have two turtles to work with, you should be able to figure out if you turned based on what side the redstone signal comes from.

If you save both before and after, you'll be able to narrow it down to a smaller window of potential failure.

How should that work either? In this case you have doubled the amount of variables safed. In my eyes that has more potential to fail :P/>
It is allways better to use as less variables as possible.

The bit it helps with is if you have the after save, you know for sure you made the move. If you have a before but not an after, and you don't have a way to determine if you moved our not, for some programs it might be better to bail than take the chance that you carry on doing the wrong thing. And it's not necesarrily more variables, it's just more states. Instead of just a "I meant to move, but maybe didn't state" you get a "I really did move" state (although the "I meant to move" state is still there, but hopefully it won't be that common). KISS is good, but keep in mind the simplest program is "exit()". :)/>

In this case since you have two turtles to work with, and they're within a block or two of each other, you should be able to use their positions to figure out if you moved or not, so you probably don't need the extra save.

I originally had snap figuring out where box went via which direction the redstone signal comes from, but the problem is that the side with the chunk-loading module can't detect redstone signals (he could only turn left aka not an ambiturner) so I was forced to use a less elegant approach.

They should handle persistence through the turns (I think)

Niseg, on 08 June 2013 - 05:32 PM said:

I didn't understand how to lock the tesseract …

I'm running into this issue too.. Did you figure it out?

LazyNub, on 19 June 2013 - 09:11 AM said:

Niseg, on 08 June 2013 - 05:32 PM said:

I didn't understand how to lock the tesseract …

I'm running into this issue too.. Did you figure it out?

Yes , it's only possible in later versions of Thermal expansion. You have to right click the tesseract with pulverized shiny metal to have it work. I tried locking in FTB Ultimate but It didn't work. Maybe in a later FTB ultimate version it would work .If locking a tesseract doesn't work for you then you can use energy cells instead - I think they are locked by default.

I also wrote a script like this (posted on forum) but it doesn't use tesseracts so it should work with most versions of ftb. My goal was mainly rushing a quarry in ftb beta 1.52 because in this version turtles can break buildcraft pipes without destroying them. Gold conductive pipes are still very slow compared to energy conduits. Because my script requires lengths *width gold conductive/conduits it can become somewhat of a resource hog . Feeding it directly with engine is also a challenge I need to figure out.

Niseg, on 19 June 2013 - 09:49 AM said:

LazyNub, on 19 June 2013 - 09:11 AM said:

Niseg, on 08 June 2013 - 05:32 PM said:

I didn't understand how to lock the tesseract …

I'm running into this issue too.. Did you figure it out?

Yes , it's only possible in later versions of Thermal expansion. You have to right click the tesseract with pulverized shiny metal to have it work. I tried locking in FTB Ultimate but It didn't work. Maybe in a later FTB ultimate version it would work .If locking a tesseract doesn't work for you then you can use energy cells instead - I think they are locked by default.

I also wrote a script like this (posted on forum) but it doesn't use tesseracts so it should work with most versions of ftb. My goal was mainly rushing a quarry in ftb beta 1.52 because in this version turtles can break buildcraft pipes without destroying them. Gold conductive pipes are still very slow compared to energy conduits. Because my script requires lengths *width gold conductive/conduits it can become somewhat of a resource hog . Feeding it directly with engine is also a challenge I need to figure out.

Thanks for the information.. I couldn't find any info about it at all.

I have been looking at your solution as well.. I am looking for the "next level" of turtle based quarries beyond what the great AustinKK has done.

The cost in pipe does seem to be an issue.. But speed/cost trade off may not be as bad as it may seem.. Maybe a cheaper pipe is "fast enough"

to get going and once the resources roll in faster pipes can be made.

Thanks again for the help.

I think you can use a redstone energy cell in place of the energy tesseract pretty easily.

Psyestorm, since this relies heavily on the MiscPeripherals mod anyway, why not have an option to make the engineering turtle also configure the tesseract each time it sets it down. This removes the restriction of using this only on servers/packs that have the tesseract locking feature enabled/included. I know on my server there is no shiny metal dust, and platinum dust doesn't work on it. But I see in the MiscPeripherals API there are commands to set the frequency.

Just a thought, great program.

My understanding the setFreq() is for the sound block not anything else.

fusty, on 19 June 2013 - 12:27 PM said:

I think you can use a redstone energy cell in place of the energy tesseract pretty easily.

Psyestorm, since this relies heavily on the MiscPeripherals mod anyway, why not have an option to make the engineering turtle also configure the tesseract each time it sets it down. This removes the restriction of using this only on servers/packs that have the tesseract locking feature enabled/included. I know on my server there is no shiny metal dust, and platinum dust doesn't work on it. But I see in the MiscPeripherals API there are commands to set the frequency.

Just a thought, great program.

From what I understand (and I may be wrong) the tesseract API is part of the not part of the version currently in ftb ultimate. Any new version of ftb with Misc Peripherals new enough for the API, would likely also be running the new version of thermal expansion which allows tesseract locking with shiny dust.

Also, I dont think turtles can set tesseracts to private so playing on a server, anyone who knows your frequency could leech your power. I think I'll probably keep the code the way it is unless turtles can set private mode. In which case I'll add it in.

I play ftb 1.52 with latest update and I can confirm shiney ore exists and works to lock the power tes.

Well all of that makes sense. Sounds good to me, can't wait until our server is on 1.5.2

Until then I'll just use redstone energy cells and periodically visit the mining operation to replenish things.

Thanks!

Make sure you set the tesseract before you add the dust once you add pulverized shiny dust you use a Omni tool or the thermal expansion hammer make sure you do not use a pickaxe or any other tool as it will destroy the link and the use of the dust and you will have to add another. Also you will need to make the mystical plinth and forge lexicon to change the dust back to pulverized shiny dust from platinum dust if you have gregtech installed.

With 1 energy cell you can run about 19x19 not including the fuel use of the turtle. Psyestorm can probably add handling of redstone energy cubes using ender chests or what not to move them around. there is a way to calculate when the cell is almost empty.


I had plans to use a slave engineering for my script but i found that when the engineering turtle is placed by another turtle it won't startup unless a player right click it :(/> . I then tried to find a way to control the engineering turtle with redstone but I decided not to rewrite ;)/> this script. In the process I found how to improve this script by using 3 wells. My solution of choice was 3 mining wells with a tesseract in the middle ,ender chest above the tesseract and 3 golden transport pipes around it over the mining wells (will not work in 1.47 packs like ultimate) . Using the energy conduits at the top will not really work because the ends are 1 directional and you have to whack them with a wrench to make it output.

I also found something unusual with engineering turtles. if a mining turtle drop into an engineering turtle inventory it seems to work but when the engineering turtle does the dropping it doesn't work. The solution I used in my eventual engineering turtle script ( I have to move energy conduits around) was that the mining turtle would suck the energy pipes out of the engineering turtle's inventory.

misc peripherals only keep the chunks loaded in the world that has a player in it the chunkloader is basically like a player in the world.

Kravyn, on 27 June 2013 - 04:41 PM said:

misc peripherals only keep the chunks loaded in the world that has a player in it the chunkloader is basically like a player in the world.

Is there anyway around that like a config option or something else. currently I am using a chunkloader from chickencore

Darn. Looks like we are on an older version of CC on my server, so we don't have the redstone.setAnalogOutput calls. I guess I will try with the older snap and box.

Awesome!

i am having a problem where turtles are not keeping the right items in the right slots. snap stops picking up the teseract, and box starts to put cobblestone down and sometimes even spits out the enderchest..

Could you make it possible that the turtles also have a worldanchor? or atleast place one ever X chunks so they remain loaded so we can leave them alone?

Great script! Works like a charm….

One question, is there any way to add a check for a certain block type that when found will stop the mining?

I'd like to be able to check for mossy coble or stone brick, that way if a dungeon or stronghold is found I can go and check things out without worrying about any chest's being destroyed.


Keep up the good work….


Thanks,
Grinch…….

People should note there have been major changes to buildcraft but it doesn't effect this script muchl except for the fact you have to provide the mining well with 60Mj/block instead of 25Mj/block . Only scripts that use 3 mining wells are affected because a tesseract even after the TE update can only push about 80MJ (maybe 100?) while 3 wells pull 180Mj/t . I don't think they change redstone conduits except for removing the energy loss so a script like direwolf's will be slower.

There is another adverse change that will effect this script in terms of energy consumption . Mining wells seem to have change to keeps consuming energy at max rate even if it hits bedrock. I'm not sure if that's intentional but if you keep it connected for too long it will be pulling extra power.

grinch843, on 01 July 2013 - 11:34 AM said:

I'd like to be able to check for mossy coble or stone brick, that way if a dungeon or stronghold is found I can go and check things out without worrying about any chest's being destroyed…….

It can be done if someone puts their mind into it because the turtle sees what the mining well is pulling from the ground.

grinch843, on 01 July 2013 - 11:34 AM said:

Great script! Works like a charm….

One question, is there any way to add a check for a certain block type that when found will stop the mining?

I'd like to be able to check for mossy coble or stone brick, that way if a dungeon or stronghold is found I can go and check things out without worrying about any chest's being destroyed.


Keep up the good work….


Thanks,
Grinch…….

Someone could certainly add this to the code in their worlds, but I don't think its a feature I would add to the primary fork. I'm trying to keep them focused on the primary goal of mining. If someone were to implement this, I would probably put it in the emptyInventory function. I would have it stop at emptying at slot 14 and then have a mossy cobble and a stone brick in the last 2 slots. Then as you're dropping the items, compare it to the items in slots 15 and 16 and if they match then stop the program.

not sure if its a bug with 0.8 152wgt but "box" wont empty its inventory except slot 1 and 2 and when it does it just dumps everything onto the ground

catdog13, on 04 July 2013 - 12:09 AM said:

not sure if its a bug with 0.8 152wgt but "box" wont empty its inventory except slot 1 and 2 and when it does it just dumps everything onto the ground

I'm guessing your world has fuel turned off. There was a bug with the code where box would do this if you had fuel off. If you have automatic updates on in my launcher you should get the update as soon as your server restarts or if you reboot snap/box. If not, just delete and re-download and it should be fixed.

-Psye

grinch843, on 01 July 2013 - 11:34 AM said:

Great script! Works like a charm….

One question, is there any way to add a check for a certain block type that when found will stop the mining?

Turtles can't tell what something is, they can only compare it to another item; this means if you want to make a turtle dump all cobble it mines it needs to always keep one piece of cobble in its inventory to compare everything else to. To detect mossy cobblestone you would need the turtle to keep a piece of mossy cobblestone in its inventory and compare everything else to; not impossible, but more work than just updating the code.

it would be nice if you could add a check to make sure the turtle is actually responding sometimes the signals are too fast that the other turtle does not receive it. Is there any way to can make it so if it does not get a signal from its partner to send the signal again? …… With a delay each time of course.

The box turtle seems to get stuck at the point after it does sending ….. once you see waiting for # sometimes it freezes up and is unable to continue…..

its tied to the same problem some people have had where it does not empty it is waiting at the "Waiting for #"

I have to force restart the box turtle for it to realize its not actually waiting anymore. using CTRL+R

I added a msg print after the os redstone pull and I noticed it gets stuck on sending 5 waiting for 5 the most the msg I added to the snap told me thats the location it was hitting the problem is it did post twice but it said 0 then 0 instead of 5 and 5 so it forgets to cPowerUp=5 so it can continue.

after this code which is on line 154 I added

local msg=redstone.getAnalogInput("front")

to snap was this to line 155 - 157

if settings ["debug"]==true then
   print("Redstone strength on front: " ..msg)
end

at every attempt to change the code it would lock up at a different place I'm trying your older code but it does not have a way to tell the turtle to
stop.

I have attempted to add delay to the code but as I said it would lock up at those locations.

if your made your old code using normal wireless turtles with a chunkloader nearby then it would not have a problem all it needs is the ability to mine in a more compact area instead of straight line. like the newer code has.

this is from your launcher version. of snap/box

Kravyn, on 21 July 2013 - 09:57 AM said:

it would be nice if you could add a check to make sure the turtle is actually responding sometimes the signals are too fast that the other turtle does not receive it. Is there any way to can make it so if it does not get a signal from its partner to send the signal again? …… With a delay each time of course.

The box turtle seems to get stuck at the point after it does sending ….. once you see waiting for # sometimes it freezes up and is unable to continue…..

its tied to the same problem some people have had where it does not empty it is waiting at the "Waiting for #"

I have to force restart the box turtle for it to realize its not actually waiting anymore. using CTRL+R

I added a msg print after the os redstone pull and I noticed it gets stuck on sending 5 waiting for 5 the most the msg I added to the snap told me thats the location it was hitting the problem is it did post twice but it said 0 then 0 instead of 5 and 5 so it forgets to cPowerUp=5 so it can continue.

after this code which is on line 154 I added

local msg=redstone.getAnalogInput("front")

to snap was this to line 155 - 157

if settings ["debug"]==true then
   print("Redstone strength on front: " ..msg)
end

at every attempt to change the code it would lock up at a different place I'm trying your older code but it does not have a way to tell the turtle to
stop.

I have attempted to add delay to the code but as I said it would lock up at those locations.

if your made your old code using normal wireless turtles with a chunkloader nearby then it would not have a problem all it needs is the ability to mine in a more compact area instead of straight line. like the newer code has.

this is from your launcher version. of snap/box

I am having the same issue. I will try to dig it up a bit more to see what's going on in there and try to resolve the issue

BTW earlier on another world when I was having the same issue, I just placed a chunk loader nearby and that seemed to resolve the issue so I thought it might have been some issue with the chunkloader module.

Hey, this program is great! I'd honestly still prefer Frame Quarries since they're more efficient energy-wise (i.e., you can use Power Converters and a Liquid Tesseract instead), but with the absence of RP2 in 1.5+, this program fills the void quite nicely.

FYI, using shiny metal isn't required. With OpenPeripherals you can just use the Tesseract as a peripheral and use setFrequency(). More info can be found here.

There seams to be a fixed timer for how long the well runs for. This is great but for higher placements of the turtles say 80-100+ from bedrock the timer is too short and they miss a whole bunch of materials near bedrock. Consequently this is where diamonds are! Would it be possible to add in a question as to the turtles height when first running the program as to change this timer. Maybe just ask whether the delay should be short (eg only mining diamond level) normal or high (eg 130ish).

The only problems with stopping I have encountered are when snap and box seam to be one brick apart and have blank screens on one or both of them. I assume this is somehow due to charging themselves not working. For those who are having this issue and maybe others as well you can manually refuel the turtles with a ridiculous amount of fuel before running the program and you shouldn't have to worry about them for many days/weeks.

I have used frame breakers and frame quarries and have managed to crash the server with them quite a few times, sometimes permanently. This method of mining has not had nearly any impact on performance of the server since it is so simple and the only blocks that move are the turtles themselves which seam to have better/safer code.

Such an awesome program thanks heaps!

i have a problem i download programs for snap and box and after 1 block of movement snap and box are completly stuck donșt move donșt do anything if is a newer version please let links to them becouse i don't have internet conection on my pc becouse i am at my grandparents and i use only from mobile i realy like the program :D/> keep working on it

I love it already but do you think there is a way you could have more than 1 snap per box?

Great turtle program. Love the auto update and resume functionality.

I had a couple of issues. The first was the blanket 5 secs sleep to wait for mining. With lots of things requiring power all the time this often wouldn't be enough. So I updated the code to sleep for 5 seconds then check the number of items in the inventory. If it was still changing give it a bit more time. Here are the code changes

231a232,248
> function getInventoryCount()
>	 local count=0
>	 for i=1,16 do
>		 count = count +turtle.getItemCount(i)
>	 end
>	 return count
> end
>
> function waitForMining()
>	local count = getInventoryCount()
>	sleep(5)
>	while (count ~= getInventoryCount()) do
>	  count = getInventoryCount()
>	  sleep(2)
>	end
> end
>
375a393,395
>		 setNextStep("waitformining")
>	 elseif nextStep=="waitformining" then
>		 waitForMining()
377d396
<		 sleep(settings["miningTime"])

Also on resuming I noticed that sometimes if the chunk had been unloading as the turtles were moving there would be a gap between snap and box and it would be stuck. A bit hacky but I added a turtle.forward() to the beginning of snap.

Dybuk

You left the updated pastebins out of your main post. Can you add them please. :)/>

kreezxil, on 09 September 2013 - 02:57 PM said:

You left the updated pastebins out of your main post. Can you add them please. :)/>

They are in the video he made, I used it yesterday. I'm at work now, so can't type them for you.

Oh, and thanks for a great program psyestorm!

IS there any way to use this with 1.6.4 and TE3? I have tried to use it with the new tesseracts and it does not work. Two things seem to be happening, 1) the tesseract is not powering the mining well when next to it, 2) the crescent engineering turtle does not pick up the tesseract and have it retain its settings. With the new TE3 tesseracts shiny metal does not keep the settings for the tesseract anymore.

cormoo, on 20 December 2013 - 04:25 PM said:

IS there any way to use this with 1.6.4 and TE3? I have tried to use it with the new tesseracts and it does not work. Two things seem to be happening, 1) the tesseract is not powering the mining well when next to it, 2) the crescent engineering turtle does not pick up the tesseract and have it retain its settings. With the new TE3 tesseracts shiny metal does not keep the settings for the tesseract anymore.

Don't quote me on this, but I think that tesseracts saving settings hasn't been implemented yet, and tesseracts will only transfer Redstone Flux, while the mining well needs MJ. You could verify these yourself if you want.

Can you make this program to work without enderchest, but with 2 teseracts: to object and energy? Sorry for my English-I am a Russian…

Very well done. I wanted to see a program like this! The code is nifty and well done. Nice :)/>

I've been watching the counter on that thread for a while and it seems like it is still being downloaded quite a bit even though the program is outdated and won't work on modern modpacks.

It is a very good program, but wrench turtles have been deprecated for a while now.

I entirely coded the program again to make it more efficient and up to date with the current versions, now that tesseracts can be picked up without a wrench and everything.

http://www.computerc...-box-revisited/