Help Finding a Bug in My Advanced Orefinder

Its been awhile since I have worked with this program and the last time I did I left it with a few bugs. For the most part I have fixed all of them but I just found another and for the life of me I can't figure out were I when wrong, it been almost a year since I wrote the code.

Here's the bug:
When the turtle program is exited, opened back up, and resumed from the save file at hand. The Whole excavation area is moved one to four blocks too the left or right depending on what row its on, It also is still able to return to the chest and and empty its inventory even though its excavating the wrong area. But if the computer is rebooted instead then the excavation continues normally.

If anyone could help me with this bug it would be much appreciated.

Forum post for the program can be found here:
http://www.computerc...efinder-tunnel/
So that you can set it up correctly.

GitHub file can be found here:
https://github.com/H...vancedorefinder

If you have any questions please ask.

If the program is exited and the turtle is rebooted before running the script again, does it behave differently to if the program is exited and restarted without rebooting?

If the Turtle is rebooted before continuing then it works as intended. That would explain why I have never gotten the bug before. So from that information I'm assuming it has to do with the width and length variables not being set in the start of the program. Unless I set them to local then I'm sure that would work.

I guess I already am resetting the Variables at the start On line 716 would I have to change that to _tSave = nil from _tSave = {}

EDIT:
Nvm I just tested that and it still didn't work gonna continue testing.

EDIT:
I tried setting _tSave to local but the programs just breaks, never understood how local works. :)/>

--Program scope
varX = 0
local function derp() -- this function is only accesible within this program
  --this functions scope has acess to everything defined in the main program scope, but the main program does not have acess to anything defined as local within this scope.
  local varX = 2 -- this only aceesible from within derp and anything defined within derp. As such it is not the same as the previous varX, as it is in another scope.
end
derp()
print(varX) -- prints 0, as that is the only varX defined in this scope(the program)

To put it simply, local variables are only acessible within the scope they are defined. A good analogy is to think of them like boxes, where you have the biggest box(in the case of cc, this is the shell), then another box within that box(global scope), then another(program), and within that one (functions, loops, ifs etc.). Anything outside the box is acessible to everything within the box, the same does not apply in reverse however.
Note that if you use variables prior to defining them(within functions and such) then define them locally later, they will not be the same variable. As the one within the function will point to the global variable, while the one you defined locally will point to the variable within the scope it was defined.

This isn't something im very good at explaining lol, but hopefully you get the point.

Yea that helps Thanks, almost makes me want to reorganize my program.

But I guess that still wouldn't fix my problem

Anyone have any tips to find this bug?

Maybe it could help if you just use local variables and reload it after a run?
The problem seems to be not resetted variables
Edit
I THINK _ is mostly used for internal variables, so i wouldn't start a variable with it

_ is normally used for throwaway variables, like when a function returns multiple variables and you want the second one. The only exception to this would be _G and _VERSION i think, all the other internal variables use double underscores as far as i know. Also yes that is a very good point, all non-local variables will persist until you reboot. So if the issue only occurs on reboots, chances are it's related.

CometWolf, on 14 January 2014 - 09:51 AM said:

_ is normally used for throwaway variables, like when a function returns multiple variables and you want the second one. The only exception to this would be _G and _VERSION i think, all the other internal variables use double underscores as far as i know.

_ is just an ordinary variable name. It may be common to use _ as throwaway variable, but i dont think that it is a throwaway by convention.

double Underscore is reserved for metamethods, not internal variables ( http://lua-users.org...methodsTutorial ). The Lua Manual states this:

As a convention, names starting with an underscore
followed by uppercase letters (such as _VERSION) are reserved for internal global
variables used by Lua

so i just wanted to point this out, not that it is something wrong, but something that can cause hard to detect errors

Yea at this point the variable's with underscores are not causing any problems, I get that they are only used in certain cases and I'll fix that, but as far as I'm concerned it's a variable just the same as the rest.

I'm still getting the bug so if anybody has any ideas please tell me, I made the "tSave" variable local and I am unable to make the "_sFile" local without the program erroring out. Its still not making since because all the information gets pulled from a save file at the start of the program so none the variables should be keeping any residual data.

Moody, on 14 January 2014 - 12:28 PM said:

_ is just an ordinary variable name. It may be common to use _ as throwaway variable, but i dont think that it is a throwaway by convention.

double Underscore is reserved for metamethods, not internal variables ( http://lua-users.org...methodsTutorial ).

Right my bad, mixed up metamethods and internal variables. Sure it's a regular variable name like any other, but a strange choice…

Henness, on 14 January 2014 - 12:46 PM said:

Yea at this point the variable's with underscores are not causing any problems, I get that they are only used in certain cases and I'll fix that, but as far as I'm concerned it's a variable just the same as the rest.

I'm still getting the bug so if anybody has any ideas please tell me, I made the "tSave" variable local and I am unable to make the "_sFile" local without the program erroring out. Its still not making since because all the information gets pulled from a save file at the start of the program so none the variables should be keeping any residual data.

Hey, i tested it, and if i put

local tSave = {}

to the beginning of the code ( where you defined author and such), i think it works for me (although im not sure what it should not do)
Keep in mind that at the position where you declared, every tSave before was declared global, thus making it redundant (same with sSave - you probably declared it way down, so your main function tries to access the local sSave, whereas the function that should edit sSave edits the global variable)

Moody, on 14 January 2014 - 02:45 PM said:

Henness, on 14 January 2014 - 12:46 PM said:

Yea at this point the variable's with underscores are not causing any problems, I get that they are only used in certain cases and I'll fix that, but as far as I'm concerned it's a variable just the same as the rest.

I'm still getting the bug so if anybody has any ideas please tell me, I made the "tSave" variable local and I am unable to make the "_sFile" local without the program erroring out. Its still not making since because all the information gets pulled from a save file at the start of the program so none the variables should be keeping any residual data.

Hey, i tested it, and if i put

local tSave = {}

to the beginning of the code ( where you defined author and such), i think it works for me (although im not sure what it should not do)
Keep in mind that at the position where you declared, every tSave before was declared global, thus making it redundant (same with sSave - you probably declared it way down, so your main function tries to access the local sSave, whereas the function that should edit sSave edits the global variable)

I had already declared it as local in my testing right above the start of the program near the end of the file, I just moved that to the start of the file and the bug still there. :(/>

Does anyone have any clue why this is happening???

There are two possibilities; either the turtle knows the co-ords it should be going to but doesn't know where it currently is, or it knows where it currently is but doesn't know where it should be going to.

Given that rebooting the turtle seems to work fine, it presumably has something to do with the remaining unlocalised variables in the script (the contents of which stay loaded until the turtle actually shuts down, as opposed to when the script ends). Putting aside the functions, the ones I can see are:

ores_mined
tCordsInput
select
screenw
screenh
fuel_level
_sFile

Add the below to the top of the script, see if it makes a difference. If not, see if you can figure out some more details about what the turtle's getting confused over - put some extra print statements in so you can better see what it "thinks" it's doing, as it does it.

local ores_mined, tCordsInput, select, screenw, screenh, fuel_level, _sFile

Bomb Bloke, on 15 January 2014 - 12:06 AM said:

There are two possibilities; either the turtle knows the co-ords it should be going to but doesn't know where it currently is, or it knows where it currently is but doesn't know where it should be going to.

Given that rebooting the turtle seems to work fine, it presumably has something to do with the remaining unlocalised variables in the script (the contents of which stay loaded until the turtle actually shuts down, as opposed to when the script ends). Putting aside the functions, the ones I can see are:

ores_mined
tCordsInput
select
screenw
screenh
fuel_level
_sFile

Add the below to the top of the script, see if it makes a difference. If not, see if you can figure out some more details about what the turtle's getting confused over - put some extra print statements in so you can better see what it "thinks" it's doing, as it does it.

local ores_mined, tCordsInput, select, screenw, screenh, fuel_level, _sFile

I added the local variables to the beginning of the program and still no luck, the bug still exists. And may I add the turtle still knows were it is, its able to return to the chest normally.

If you restart the turtle over and over, does it always work?

If you restart just the script over and over, does it always fail?

Bomb Bloke, on 15 January 2014 - 07:30 AM said:

If you restart the turtle over and over, does it always work?

If you restart just the script over and over, does it always fail?

If you restart the turtle over and over it does always work.

If you restart the script over and over it will fail if the turtle has moved away from one of the vertical holes it digs but as long as its in or above one of the hole its fine. And will continue normally. but it still knows were it is because it can still find the chest.

I updated the bug in my first post to be more descriptive. If anyone has any ideas please tell me.

Ok, had a bit of spare time so I tried running the script.

First issue I ran into was setting the initial co-ordinates - having no GPS system set up, I had to type them manually. Entering in the numbers was simple enough but when I pressed enter at the end nothing happened. I had to inspect the source a bit harder to get past that - it wanted me to enter a "y" figure between 1-255, though as far as the GPS API and many non-MineCraft-related conventions are concerned, "z" handles height.

At this point it'd likely be easiest to changes lines 536 and 539 accordingly:

                x,z,y = gps.locate(3)

                        local tmpx,tmpz,tmpy = gps.locate(3)

It's also not at all clear to the user that you want a number from 0-3 entered for "facing", especially given the complete lack of feedback when you type something wrong (and what regular user is going to know what those numbers mean?). I'd highly recommend that at the least you document these issues (no feedback when typing something wrong, potential confusion about y/z, how north=0 etc).

Anyway, once the turtle was moving I told it to exit the script and then re-launched it. It returned to the surface, moved four blocks to the south, then started digging downwards again.

I then fully rebooted the turtle and relaunched the script. It returned to the surface, moved four blocks to the south and four blocks to the east, and started digging down again. :P/>

After a couple more tests it became clear that the further I allowed the turtle to wander from its starting position, the further away again it'd wander when I next started the script. This suggested it initially knew it was far away from home, and trying to get back there - only it had its directions confused, so instead of travelling "closer" to its starting point it was going in the opposite direction. Soon it was going dozens of blocks each restart and buried itself in a mountain - it had no idea where it was after having done so.

With the finger pointed squarely at the movement functions, I examined then re-wrote the following inside "loc":

        facingToAxis = {
                [0] = { axis = 'z', unit = -1 },  -- Moving north DECREASES your "z"
                [1] = { axis = 'x', unit = 1 },   -- etc
                [2] = { axis = 'z', unit = 1 },
                [3] = { axis = 'x', unit = -1 }
        },

        movez = function(d)
                if d < loc.z then loc.face(0) elseif d > loc.z then loc.face(2) end  -- Face NORTH to decrease "z", etc.
                return loc.moveForward()
        end,

        movex = function(d)
                if d < loc.x then loc.face(3) elseif d > loc.x then loc.face(1) end  -- Face EAST to increase "x", etc.
                return loc.moveForward()
        end,

On restarting the script again, the turtle dug its way out of the mountain back to the area where I'd initially started it.

While a rather verbose retelling, hopefully the above gives you some insight into how you might go about troubleshooting things in the future.

Bomb Bloke, on 16 January 2014 - 08:56 PM said:

-snip-

I really do thank you for your help but… non of that fixes the program.

For starters I have y and z swapped for the sake of it being the same as minecraft, and as long as you set up your gps host this way. The gps api could care less what way is which it just does math and the math is the same no mater if y is swapped with z or not.

Secondly, I can pretty much sum up the rest of your conclusion to the fact that zero is not north its south. 0 = south 2 = north just like in minecraft, and again only reason I did this is so people only have to push F3 and copy down the numbers rather then thinking about which direction is which.

Also I have all the info needed to set up this program documented on my forum post.

Henness, on 12 January 2014 - 10:51 PM said:

Forum post for the program can be found here:
http://www.computerc...efinder-tunnel/
So that you can set it up correctly.

Ah, fair enough. Bear in mind, however, that the one GPS tutorial I've found around these parts is specifically incompatible with your setup. I'll have to keep it in mind if I ever distribute a script that uses GPS calls - should be simple enough to detect the orientation automatically.

Anyway, such orientation issues (edit: in terms of facing) are the only possibility I can see which would cause the behaviour you describe. In fact, having set up a GPS satellite to your specifications, I can't otherwise replicate your problems at all. For me it makes no difference how I terminate the script - rebooting, Ctrl+T (once to exit back to AP, or twice to go back to shell), telling it to save&exit, telling it to exit without saving… it all works fine.

There are two exceptions. If something prevents the turtle from going backward on line 550 (eg a mob), then locate() will end up returning an incorrect result. Obviously this won't cause the turtle to move more then a square out, but it's an issue none the less. I suggest not bothering to move backward and instead just returning your "tmp" variables.

The other is when the turtle starts up with a full inventory. locate() calls forward(), and in this case, forward() will call returnToChest()… but without having resolved the rest of locate() first, this will obviously have bad results (I tried it, and for all I know my turtle's still going upwards…).

I can only suggest repeating some of your tests. In particular I suspect that there's a rogue GPS server somewhere that's messing things up for you - shut down all the ones you're aware of, type "gps locate" into the prompt, see if you still get some replies back.

The bug only happens when when the turtle program is exited between the vertical holes.

Thanks for the information on the full inventory thing.

Ok, I still haven't been able to reproduce it in the field, but I think I've got it this time (honest!).

As the turtle works, tSave.l (and sometimes tSave.w) get updated. Every so often, tSave.returnPos gets updated, along with an automatic save to disk.

Let's say the turtle has just finished digging out a column, and starts to move forwards. If you Ctrl+T out, Ctrl+R out, or exit without saving, that's all fine.

The problem occurs when you try to save and exit. Because the turtle has moved one or more spaces without updating tSave.returnPos, when you resume, the turtle will move BACKWARDS to where tSave.returnPos was last set - but the values of tSave.l/tSave.w will still be set as though the turtle were at the position where the script was exited.

Simply updating tSave.returnPos just before save&exiting wouldn't be enough to resolve this on its own, as there'd still be some room for confusion if you managed to catch the turtle while it was in the process of turning (it'd potentially resume in a direction perpendicular to the intended excavation site). It may be simpler to remove the save&exit function entirely, but either way I figure you should be able to work things out from here.

Omg I thank you so much for this lol, that's exactly what it is. I don't know why I didn't see that.

Don't worry, I'm thinking much the same thing in regards to my own eyes. :|