# ComputerCraft | Programmable Computers for Minecraft

»

## Rothbomb30 Jul 2016

I have written an API (trackMove) for tracking turtle location in cartesian coordinates. I have run into some issues while utilizing it in a program I have written to dig a rectangular room (digRoom).

In digRoom, the turtle stops mining and returns to the chest to empty it's inventory when all slots are occupied. In order to allow the turtle to return to the location it stopped at, I save its current location to instance variables before returning. The excerpt below is from this portion of digRoom:

```if shouldReturn() then
tempX = trackMove.xCoord
tempY = trackMove.yCoord
tempZ = trackMove.zCoord
tempO = trackMove.orientation
print("Temp Coords: " .. tempX .. ", " .. tempY .. ", " .. tempZ .. ", " .. tempO)
returnToOrigin()
print(trackMove.xCoord .. ", " .. trackMove.yCoord .. ", " .. trackMove.zCoord .. ", " .. trackMove.orientation)
if not chestDump() then
return
end
trackMove.gotoX(tempX)
trackMove.gotoY(tempY)
trackMove.gotoZ(tempZ)
trackMove.orientTo(tempO)
end
```

After the turtle failed to return to the correct position, I added the print statements above to troubleshoot. Both consistently print the location of the turtle as (0, 0, 0) regardless its actual location. Digging deeper, I added a print statement in trackMove.

```function mine()
genDig.mine()
if orientation == 0 then
zCoord = zCoord + 1
elseif orientation == 1 then
xCoord = xCoord + 1
elseif orientation == 2 then
zCoord = zCoord - 1
else
xCoord = xCoord - 1
end
print("Current Position: " .. xCoord .. ", " .. yCoord .. ", " .. zCoord .. ", " .. orientation)
return
end
```

This resulted in the correct location being printed out every time the turtle moves forward (including when the other statement prints "0, 0, 0") until the turtle gets back to the chest and empties its inventory. From there, its z value if off by +1.

I assume the z error is a logic mistake that I will be able to fix, but the failure of digRoom to save the current location of the turtle in order to return has me perplexed. The full code can be found at my github here: https://github.com/dcmid/ComputerCraft

## Exerro30 Jul 2016

Ah, this is a limitation of APIs:

someAPI
```a = 1

function f()
a = a + 1
end
```

program.lua
```os.loadAPI "someAPI"
print( someAPI.a ) --> 1, as expected
someAPI.f()
print( someAPI.a ) --> 1, rather than 2
```

This is because when you load an API, the thing added to the global environment isn't actually the API's global environment, but a copy of it when it had been created, therefore any changes to the API's global environment won't actually affect the API table. You can see this here.

## Rothbomb30 Jul 2016

Exerro, on 30 July 2016 - 06:38 PM, said:

Ah, this is a limitation of APIs:

someAPI
```a = 1

function f()
a = a + 1
end
```

program.lua
```os.loadAPI "someAPI"
print( someAPI.a ) --> 1, as expected
someAPI.f()
print( someAPI.a ) --> 1, rather than 2
```

This is because when you load an API, the thing added to the global environment isn't actually the API's global environment, but a copy of it when it had been created, therefore any changes to the API's global environment won't actually affect the API table. You can see this here.

Any advice for what I should look into to accomplish the same result?

## Exerro30 Jul 2016

You could make a 'location' table, containing the x, y, z and orientation. As both the actual API and API environment would contain the same table, getting and setting keys inside that table would work from both inside the API file and outside. For example:

```location = { x = 0, y = 0, z = 0, orientation = 0 }

location.orientation = location.orientation + change
...
```

Other than that, you could use something like this:

```local trackMove = {}

trackMove.x = 0
trackMove.y = 0