This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Javatech's profile picture

Help locating lost wireless mining turtles

Started by Javatech, 18 January 2013 - 10:13 AM
Javatech #1
Posted 18 January 2013 - 11:13 AM
lastnight I set my 3 turtles to flatten a 64x64 area around me, dug 3 down, put my chunk loader above my head and went to bed.

This morning I could only find 1 of them. I have no idea what could have happened to them, I have looked all over the place but have had no luck. Could someone help me have them do a GPS Locate then save their location to a text file? I've tried this http://www.computerc...how-to-find-it/ but that doesn't seem to work at all. Currently I have rednet set to broadcast t512 meters to help find them easier. Thanks
jewelshisen #2
Posted 18 January 2013 - 11:27 AM
Do you know their id numbers?
ChunLing #3
Posted 18 January 2013 - 12:03 PM
The other thread suggested putting down a rednet logging computer to enable you to get the messages back. What was the output on that computer?
Javatech #4
Posted 18 January 2013 - 12:14 PM
Do you know their id numbers?

1 and 5

The other thread suggested putting down a rednet logging computer to enable you to get the messages back. What was the output on that computer?

That code errors, and trying it with another turtle sitting next to me gets no results.
ChunLing #5
Posted 18 January 2013 - 12:57 PM
Hmm…looking at it, I can see it wouldn't quite be what you need anyway, but I'm not seeing where it errors. Here's a slightly modified version to try:
rednet.open("top")--Or whatever side your computer has the modem on
rednet.broadcast(" ")
repeat
  local id, message,distance = rednet.receive(2)
  print(id,": ",message,", from ",distance)
until not id
Also, for the turtles you can use:
rednet.open("right")
local id = rednet.receive() --Wait for a message
local x,y,z = gps.locate(1)
rednet.send(id, "I am at: "..x..","..y..","..z)
Edited on 18 January 2013 - 12:02 PM
Javatech #6
Posted 18 January 2013 - 04:34 PM
Ok, I put that script on all currently deployed turtles… I am very sad to report that all but the two missing ones report in. But the scripts work flawlessly, Thank you.

I don't understand how two turtles can just vanish without a trace.
ChunLing #7
Posted 18 January 2013 - 08:29 PM
Hmmm…okay, time to see the code you were using on the turtles that vanished.

Also, how big is the chunk loader radius? And is it possible that someone just stole them?
Edited on 18 January 2013 - 07:29 PM
Javatech #8
Posted 18 January 2013 - 08:48 PM
Hmmm…okay, time to see the code you were using on the turtles that vanished.

http://pastebin.com/aYeeMz0J

ChunLing said:
Also, how big is the chunk loader radius?

'4' or 49 chunks 4 3 2 [1] 2 3 4

each was doing a 32x32 area for a 64x64 centered on me and the chunk loader

ChunLing said:
And is it possible that someone just stole them?

No, private 4 - 6 person server and no one had logged in while I was asleep
Luanub #9
Posted 18 January 2013 - 09:08 PM
Is it possible that 1 turtle destroyed the other 2?
Javatech #10
Posted 19 January 2013 - 12:43 AM
Is it possible that 1 turtle destroyed the other 2?

I wish I could say no for certain, but at this point I have no idea and probably never will. It's just a shame #1 was lost, it was the first one I had ever built.
ChunLing #11
Posted 19 January 2013 - 03:18 AM
What version are you on? I recall that on some older version, there was the infamous leaf replacement bug, where tree growth could destroy turtles. The code is a little clunky, but looks solid. I don't really see it letting the turtles go wildly off course, but if you were to upuntil() a tree trunk, you could end up being vulnerable to another tree growing nearby. Particularly if the turtle upuntil() a very large tree.
Javatech #12
Posted 19 January 2013 - 10:03 AM
I am on the latest build of FeedTheBeast client and server. As for the code, I am always open to suggestions for improvement, this so far is doing a decent job of clearing an area. It handles gravel and small gap/overhangs.
ChunLing #13
Posted 19 January 2013 - 03:08 PM
I can see a scenario where a tree growing (or even just a mob) threw one of the turtles off course, causing it to eat another turtle and then be subsequently eaten by the last remaining turtle. If the last turtle had a full inventory when that happened, it could result in both the other turtles being dropped as items and lost after five minutes. There are ways to make the forward movement function robust enough to virtually ensure that sort of thing can't happen in the future.

For now, I'm going to suggest that you replace:
if turtle.detect() then
  repeat
   turtle.dig()
   sleep(0.5)
  until turtle.detect() == false
 end
with
while turtle.detect() do
    turtle.dig()
    sleep(0.5)
end
Functionally this is almost identical but much easier to read.
Javatech #14
Posted 19 January 2013 - 11:04 PM
I just tried that out, ended up making the turtle go way off course. I selected a large area to clear to test it.. "Flat 60" after it dug 10 blocks I stood in front of it, the turtle immediately turned around and went back 60 blocks and tried to start digging there. Luckily I had my jetpack on to beat it there or it would have ate my house.
ChunLing #15
Posted 20 January 2013 - 04:29 AM
The standard "mob proof" forward looks something like:
local function forward()
    while not turtle.forward() do
        turtle.dig()
    --    turtle.attack()
    end
end
Having the turtle attack when it can't move is optional, and not something you want to test by standing in front of it.
Javatech #16
Posted 20 January 2013 - 05:13 AM
Thanks, I will try that out. I was just pointing out that the code you posted made it run massively off course, while beforehand it would either start a new row in the proper location or if it couldn't come down all the way would just continue on above the obstruction.
ChunLing #17
Posted 20 January 2013 - 09:15 AM
Odd. The code I posted should have been materially-equivalent to the code it replaced in terms of function. The same function calls and conditionals all occur in the same order. There is nothing about the code it replaced that would have prevented a mob throwing the program off-course in the same manner.