Please make sure you are posting in the correct place. Server ads go here and modpack bugs go here
The FTB Forum is now read-only, and is here as an archive.
To participate in our community discussions, please join our Discord! https://ftb.team/discord
I need a turtle logging program that won't get stuck or break when the server resets. Anyone know of a good one? I'd be willing to set up rednet or gps if need be.
I know that, but can't the program restart when the server comes back up?
The main problem is that the turtle has to move around, so if it's not in the right spot when the program restarts it gets stuck or ends up whacking something stupid
I know that, but can't the program restart when the server comes back up?
The main problem is that the turtle has to move around, so if it's not in the right spot when the program restarts it gets stuck or ends up whacking something stupid
Running it as a startup program just runs the code from the beginning, not where the turtle left off before the restart. That means the turtle's location and the code it's trying to run won't match up. This leads to all sorts of problems ranging from it just getting stuck and stopping to pickaxing something important such as chests or the side of your house
Running it as a startup program just runs the code from the beginning, not where the turtle left off before the restart. That means the turtle's location and the code it's trying to run won't match up. This leads to all sorts of problems ranging from it just getting stuck and stopping to pickaxing something important such as chests or the side of your house
The simplest way to achieve what you're asking is to make a logging script that saves its current action to the turtle's memory and use rednet GPS to determine location relative to "home", and make that script the startup script. That way if it wakes up from server (or internal) reboot and sees "huh, I was cutting a tree... let's look in front of me and above me and see if I finished." or "I was finished and on my way back down but I'm... not at start? I should go there." and resumes operation.
slot 16 = cobblestone
slot 2 = birch tree log (or any log you want to harvest from a 1x1 tree with no branches
slot 1 = saplings
make this the turtles startup program
goingUp = true
while true do -- forever loop
turtle.select(16) -- Select the cobblestone to see if it's above or below us
if turtle.compareUp() then -- If cobble is above is, we're going to be going down
goingUp = false
end
if turtle.compareDown() then -- if cobble is below us, we're going to be going up
goingUp = true
end
-- now let's check out what's in front of us.
turtle.select(2)
if turtle.compare() then
--woot, something to chop down! Wood!!!!
turtle.dig()
end
-- Now let's see if we need to plant a sapling
turtle.select(16)
if turtle.compareDown() then -- we're on the ground
turtle.select(1) -- sapplings
if not turtle.detect() or turtle.compare() then -- there is empty space in front of us or a sapling
turtle.place() -- plant a sapling, or fail trying to plant a sapling
-- Let's wait for a tree to grow ... even if we grow old and die
turtle.select(2)
while not turtle.compare() do -- yeah, while it's not a log ... we're just gunna wait here for a long time.
sleep(10) -- snore
end
end
end
turtle.select(2) -- select the wood slots and let's get chopping or moving
-- If we got to this point, we're somewhere in the middle of our process and need to dig up or down.
if goingUp then
turtle.digUp() -- clear any stupid leaves in our way. Also because we check for cobble before digging (going up going down) we don't need to worry about destroying cobble
turtle.up()
else -- going down!!!
turtle.digDown() -- because we check first to see if we're on the cobble before digging ... we can't destroy the cobble even if we're armed with a pickaxe
turtle.down()
end
end
Now, mind you - that code isn't tested but it's a concept. It doesn't have a fuel mechanism. It doesn't store the wood or get saplings.
Also cobblestone was a poor decision, in thinking about it ... a chest would be better at the top to store the wood.
At the bottom probably use another chest filled with saplings (pipe them in using water directing the saplings to a collection point to the chest.) In the routine that plants the sapling you can have the code use turtle.select(1)--saplings, turtle.suckDown() (get some saplings).
Might also want to have a cleanup routine that cycles through all the slots for getting stuff and dumping them out to the chest at the bottom or the top.
--At bottom
for i=3,15 do
turtle.select(i)
if turtle.compareTo(1) then -- It's a sapling not in slot one
turtle.dropDown() -- put it in the chest below us
end
--At Top
for i=3,15 do
turtle.select(i)
if turtle.compareTo(2) then -- it's a log not in slot 2
turtle.dropUp() -- put it in the log chest above us
end
... Sorry for bad code, I suck at code without some coffee but it's too late to get some tonight.
Anyhow, the idea is - no matter where in the cycle you lose power/server resets ... the code just makes assumptions about where it is in the cycle and carries on based on that.
Also you could try to use bonemeal if you want to speed up tree growth ... but I'd probably use a lilly pad of fertility near it ... and since turtles are cheap, I'd not just make 1 of these turtles but probably 4-5 of them.
You need a program that updates based on the turtles positioning. I hear of people using GPS. Based on the turtles current coordinates and the start coordinates of the mining location (as a reference) know where in the mining cycle you are. I am assuming that you will be having a fairly redundant mining cycle or else I don't know how else to do it.
The simplest way to achieve what you're asking is to make a logging script that saves its current action to the turtle's memory and use rednet GPS to determine location relative to "home", and make that script the startup script. That way if it wakes up from server (or internal) reboot and sees "huh, I was cutting a tree... let's look in front of me and above me and see if I finished." or "I was finished and on my way back down but I'm... not at start? I should go there." and resumes operation.
That's one way to do it, and I think the key that makes 'recovery' after a server restart possible is that your turtle has a 'hard drive' just like a computer does, and a file system API (search 'Fs (API)' on the wiki) that allows a person to make use of it. You could use the rednet GPS system as you described, or you could use a simple relative coordinates system. The key is that you update a save-state file on the turtle's hard drive after every action. Turtle moved? Update the file. Turtle turned to face a new direction? Update the file. Turtle chopped something? Update. Tiny file, relatively simple system to implement, and accurate maintenance of relevant data that will allow the turtle to pick up where it left off. It's just up to the user (writer) of the code to determine what they want to track and how to represent it so that the server could shut down at any time and the turtle can pick up where it left off when the server comes back up.
The simplest way to achieve what you're asking is to make a logging script that saves its current action to the turtle's memory and use rednet GPS to determine location relative to "home", and make that script the startup script. That way if it wakes up from server (or internal) reboot and sees "huh, I was cutting a tree... let's look in front of me and above me and see if I finished." or "I was finished and on my way back down but I'm... not at start? I should go there." and resumes operation.
you can't keep track of the turtle's location by writing to a file.
Writing to a file is almost instantaneous, and by comparison moving or turning takes much longer. if the server restarts while the turtle is moving then when it restarts it will write an incorrect location to the drive.
I was going to try a simple workaround with a compass turtle, but getFacing() doesn't seem to return any value. The error I get is "Attempt to call number"
you can't keep track of the turtle's location by writing to a file.
Writing to a file is almost instantaneous, and by comparison moving or turning takes much longer. if the server restarts while the turtle is moving then when it restarts it will write an incorrect location to the drive.
I was going to try a simple workaround with a compass turtle, but getFacing() doesn't seem to return any value. The error I get is "Attempt to call number"
This is why I suggested using rednet for position and otherwise using FSM behavior, writing state, etc. You can expand the state recovery with sanity checks as needed, but you're not trying to rely on it for anything other than an idea of what you were last doing, as a way to get close to where you were and get back on track.
On the compass work, are you wrapping the compass?
Code:
m = peripheral.wrap("right")
m.getFacing()
returns 2 for me with a compass turtle, while facing north, same as F3.
Also, if the server restarts while the turtle is moving, on my server that obliterates my turtle entirely, leaving me with an empty inventory turtle. count yourself lucky if you get to keep your moving turtles past reboots.
you can't keep track of the turtle's location by writing to a file.
Writing to a file is almost instantaneous, and by comparison moving or turning takes much longer. if the server restarts while the turtle is moving then when it restarts it will write an incorrect location to the drive.
I was going to try a simple workaround with a compass turtle, but getFacing() doesn't seem to return any value. The error I get is "Attempt to call number"
You can keep track by writing to a file. You don't write a new location until the move is finished, so if the move doesn't finish (restart), the turtle will boot up to a save state file saying basically, "I was at x, y, z facing <d> direction and about to move <m> direction" as the last recorded state. Unless CC registers a turtles' final position as the turtle starts to move, the turtle should be back where it started before the restart, not in the new location. And if it turns out CC does update the turtles' new location as soon as it starts to move, that can be accounted for in the script as well. Writing updates to disk is what allows the user to keep a record of what is going on that persists through game restarts. How to interpret and use that information is up to the user based on their needs and observations.
you can't keep track of the turtle's location by writing to a file.
Writing to a file is almost instantaneous, and by comparison moving or turning takes much longer. if the server restarts while the turtle is moving then when it restarts it will write an incorrect location to the drive.
Write the file after the move command returns. As you said, writing is almost instantaneous, so hitting the race condition of <after move> and <before write> is so remote - and the circumstances so non-critical - that it shouldn't even be coded around.
Write the file after the move command returns. As you said, writing is almost instantaneous, so hitting the race condition of <after move> and <before write> is so remote - and the circumstances so non-critical - that it shouldn't even be coded around.
As far as I can tell, the race condition would actually be <after move initiation> and <before write>. This would include move time, as the turtle's location is changed at the start of the movement. This move time is not inconsequential and coding for it may be appropriate.
Or write to the file directly before the move, changing the race condition to <after write> and <before move>.
I made a rather brutish program that did this. Basically, on server restart the turtle would go forwards until it reached a colored xycraft block to determine what direction it was facing, then it would make it's way to a specific corner based on what color block it was facing and then navigate back to the start of the farm from that corner. I'm not a good coder, these solutions look so elegant D:
I made a rather brutish program that did this. Basically, on server restart the turtle would go forwards until it reached a colored xycraft block to determine what direction it was facing, then it would make it's way to a specific corner based on what color block it was facing and then navigate back to the start of the farm from that corner. I'm not a good coder, these solutions look so elegant D:
Yeah, I was trying something similar out where the turtle took it's heading with a compass and then "felt" around it's environment by moving around attempting to find where it's supposed to be based on multiple different starting positions. Eventually I slipped up somewhere and the damn thing flew off. never did find the little dude
Newbie tip: code your original programs on a computer and then transfer them over to turtles.