26 replies to this topic

[Bomb Bloke]

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.

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.

[Henness]

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.

[Bomb Bloke]

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.

Edited by Bomb Bloke, 18 January 2014 - 08:52 PM.

[Henness]

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

Thanks for the information on the full inventory thing.

[Bomb Bloke]

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.

[Henness]

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.

[Bomb Bloke]

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