keridos / shape-builder Goto Github PK

Since it asks the user "Which half of the sphere do you want to build?(bottom/top)", I think makes more sense if the user chose "half sphere" rather than "dome".

Someone asked in the forums if bbuilding things upside down might be included.
It clearly is possible but I have not yet found an elegant way to do it.
Basically you would need to edit all functions to be built reversed, at least the ones not being able to be build that way now. Would only be the pyramid and the stairs, though stairs upside down do not make sense to me.
Going to write the stuff for the pyramid function soonish. Would be cool if new shapes could be able to be built upside down too.

Hi,

I play on the server with FTB Ultimate. I've been uploading stable version of the script to my turtle, choosing various shapes, placing building blocks inside (tried wood, sandstone, stone, glass, dirt), fuel (tried coal, lava bucket). Turtle starts to draw the specified shape but without placing any blocks - just driving on the ground/in the air. Is that a bug?

Thanks

A user said that a diamond would have been nice to implement for octagons. Do we want to add a diamond shape? or is this just a silly idea?

if x==y then
  local choide = abc
end
print(choice)

would error with choice being nil.

I will work on this pretty soonish to allow players without MiscPeripherals to also resupply their turtles on the go without having to constantly refill them

Shall we add that? For a few shapes like circles that would be very handy.

rsmodule overwrites the rs (redstone api) and a resupply module makes gps unusable.

To implement inverted shapes we might be able to get away with editing placeBlock() and safeUp(). First by renaming safeUp() to safeMoveVertical()` or some such. Then use an if statement.

function safeMoveVertical()
--code goes here
if inverted then
   turtle.down()
else
   turtle.up()
end
--more code here
end

And for placeBlock():

function placeBlock()
--code goes here
if inverted then
   turtle.placeUp()
else
   turtle.placeDown()
end
--more code here
end

The only problem with that is it would start at the top and work it's way down. Then we'd have to code a function that moves it up to the top before building so that it finishes on the same level it started on. Which will cause issues with being able to string together multiple shapes, but hey it's inverted!

Lets take that resume function discussion to this issue here.

Shall we split the Program into a main program and an API to use (for navigation and shape routines for example). Would result in a minor increase in work to do either for us (when we re"compile" it into 1 program) or for the end user (multiple files needed), but it could really help resolving conflicts when we work on the same file (which currently is always the case).
So with a bit of communication we should be able to work more efficient without worrying to cause manual rebasing conflicts (are they called that way?).

I was just playing around with the code that is hosted on pastebin. While building circles the turtle seems to move twice for every move it needs to make which causes it to overshoot and backtrack to any target blocks. I haven't tested any other shape but circle and cylinders do this. It seems like a major waste of time and fuel.

I think links to the pastebin and to the forum thread should be included in the ReadMe, this would help people like me (who know about this only on github) find it in those other places.

On the forum two people have asked to have hexagons and octagons added. Please take a look at how I've responded and give your two cents about the matter too. I think this may get accomplished with an n-gon builder. You would have to give it the number of sides and the length of each side. It could figure out the angle between the sides by using ((number_of_sides - 2) * 180) / number_of_sides. It could also use vector math to figure out distance from vertex to vertex and change directions when distance_from_last_vertex >= side_length (it would check this every block placed). I'm still not sure how exactly to tell it to go a specific angle from where it is now (turn 135° for an octagon, 120° for hexagon, etc) octogon is up-one-over-one and I believe hexagons would be up-one-over-one-up-one-over-two but I have no clue how to code that to work for any angle greater than 60 (triangle)

A few users (both on our thread and on pruby's original thread have mentioned that smaller circles/spheres/domes/bowls look more like octagonal shapes. Their "sides" that line up with the grid are a bit too long.
Link to external picture as this user has pointed out in a screen shot.
Ours is on the left and a different algorithm generated the one on the right. I personally don't know how to optimise this and haven't given it much thought other than some early exploration about our uses of sqrt(3). I'd like to ask pruby for some explanations as his code is really elegant but I don't know the motivation behind some of the code. I would eventually optimise smaller circles but I also don't think this to be a large priority since it already looks pretty good. This issue can be a discussion thread / journal (of ideas) on how to make smaller circles look nicer.

A user on the forums has asked if we could add circular platforms. This seems pretty useful so I'd like to try to add this. I think we could achieve this by telling the turtle to build from the center out to where the circle code says is the edge and then go back to center and repeat until both sides are done (kinda like how the very bottom/top of a sphere is filled in). That would be horribly inefficient, but its the only way I see. Do you have any other ideas?

linktorsstation is wrong method name. should be linkToRSStation

this bug prevents the resupply station from working(program doesn't even start)

Flags like returnToHome and enderchestRefilling aren't saved to the restore table. They should because starting a job with enderchest refilling and having to resume would just operate like normal after that.

I'm OCD, so these kind of things bother me... 😱 I will work my way through the code after my last pull request is merged and I shall refactor all of the code to make variables/functions be camelCase and flags be underscore_separated. I'll also expand non-descriptive variables like "ll" to have more descriptive names (In that case, "length"). Also, rectangle builds rectangles with dimensions depth by width, and platform builds filled in rectangles with dimensions width by length. So I will also change these to use the same words for consistent naming program wide; I will do the same for any other thing that doesn't match up. After that I will add a wiki page with a naming guide.

trying to build a sphere with radius 5 (didnt test more yet) resulted in "903: attempt to call table"

prog_table.param1 = rad would be more correct than prog_table {param1 = rad} ???

Please update the RA... Pastebin link because it is our main link and it has a typo that prevents users from building spheres, this causes issues with a sphere building program. The code as it is today (August 19, 2014) is in a stable form and will not be changing in a few weeks while I work on stuff locally. Please update the pastebin code to today's current code.

The known bug, now here a place to discuss it. My recent commit didnt fix it.

/edit: 71ff0af fixed it

Feature Request:

Ability to specify shape parameters from command line instead of having to go through the wizard.

I saw some command line arguments, but they didn't seem to be as robust as I am looking for.

Because it it writing to the file unless it is in sim mode it also writes when doing cost_only mode. Cost_only mode goes fast though since it isn't having to move, this causes the writing function to attempt to write far too quickly throwing the Too long without yielding error. Is there any major objections to changing if not sim_mode then... in several places with if not (sim_mode or cost_only) then.... If nobody has any concerns I will change this when I release my command line Pull Request. But if there is a reason for it being that way that I'm not seeing, please state so below. It might even be best to just change it to if not cost_only then... because cost_only should always true when sim_mode is true.

Are you eventually adding that to the code?

When trying to build an 8 sides prism, the program halts with the following error message:
shapebuild:1434: attempt to call nil

To reproduce:

1. Start program and select 8-Prism as the shape.
2. Select any option for each of the proceeding prompts until the final prompt.
3. Observe error message.

I'm currently trying to build a large, 65 radius dome. After the first few levels I keep getting this error: Build:982: attempt to index ? (a nil value). I've tried restarting the whole process a few times, it happens with or without the enderchest resupply. It also doesn't always happen in the same place. Some times I can restart it from the same place, most times though I get build:99: Too long without yielding.

Line 1155, in choiceIsValidShape(choice) function, "shphere" should be "sphere".

As I personally no longer play with CC on my private server, I am gonna create a port from the script to OC, should work without much to change, just gonna have to rewrite the whole CC API to OC API.

first bug: You start the program, without building blocks in slots, select a shape, It asks you to put in building blocks, when you place them it exits and tells you no blocks and no fuel used.

/edit: It refuses to work after that. And it seems to not like it when put into the global turtle folder? I currently have put it into to lua/rom/programs/turtle folder on my server.

/edit2: Still does not work after fixing the progress file creation, I am missing something....

A user asked if we could implement Non Straight lines and Lines thicker than 1 block wide.
While the actual code would not be that terrible the modifications in the crafting menu would be , lets say a bit weird.

As it is now hexagon code is pretty broken. I never really liked it to begin with, but now even less. While testing yesterday, not a single hexagon, no matter the size, connected or was remotely symmetrical. I think we should remove this shape until we decide to make new code that works better. What do you think?

I propose that we move the remaining building stuff from the choice function out to the shape building functions to make the choice function easier to read.

Some user in the forums posted that the turtle can get stuck if digging through sand/gravel. When digging through sand/gravel and the turtle turns around and sand/gravel fell behind it, it seems to get stuck with the current code. The result is that the user apperently has at least to hit enter to get it to move again.

To implement this I will probably add functionality to the -c command line flag that will save the final calculated value blocks + fuel to a file. To show progress I will write a progress bar that shows percentage of current blocks + fuel out of the pre-calculated blocks + fuel value. Executing any shape without the -c flag set will cause the program to execute a version of itself with the same parameters but with the -c flag, creating the final value file.

It looks like the spheres (at least in smaller versions) do look a bit strange.
For me it seems as if the faces of the sphere in all 6 room directions are a bit to big.
I uploaded a file on imgur to show a smaller sphere (radius 5) built with the current source code.

http://imgur.com/gHEV3XZ

I started working on gps functionality in the new "gps" branch. Any ideas on how we should set that up?
Reworking the movefunctions to check coordinates via gps?
Or add in a function that compares the virtual coordinates to real coordinates received via gps?
We definitely need to set the starting real coordinates in the prog table and store it in the file. That way we can compare the turtles position after resuming from file.
And how shall we keep track of the direction the turtle is facing?

I've tested this on many different shapes and the turtle always crashes. I'm not sure what is wrong with the program that is causing this though.

Sometimes the resume function seems to restart one coordinate off.
It happens when the turtle gets unloaded while moving basically it moves but does not update the file. A solution could be just to set a temporary variable in the file that gets deleted/changed after the turtle actually moved.
Or as WriteProgress checks for sim mode even just include the WriteProgress in the safemovement functions.
That would at least decrease the chance of this bug occuring.

This bugs ends in structures looking like this when you restart a few times:

Will add this in, needs a few more improvements like more than 2 options, but that is optional

function getInput(inputtype, message, option1, option2)
    local input = ""
    if inputtype == "string" then
        writeOut(message.. "(" ..option1 .. " or "..option2..")" )
        while true do
            input = io.read()
            input = string.lower(input)
            if input ~= option1 and input ~= option2 then
                writeOut("You didn't enter in " ..option1.." or "..option2 .. ". Please try again.")
            else
                return input
            end
        end
    end
    if inputtype == "int" then
        writeOut(message)
        while true do
            input = io.read()
            if tonumber(input) ~= nil then
                return tonumber(input)
            else
                writeOut("Need a number. Please try again")
            end
        end
    end 
end

/edit: made the function as shown here, implemented it, made ChoiceFunction a lot easier to read.
And the program lost a whopping 33 lines of unnecessary/redundant code.

I will start working on this in the next days, so we can use the hollow parameter for cuboids and rectangles aswell.

pre-constructing the shapes would make it 10x easier to resume progress. basically run the shape subroutine and make it construct a table where there are incremented steps, and each step contains the x, y, z coords of that needed block. Save that (then only access it thereafter via read-only!), then have the turtle make its own "progress table" of the same size as the shape space table, but with only "checkboxes." This is so the turtle can just say "I placed this block, next block is at X, Y, Z, so I need to go there next" without having to re-sim the entire function OR care where it's at. This would lend itself most easily to a GPS-enabled turtle, obviously, and would have to have a little bit more functional of a "navigate" function (similar to Direwolf20's "goto" which can find its facing direction)

basically, you'd end up with a "choicefunc" that looks something like:

for i = 1,table.getn(shape) do -- basically want to get the size of the array.  should be simple to acquire procedurally when the table is constructed
    if progress.[i] ~= true or progress.[i] == nil then -- I guess we could really just dynamically construct the array here, since it would just be the same result.
        goto(shape.[i].x, shape[i].y, shape[i].z)
        placeBlock()
        progress.[i] = true
    end
end

Of course, that's after we've already used the existing algorithms to construct the shape in a table. This is just the easy part. Making it go in "steps" also guarantees the turtle will follow exactly the pattern the algorithm dictates.

Edit: the "number of steps" (e.g. size of "shape" table, max size of i) is also the blocks used. Fuel used would work the same as it does now, since in cost-only it'd go through the same shtick as it does now (use the safeUp/back/down/etc functions, which record fuel usage, in the goto() function. no reason to not recycle those)

This method is also almost completely dependent on a GPS. Without one, we would have to record current location in the "progress" table (like we do now) as well as the direction we're facing, since we can't infer that from two GPS readings without GPS enabled. Yeah, I know, GPS takes up a peripheral slot, but it seems like for the "resume function" capability, it'd be worth it to drop something like a pickaxe. Especially for large projects (e.g. 40-dia dome).

This is a version 2.0 thing: I want to restructure the code so that it is more organized and easier to tell what is what. The code should be slit up into sections like: Variables, Movement and inventory code, Shape Constructors, UI code (Menu and CLI), Restore code, Building code, main(). Additionally I want to try to isolate CC code as much as possible to the movement and inventory code to move between OC and CC easier as well as allowing us to change to someone else's movement code if need be. main() should be simply a list of function calls, nothing else. I want to try to redo restoring code to work with the new way.

A few users (both on our thread and on pruby's original thread have mentioned that smaller circles/spheres/domes/bowls look more like octagonal shapes. Their "sides" that line up with the grid are a bit too long.
as this user has pointed out in a screen shot.
Ours is on the left and a different algorithm generated the one on the right. I personally don't know how to optimise this and haven't given it much thought other than some early exploration about our uses of sqrt(3). I'd like to ask pruby for some explanations as his code is really elegant but I don't know the motivation behind some of the code. I would eventually optimise smaller circles but I also don't think this to be a large priority since it already looks pretty good. This issue can be a discussion thread / journal (of ideas) on how to make smaller circles look nicer.

The turtle should not pick up blocks when breaking them. This causes the turtle to use these blocks for mining. Will try to take a look into that when the saveresume stuff is merged and working.