Fixing this code? (Recursive room digger, likely recursion broken)

So, I've been having a lot of issues with employing recursive code in CC. Basically, it works as expected for a few iterations, and then suddenly begins to break.

As an example, this is a room digger code. It's basically designed such that I pick a length, and a width, and it digs out a 3-high room with these traits. Anyhow, it ran successfully down 4 rows, before suddenly breaking on the back() step in the recursion, and opting to do the turning code (for the next length to hollow out).

I took a screen to help show what I'm getting at as far as what "error" means:

Note: far more readable version on pastebin: http://pastebin.com/vrf6S6rs

args = { ... }
-- A[1] == LENGTH, A[2] == X
function refuel()
turtle.select(1)
if turtle.refuel(0) and turtle.getFuelLevel() == 0 then
  turtle.refuel(1)
  return true
elseif turtle.getFuelLevel() > 0 then
  return true
else
  return false
end
end
function dig(counter, x)
-- dig until at length value
if counter < x then
  repeat
  until turtle.dig() == false and turtle.digUp() == false and turtle.digDown() == false -- in theory, deal with recurrent blocks like gravel

  turtle.forward() -- move forward into the hole
  dig(counter + 1, x) -- call again, pass new counter value to recursive function
  turtle.back() -- as recursion resolves, move back to compensate for forwards and return to start pos
elseif x == counter then -- clear last segment before returning
  turtle.digUp()
  turtle.digDown()
  return false
end
end
-- get turtle ready to dig another row
function prep()
turtle.turnLeft()
turtle.dig()
turtle.forward()
turtle.turnRight()
turtle.digUp()
turtle.digDown()
end
function move()
local initial = true
local length = tonumber(args[1])
local x = tonumber(args[2])

-- a note to the person kind enough to help with this: I sort of messed up the names. X is how long the room is, length is how many rows.
print("Length: ", length, " X: ", x)
turtle.up()
for i = 1, length, 1 do
  if refuel() == false then
   print("ERR: No fuel!")
   break
  end
  if initial == true then
   print("dig started")
   dig(0, x)
   initial = false
  else
   print("prep started")
   prep()
   dig(0, x)
  end
end
end
move()

At a glance, I'm thinking it's the gravel causing your problems - dig() has a mechanism to deal with it, prep() does not.

Bomb Bloke, on 25 October 2015 - 01:07 AM said:

At a glance, I'm thinking it's the gravel causing your problems - dig() has a mechanism to deal with it, prep() does not.

Thanks for pointing that out - though in the present situation, the bug shouldn't be triggering. That weird gravel-like block you see (gravity independent) is andesite from Chisel2. So far at least it hasn't hit any gravel.

Sorry for the DP, still on approved posts: anyhow, I should also mention that the chunk where this was active is now super low FPS and pushes my Java to 60% usage. Moment I leave the chunk, FPS returns to normal.
I had to pick it out rather than terminate, could that have caused its own issues?

Looking closer, the only other mistake in the code that I can see is the way you're handling fuel. You consume a fuel item at the start of a row, and but only if the turtle's tank is completely empty. Which means that if the row length is 10 and the turtle has 5 fuel at the start of a row, it'll skip refuelling, go forward as far as it can, run out of juice, then fail all further movement calls until it's allowed to refuel at the start of the code for the next row.

That'd cause the symptoms you're seeing, and could be corrected by having the refuel() function compare turtle.getFuelLevel() to x instead of 0.

i had this issue aswell..
mobs and bats can be the cause of this.. it was for me at least
and for refueling..

every time mine comes back from after doing a row, it unloads, and then checks the fuel lvl.
that way, you can build insanely large rooms, without running out of fuel (if you keep it restocked in its inventory)

Bomb Bloke, on 25 October 2015 - 02:33 AM said:

Looking closer, the only other mistake in the code that I can see is the way you're handling fuel. You consume a fuel item at the start of a row, and but only if the turtle's tank is completely empty. Which means that if the row length is 10 and the turtle has 5 fuel at the start of a row, it'll skip refuelling, go forward as far as it can, run out of juice, then fail all further movement calls until it's allowed to refuel at the start of the code for the next row.

That'd cause the symptoms you're seeing, and could be corrected by having the refuel() function compare turtle.getFuelLevel() to x instead of 0.

Thank you very much for your help! One last major question - when you say "symptoms", just to elaborate, do you mean the FPS lag as well?
The reason I ask is now that entire chunk is a 0FPS zone, and I dug the turtle out so I'm not sure how I'd restore it if that's in fact the case. Does this sort of thing have the potential to corrupt a chunk?

canadianvice, on 26 October 2015 - 01:35 AM said:

when you say "symptoms", just to elaborate, do you mean the FPS lag as well?

I've never heard of ComputerCraft causing that (actually, monitors can, when you're facing them, but I didn't get the impression you were using monitors)

What other mods do you have?

HPWebcamAble, on 26 October 2015 - 02:25 AM said:

canadianvice, on 26 October 2015 - 01:35 AM said:

when you say "symptoms", just to elaborate, do you mean the FPS lag as well?

I've never heard of ComputerCraft causing that (actually, monitors can, when you're facing them, but I didn't get the impression you were using monitors)

What other mods do you have?

Basically, a good portion of the FTB Infinity Pack. We pulled them ourselves, but my day basically went like this:
Dig room manually
Rig up Aqeuous accumulators + piping to tanks and sprinklers
Glowstone magical crop farm
program turtle
test turtle program
fix turtle program
test turtle program (in outside, working chunk, though both worked at this point)
run turtle room digger in base chunk
runs 5 rows, glitches as seen in photo
try to restart it on a new row
Glitches after 3 or so rows again
Mine out with pickaxe
Game starts lagging to all hell, solely in that chunk.Which, sadly, contains my whole base.

Interestingly, if I activate the lever on my hidden door from outside the chunk, the door takes an extremely long (comparative to its normal working state) time to execute and open.
Hence why my suspicion is with the turtle.

I did upload the file via FTP straight into the turtle, without using a floppy as the intermediary as I usually do.

Sorry, I get this is a compcraft forum, but I'm sort of shooting for any answers I may get, and several hours of work are trapped in a time abyss.

Hm nothing out the ordinary

What are your computer specs?

canadianvice, on 26 October 2015 - 01:35 AM said:

Thank you very much for your help! One last major question - when you say "symptoms", just to elaborate, do you mean the FPS lag as well?

Sorry, I was only referring to the way in which the turtle was moving.

Turtles are generally very good at doing what they're told to do. If a chunk is causing the player movement issues for whatever reason, that typically won't stop a turtle from moving through it correctly. If for whatever reason a movement call fails "out of the blue" (something exceedingly rare), it'll still reliably return its success indicator. You can hence do this sort of thing:

while not turtle.forward() do
  turtle.dig()
  turtle.attack()
end

… which'll lead to the turtle smacking anything in its path until one single movement call succeeds.

Whatever's affecting that chunk is highly unlikely to be related to ComputerCraft. Given that it's just the one chunk, and your base is sitting within it, I'd be suspecting that it has something to do with the piping system overloading (which mod is that from?), and would break that up as a starting point.

Many players try to put all the blocks from each mod they're experimenting with in separate chunks, precisely so they can easily pinpoint which one is causing this sort of problem. On the other hand, some piping / tank systems go haywire if you try to spread them over multiple chunks (which can generally be made stable by ensuring they're all chunk loaded at all times).

HPWebcamAble, on 26 October 2015 - 03:22 AM said:

Hm nothing out the ordinary

What are your computer specs?

Solely regional. Server's worked perfectly before.

@Bomb Bloke: Oooh. That's going to be a doozy. I'll crank away at it tomorrow I guess. Maybe I'll just set off some TNT.

Disconnecting just the ends of the pipes first might be sufficient to make a difference. If not, remove the whole piping system, then failing that, get to work on the tanks.

canadianvice, on 26 October 2015 - 03:36 AM said:

HPWebcamAble, on 26 October 2015 - 03:22 AM said:

What are your computer specs?

Solely regional. Server's worked perfectly before.

The server's specs have nothing to do with your client's FPS :P/>
I meant your computer, the one you use to play minecraft

HPWebcamAble, on 26 October 2015 - 04:05 AM said:

canadianvice, on 26 October 2015 - 03:36 AM said:

HPWebcamAble, on 26 October 2015 - 03:22 AM said:

What are your computer specs?

Solely regional. Server's worked perfectly before.

The server's specs have nothing to do with your client's FPS :P/>
I meant your computer, the one you use to play minecraft

Well, considering this is AREA specific in the game, logically my computer specs have nothing to do with the issue, as it runs perfectly literally everywhere else. It's an issue with a corrupt or broken chunk. That said, my computer is certainly more than enough to handle minecraft.

@Bomb Bloke: I'm just going to try the nuclear option.

Edit: Just an update. It was something to do with ComputerCraft.
Either my GPS system getting torn down did it, or when I cast my turtle into the fires of Mt. Doom (Literally. I chucked it into a volcano). Either way, the chunk has been restored to full, timely function.

canadianvice, on 26 October 2015 - 04:56 PM said:

Well, considering this is AREA specific in the game, logically my computer specs have nothing to do with the issue, as it runs perfectly literally everywhere else. It's an issue with a corrupt or broken chunk.

Still, server specs won't affect your client's FPS

canadianvice, on 26 October 2015 - 04:56 PM said:

That said, my computer is certainly more than enough to handle minecraft

Ok, I thought so, but I just wanted to make sure

canadianvice, on 26 October 2015 - 04:56 PM said:

Either way, the chunk has been restored to full, timely function.

Fair enough ;)/>