Looking through your code, I thought it was funny that I coincidentally picked some of the same variable names (like "facing") you did, and just implemented them slightly differently (like 1-4 instead of 0-3). By the way, in that particular case I might be able to help you out already: here's a script that ensures the turtles always move *forward* (never in reverse) with the same efficiency. xRel and yRel would by my "GPS" variables.
local function face(f) -- Re-orient the turtle WRT original facing: 1=forward; 2=right; 3=back; 4=left if f-facing == 0 then return elseif math.abs(f-facing) == 2 or f-facing == 1 or f-facing == -3 then while f-facing ~= 0 do turtle.turnRight() facing = facing + 1 if facing == 5 then facing = 1 end end else turtle.turnLeft() facing = facing - 1 if facing == 0 then facing = 4 end end end local function getThereX(dist) if dist == 0 then return elseif dist > 0 then face(1) else face(3) end for n = 1,math.abs(dist) do tryDig() tryForward() end xRel = xRel + dist return 0 end local function getThereY(dist) if dist == 0 then return elseif dist > 0 then face(4) else face(2) end for n = 1,math.abs(dist) do tryDig() tryForward() end yRel = yRel + dist return 0 end local function goTo(x2,y2) local dx = round(x2-xRel) local dy = round(y2-yRel) -- Check for low-hanging fruit first if facing == 1 and dx > 0 then dx = getThereX(dx) elseif facing == 2 and dy < 0 then dy = getThereY(dy) elseif facing == 3 and dx < 0 then dx = getThereX(dx) elseif facing == 4 and dy > 0 then dy = getThereY(dy) end -- do the shorter angle next if facing % 2 == 1 then dy = getThereY(dy) dx = getThereX(dx) else dx = getThereX(dx) dy = getThereY(dy) end end
Here are some other suggestions, which I would love to (and think I am able to) help implement if you're interested. I realize that a few of these (like the n-prism) are more challenging, but I have some ideas on how to go about them all.
Optional command line entry interface
- type "versatileShape dome 7 -d -e -f" to make a dome with diameter 7, "dig down" flag, "use ender chest" flag, "fill in" flag
- Suggest writing a function to populate the "parameters table" right away, by looping through #argTable if inputs are provided
- Good for scripting larger projects (like a castle!!! )
Re-organize the (already brand new) input menu (sorry, CupricWolf! We could use the same layout?)
- Choose 2-D foundation first (line, circle, n-sided poly)
- Then choose solid form (solid, tube, pyramid, 2-D)
--- So Circle choices would be "sphere, cylinder, cone, flat circle"
--- But Square choices would be "cuboid, square tower, pyramid, flat square"
--- And n-sided poly choices would be "n-prism, n-tower, n-pyramid, polygon"
- Seems like the only hard one would be the n-prism, which would require a new "angled surface" algorithm
Write a builder for imperfect n-sided polygons (aka, not all angles equal)
--- Construct by angle/side length
--- Possibly develop a GUI, or see what's already out there
--- Probably skip the "prism" option on this one
New external scripts to help showcase the code
--- Castle/fort!!!
If any of these seems like a priority and you're not already working on it, I'd be happy to get started myself. Thanks for your consideration.