I understand it except for why in the first line you put …("\"2\" is a "… why all the slash marks as apposed to …("2 is a "…?
In Lua (and indeed in a lot of languages), if you place a backslash in a string it's treated as an "escape" character. This means that the following character is to be treated in a special way.
Say you want to print a quotation mark. Catch is, you use quotation marks to signify the start and end of what you want to print! Try running this and see how far you get:
print(""")
The quote is one of those characters that can be escaped, and in this case doing so tells Lua that you actually want to represent a quotation mark within the string. Eg:
print("\"")
\n is another common usage of the escape character - that indicates that you want to perform a line break. Given how quotes are treated, you can probably guess what to do if you want to put an actual backslash within your strings.
I tested it the first time with an odd number for width which works just fine. Later realizing that even numbers still staircase. The program does everything right on odd widths because it alternates turns and with the 180 brings it back. If ending on an even though it drops and then continues to the right. creating this staircase effect like before. I tried playing with this a bit. Even tried to create a couple of functions that would get called to correct this error but they all failed to current the problem. There has to be a way to fix this but I have no idea how to do it.
Consider: At present, the turtle travels along a pattern where for each layer it will turn right/left/right/left/etc. That's fine for an odd width, but not for an even one - in an even situation, it'd need to do one layer according to the right/left pattern, the next according to a left/right pattern, then back to right/left, and so on downwards.
Now, you
could expand out the turning check to determine whether or not the width is even or not, and if it
is, then add the current depth counter to the current width counter when performing the bit.band() check to determine direction. This would achieve the desired effect, but the code would be a bit lengthy and ugly.
(Well, without a ternary, but let's not get into those yet.)
What I'd suggest is to wait until the end of each layer,
then check to see if the width is odd. If it is, then do the usual 180 and continue, but if
not, then turn just 90 degrees and switch the width and the length of the shaft around. This then makes the right/left pattern viable for all layers.
The code would look like this:
turtle.digDown()
turtle.down()
if bit.band(w,1) == 1 then
-- Width of the shaft is odd, carry on as before:
turtle.turnRight()
turtle.turnRight()
else
-- Width of the shaft is even; change the orientation of the dig:
turtle.turnRight()
local temp = w
w = l
l = temp
end
By the way, on line 10 you're really wanting to bear in mind that the turtle already starts inside the first block of each lane, and therefore only needs to dig out length - 1 blocks from that point:
for j=1, l - 1 do
If the chunk that it is working in is no longer loaded for me or anyone on the server will it keep running? Does the turtle keep it loaded?
KoGY mostly has this covered, but usually the answer is to build and place a dedicated chunk loader in the area. In fact, depending on the mods you've got available, in some cases it's possible to integrate a chunk loader module into the turtles themselves (in a similar way to how you craft them together with crafting tables and pickaxes and so on).
In many circumstances, the
GPS API can be invaluable when coding turtles that can restart themselves after eg a server reboot. Unfortunately it's not all that useful unless you're dealing with a "fully automated" turtle - eg, one which harvests the same farm over and over again (and so has cause to return often to a certain location in the world anyway, and doesn't really care about what it was doing when the reboot happened specifically), as opposed to a digging turtle, which is unlikely to ever mine out the same shaft more than once and needs to know exactly where it was up to when the restart happened.