26 replies to this topic

[Henness]

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.

Edited by Henness, 16 January 2014 - 10:35 AM.

[Bomb Bloke]

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?

[Henness]

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.

[Henness]

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.

Edited by Henness, 13 January 2014 - 08:01 AM.

[CometWolf]

--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.

[Henness]

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

But I guess that still wouldn't fix my problem

[Henness]

Anyone have any tips to find this bug?

[Moody]

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

Edited by Moody, 14 January 2014 - 09:29 AM.

[CometWolf]

_ 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.

[Moody]

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:

Quote

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

Edited by Moody, 14 January 2014 - 12:28 PM.

[Henness]

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.

Edited by Henness, 14 January 2014 - 12:47 PM.

[CometWolf]

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...

Edited by CometWolf, 14 January 2014 - 01:02 PM.

[Moody]

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)

[Henness]

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.

[Henness]

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

[Bomb Bloke]

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

[Henness]

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.

[Bomb Bloke]

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?

[Henness]

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.

Edited by Henness, 15 January 2014 - 11:02 AM.

[Henness]

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