1.64 program behaving erratically

http://pastebin.com/NJPL3V36 <– My program I am running

The error:

miner:134: attempt to index ? (a nil value)

I'm not sure how this could happen, because I clearly defined isFuel on line 12.

Also, my search function is for some reason (occasionally) attempting to recursively mine "minecraft:flowing_lava", although it is identifying it as minecraft:flowing_lava and flowing lava is not on the whitelist I set. I'm still investigating this, no combination of moving/turning with a test program has been able to reproduce this behavior.

I'm posting this to see if there is something I missed in my code, as this was basically coded in about an hour.

I would upload video, however minecraft + recording + low RAM &amp; graphics = lag city.

If you would like to replicate the behavior yourself, simply download my program and run it on a turtle that is facing some flowing lava.

I have a clean version of minecraft, with no other mods (except forge of course).

The attempt to index ? (a nil value) wouldn't be occurring on the isFuel table, it would be occurring on the item table when the slot is empty; no item details will be returned if there is nothing there. Just add a nil check in just like you did at line 117.

theoriginalbit, on 29 September 2014 - 01:14 AM said:

The attempt to index ? (a nil value) wouldn't be occurring on the isFuel table, it would be occurring on the item table when the slot is empty; no item details will be returned if there is nothing there. Just add a nil check in just like you did at line 117.

Thanks, I can't believe I missed that :P/>. I think I've figured out why I thought it was trying to mine the flowing lava as well, my branch calls are improperly placed (fixed now, but they were).

New Question (same program though)

What is the most efficient way of recursively mining ores? I have something that goes like this:

1 - is there ore in front?
2a - yes, dig it, move forward.. go to step 1
2b - no, is there ore to the left?
3a - yes, dig it, move forward.. go to step 1
3b - no, is there ore to the right?
4a - yes, dig it, move forward.. go to step 1
4b - no, is there ore above?
5a - yes, dig it, move up.. go to step 1
5b - no, is there ore below?
6a - yes, dig it, move down.. go to step 1
6b - no, start going back through the stack of movement functions

I'm using proper recursion, using return to end the function. Basically, I want to know: Is it any more efficient if I check the sides in a different sequence? Such as checking up/down first, rather than last?

Problem #2
Somehow, my turtle got turned 90 degrees when I tested it. I've been unable to track down the bug, so if anyone sees anything, let me know.

I think it might be a good idea to stick those item tables into a separate file (eg an API) and load them from there. Perhaps just make it one table, then put it together with some functions which can perform searches for items with certain attributes (eg, "isOre", "isWood", "multipliable" (for stuff affected by Fortune), etc - you'd need to define these properties manually). Just a thought.

I'd say checking left/right should be done last, as this would potentially decrease the number of turns the turtle needs to perform in order to complete its task. For example, a 2x2x2 cube requires ten turns with your current logic, but it could be done with six.

I recommend making separate functions for moving up/down/forward, and even for back. Rig them so they can't fail (remember that turtle.dig() doesn't deal with mobs, and mobs can also move behind a turtle that wishes to move backwards - it'd ideally turn around in such a circumstance, and deal with the problem). I've even found turtle.turnLeft()/turtle.turnRight() to be unreliable under some circumstances, though since they do reliably return whether they succeeded or not, that's not a problem if you account for it. I have a hunch that running multiple yielding turtle functions in parallel (like you're doing) might be one such way to trigger movement failures, but it's a guess.

Likewise, I'd move the refueling check out of the "manager" and into a turtle movement calling function. Currently, if the turtle is low on fuel, it will try to turtle.select() its fuel slot. If it encounters lava at the same time, the search function will try to select the bucket slot… which yields, so the manager function may take the opportunity to try to set it back again before the turtle can fill its bucket. A rare scenario, but all eventualities should be accounted for.

You could shrink your code a bit by adding lava to the whitelist. You could shrink it more by adding sets of function pointers into tables within a sub-table, then just having one search function instead of six.

main() isn't keeping track of "gone" correctly. It should be starting it at 0, and it only increments it once for every four movements forwards.

Just by eyeing the code I can't see where the turtle would lose track of its orientation. Exactly when does it happen? While searching, or…?