[Lua] Yet another turtle miner/tunneler question (shell.run with variables)

Minecraft Version: 1.2.5
CC Version: 1.4

Background: I've been working with CC based Lua for about 2 months (probabily more) but believe me I am by no means a pro or a genius with Lua and I've finally gotten to a point in my coding that I can run my miner and tunneler programs almost perfectly.

But I've also hit a brick wall (not my first by any means). Normally I can find the answer to a problem I'm having on the CC forums without any trouble, but this one I can't find an answer to. I've encountered a problem while trying to run a GPS goto program (Direwolf20's goto program to be precise) in a shell.run() operation.

In my program you place the turtle down in front of a chest and when you run the program for the first time it stores the xyz coordinates in a variable (That part works). From here the program runs and it fills up the turtle's internal inventory. Once the turtle's inventory is full it is supposed to go back to the coordinates it stored that where next to the chest and drop the items. This is where I am having the problem. I can't get the variables to run as arguments in the shell.run() script.

Below is a test program that I am using to test the shell.run() and goto program in tandom.

function gpsFind()
   return gps.locate(1)
end
local x, y, z = gpsFind()
print(gpsFind())
for i = 1, 2 do
   turtle.forward()
end
shell.run("goto", "..x..", "..y..", "..z..")

I will later take this program (once it works) and make it a function within the miner/tunneler program.

Direwolf20's goto program:
http://pastebin.com/hz6y4ift

My currentTunneler program:
http://pastebin.com/4Sg8MPcS

Any and all suggestions are welcome. I'm always open to improvements to my code.

shell.run("goto", tostring(x), tostring(y), tostring(z))

Your essentially running before:

goto ..x.. ..y.. ..z..

Okay, thanks to zekesonxx now the goto program works, but now it's storing the variables incorrectly.

When I run the below program it does not output the correct variables.

function gpsFind()
   return gps.locate(1)
end
local x, y, z = gpsFind()
print(gpsFind())

for i = 1, 10 do
turtle.forward()
end
turtle.turnLeft()
for i = 1, 6 do
turtle.forward()
end
–shell.run("goto", tostring(x), tostring(y), tostring(z))


When I run the "gps locate" program it outputs that it is at 82, 71, -321 but when i run the above program, it output's 7761-319. If i move it 2 blocks south (using "go forward 2") it says it's now at 7661-317.

I also need to run "gps host" before this program runs to get it to even use the goto program, if I don't it just error's out saying x y z must be input, same goto program as before. I would like to be able to take this step out or some how integrate it into the program.

Last time I ran this program it ended up 4 blocks east of where it started.

lol. First of all, zeke, shell.run() uses strings in the shell, so tonumber there is pretty obsolete.

geech; Try changing print(gpsFind()) to print("X: "..x.." Y: "..y.." Z: "..z). Your problem is the variables returned from gps.locate() are plain numbers. And so there is no space inbetween. 76 61 -317 is the correct position, am I right? Just add them spaces in ;)/>

I really don't care how it prints the vairables, I can read them either way. It just prints them out for me to see if they are being stored correctly.

The problem is is that the variables aren't getting stored correctly.

geech, on 02 January 2013 - 10:40 AM said:

When I run the "gps locate" program it outputs that it is at 82, 71, -321

Which I might add is the correct location for the turtle.

geech, on 02 January 2013 - 10:40 AM said:

but when i run the above program, it output's 7761-319.

Which means 77,61,-319.

I also tried your solution earlier and it outputted an error, I should have posted that I tried that, my bad.

try bumping up the timeout on gps.locate, so change that 1 in the parentheses to a 20 or something

Doyle3694, on 02 January 2013 - 01:09 PM said:

lol. First of all, zeke, shell.run() uses strings in the shell, so tonumber there is pretty obsolete.

tostring(). x y and z are numbers. I'm just preventing any errors that might arouse.

zekesonxx, on 03 January 2013 - 03:30 AM said:

Doyle3694, on 02 January 2013 - 01:09 PM said:

lol. First of all, zeke, shell.run() uses strings in the shell, so tonumber there is pretty obsolete.

tostring(). x y and z are numbers. I'm just preventing any errors that might arouse.

I actually agree here, although I would have the number checking happening earlier and safely erroring if NaN vs the error that would occurs there, of course that could also be mitigated with pcall

Bumping up the timeout on gps locate didn't do a thing, this time it went 6 blocks to the east.

The gps coordinates throughout this entire test are as follows:
78,71,-321 - at the pre execute gps host (that needs to be run so that the goto program can work)
71,61,-318 - before the movement phase of the test program (THE TURTLE HAS NOT MOVED YET)

The program hasn't even executed the goto program or moved from it's original location yet, how are these varaibles different?

77,72,-318 - after the goto program has completed and the program has exited (where the turtle thinks it ended up)
83,71,-321 - These are the actual coordinates of where the turtle ended up

I think it's storing the variables from a previous run and not clearing them. Is there a way to clear specific variables at the end of a run, OR before the program has run?

Hmmm…. I may have just fixed it…

I'll do a little more testing, but it seems someone may have setup an incorrectly coordinated gps tower near the one I'm testing at.

You have got to understand that you have to doublecheck the physical stuff before coming here asking what the error in your code is.

It was not my GPS tower to check, someone else built it therefore it was someone else's to maintain.

And it's broken again…. It's not sending the gps coordinates to the goto program again…

I'm gonna step away from it for a while. The updated tunneler program is in the original post.

The only annoying part is that I have to run the gps host program before I run the tunnel program.

Is there something I'm doing wrong with my entire program that I need to type gps host every time before the program runs, or is it a thing that I have to do every time?

And if it is a thing that I have to do everytime then is there a way to run it inside the program then have gps host terminate itself but not the entire program it's running?

Um…I'm not seeing where you turn on your turtle's modem.

Okay, Thank you ChunLing for helping me with the annoying gps host before every run problem.

I'm still having the problem where it doesn't send the coordinates to the goto program from my tunnel program.

I just put the rednet.open("right") string into the test program I was using earlier and it seems to be working from there perfectly, but for some reason or another my turtle doesn't like that it has to do other things between the turtle finding it's location and using the goto program.

Here's my test program:

rednet.open("right")
function gpsFind()
   return gps.locate(1)
end
local x, y, z = gpsFind()
print(gpsFind())
for i = 1, 2 do
   turtle.forward()
end
shell.run("goto", tostring(x), tostring(y), tostring(z))

Again, the turtle tunneler program is updated in the OP.

And thanks again for the help everyone.

When you say your computer "doesn't like" doing things between getting the location and using goto, what do you mean? Is it not doing them, or is goto not running properly?

I'm not sure whether goto is not running properly or my program is sending the variables incorrectly.

When I run the turtle, the gpsFind() function runs and prints it's exact location before the turtle moves. After it moves and digs and does it's job it has a drop function that is supposed to execute if slot 2 has more than 1 item in it. The drop function executes when it's supposed to but when it gets to the line that is the shell.run("goto", tostring(x), tostring(y), tostring(z)) (which is supposed to send it to the gps coordinates it stored earlier) it says "Must supply X Y Z." (Which is the error code on line 112 of the goto program for no coordinates/incorrect formated coordinates have been supplied)). So the drop function executes and it drops the items in it's inventory where it is, and exits the program. Instead of going back to where it started where I or a chest will be waiting for the items.

The code for the error from line 112 of the goto program is below:

if not x or not y or not z then
   print("Must supply X Y Z")
   exit()
end

Hope that helps.

Hmmm…maybe not bother with changing the numbers tostring? I've never had any problem with using numbers as additional arguments in shell run calls, myself.

Also, just to be sure, print(x,y,z) just before you run goto.

Ok, I put the print(x,y,z) after the gps.locate (before the turtle moves) and before the goto (after the turtle moves) and the variables are still there, so the coordinates are being stored correctly as variables, they're just not being sent to the goto program.

I've done all the variations of sending variables to a in a string that I can think of.
shell.run("goto", ..x.., ..y.., ..z)
shell.run("goto", "..x..", "..y..", "..z")
shell.run("goto", tostring(x), tostring(y), tostring(z)) ***original and currently working in the test program***
shell.run("goto", x, y, z)

This is really starting to piss me off. It works in the test program every way but it won't work when I set it inside my tunnel program… WHY WON'T IT WORK!!!!!

EDIT: Could it be because the shell.run is inside an if statement inside a function? Must do some testing to find out…

EDIT #2: Nope I was wrong again, It's not because of the if statement, I just did used a simple if statement in my test function to see if the turtle was less than 200 on the y axis and then use the shell.run… needless to say, the shell.run worked…. I'm throughtly peeved…

Um…sorry, this is the first time I've actually looked at your tunnel program (the parts you were having trouble with before were encapsulated in your test program, so there wasn't a need).

The problem in the posted version is that you define drop() before you get around to declaring x,y, and z. Lua thus interprets this as calling upon three global variables with those identifiers, and presumes that you will fill the values later. All well and good, but when you do get around to assigning values to x,y, and z, you're not assigning them to the global variables that drop uses, you're declaring local variables with the same identifiers and assigning those the values. The global variables, x,y, and z are still nil.

You should be able to do a quick fix by removing the local keyword so that the globals (being used in drop()) get the values. But for a program that is going to be calling another program, using globals isn't best practice, eventually you'll want to fix that.

Ok, now it works, perfectly I might add. (I might get another goto program, it looks like this one sends the turtle to the surface when stuff is in the way)

The only problem with global variables is I'm playing on a server and using gobal variables is kinda dangerous. Expesically when I completely finish this as a branch miner (yea, I'm going there). I tried earlier to define the variables before the drop() function (I actually defined them where I defined all my other variables) but it errored out at the line where I defeined them.

No, globals are still local to the particular computer. They're dangerous because if you have a program that runs another program using shell.run then the global environment is shared, not because there is a chance of global usage affecting other computers (otherwise anyone could brick every computer by setting all the api function tables to nil).

Oh, well then!

YEA IT WORKS!!!

Now to inegrate the goto with my miner. Maybe I'll change my miner to bedrock up. Really wish I had chunk loading turtles in 1.2.5…

Kinda need to find another goto program though. Idk if it's just the one I'm using or this is the way they work, but my goto program tries to make sure there is nothing above it, so when it's mining at bedrock it goes up until it meets the surface then comes back to me (at bedrock).

Thanks for the help everyone, I'll post back if I find more problems.