90 replies to this topic

[CupricWolf]

Shini, on 25 March 2013 - 03:01 AM, said:

>_> is there a way to make continue its work after reloading/restart

I'm working on it but it is very hard. My solution is to write to a file its current X, Y, Z coordinates, then facing, the radius, the type,and it's current used blocks. The program correctly writes the file and when it starts back up again it correctly reads the file, but due to the complexity of the loops used i don't know where to put ways of rewriting the variable to the values from the save file.

[Keridos]

happydude11209, on 25 March 2013 - 01:07 PM, said:

Shini, on 25 March 2013 - 03:01 AM, said:

>_> is there a way to make continue its work after reloading/restart

I'm working on it but it is very hard. My solution is to write to a file its current X, Y, Z coordinates, then facing, the radius, the type,and it's current used blocks. The program correctly writes the file and when it starts back up again it correctly reads the file, but due to the complexity of the loops used i don't know where to put ways of rewriting the variable to the values from the save file.

Take a look at the shape builder here: https://github.com/K...s/Shape-Builder
prubys code is included here and I considered that a startover script for reboots would be nice. If you want, you can try to add that to the shape builder as pruby and me are trying to consolidate all shape builders into one program, for better overview.

[CupricWolf]

Keridos, on 25 March 2013 - 01:20 PM, said:

happydude11209, on 25 March 2013 - 01:07 PM, said:

Shini, on 25 March 2013 - 03:01 AM, said:

>_> is there a way to make continue its work after reloading/restart

I'm working on it but it is very hard. My solution is to write to a file its current X, Y, Z coordinates, then facing, the radius, the type,and it's current used blocks. The program correctly writes the file and when it starts back up again it correctly reads the file, but due to the complexity of the loops used i don't know where to put ways of rewriting the variable to the values from the save file.

Take a look at the shape builder here: https://github.com/K...s/Shape-Builder
prubys code is included here and I considered that a startover script for reboots would be nice. If you want, you can try to add that to the shape builder as pruby and me are trying to consolidate all shape builders into one program, for better overview.

Ok, thanks. Also check out my thread I just made http://www.computerc...ucture-builder/ that is about the project in which I'm working on it. You might want to include the cylinder building function I have made. And maybe the progress bar. Are you doing any kind of work on resuming from a save file?

[CupricWolf]

happydude11209, on 25 March 2013 - 02:55 PM, said:

Keridos, on 25 March 2013 - 01:20 PM, said:

happydude11209, on 25 March 2013 - 01:07 PM, said:

Shini, on 25 March 2013 - 03:01 AM, said:

>_> is there a way to make continue its work after reloading/restart

I'm working on it but it is very hard. My solution is to write to a file its current X, Y, Z coordinates, then facing, the radius, the type,and it's current used blocks. The program correctly writes the file and when it starts back up again it correctly reads the file, but due to the complexity of the loops used i don't know where to put ways of rewriting the variable to the values from the save file.

Take a look at the shape builder here: https://github.com/K...s/Shape-Builder prubys code is included here and I considered that a startover script for reboots would be nice. If you want, you can try to add that to the shape builder as pruby and me are trying to consolidate all shape builders into one program, for better overview.

Ok, thanks. Also check out my thread I just made http://www.computerc...ucture-builder/ that is about the project in which I'm working on it. You might want to include the cylinder building function I have made. And maybe the progress bar. Are you doing any kind of work on resuming from a save file?

I took a look at it, and I see you already have a cylinder function. I have forked you and will soon make a pull request because I have added a new shape, the bowl. I hope you take a look at it.

[Keridos]

happydude11209, on 25 March 2013 - 04:57 PM, said:

happydude11209, on 25 March 2013 - 02:55 PM, said:

Keridos, on 25 March 2013 - 01:20 PM, said:

happydude11209, on 25 March 2013 - 01:07 PM, said:

Shini, on 25 March 2013 - 03:01 AM, said:

>_> is there a way to make continue its work after reloading/restart

I'm working on it but it is very hard. My solution is to write to a file its current X, Y, Z coordinates, then facing, the radius, the type,and it's current used blocks. The program correctly writes the file and when it starts back up again it correctly reads the file, but due to the complexity of the loops used i don't know where to put ways of rewriting the variable to the values from the save file.

Take a look at the shape builder here: https://github.com/K...s/Shape-Builder prubys code is included here and I considered that a startover script for reboots would be nice. If you want, you can try to add that to the shape builder as pruby and me are trying to consolidate all shape builders into one program, for better overview.

Ok, thanks. Also check out my thread I just made http://www.computerc...ucture-builder/ that is about the project in which I'm working on it. You might want to include the cylinder building function I have made. And maybe the progress bar. Are you doing any kind of work on resuming from a save file?

I took a look at it, and I see you already have a cylinder function. I have forked you and will soon make a pull request because I have added a new shape, the bowl. I hope you take a look at it.

I will take a look at it as soon as you send the pull request. New functions are always welcome. Btw I am trying to make this project a bit more communitydriven, not just 1 person administering all of it. Since that Aeolun guy who took the program was online for like 3 weeks and then disappeared entirely (for almost 6 weeks now), I have tried to update the program and get people into helping with it.

[CupricWolf]

Keridos, on 26 March 2013 - 09:19 AM, said:

I will take a look at it as soon as you send the pull request. New functions are always welcome. Btw I am trying to make this project a bit more communitydriven, not just 1 person administering all of it. Since that Aeolun guy who took the program was online for like 3 weeks and then disappeared entirely (for almost 6 weeks now), I have tried to update the program and get people into helping with it.

Thanks for including! I'll try to be more active then

[Scotty]

pruby, on 07 March 2013 - 02:41 PM, said:

solaris187, on 07 March 2013 - 01:55 AM, said:

I am attempting to build a dome using this command. I enter into the turtle (that has just been refueled) sdbuild -28 -sz 28 and it returns an invalid argument on the 28

Try with 28 instead of -28?

sdbuild 28 -sz 28

Hi Pruby,

I'm using your sdbuild as it's the only one I can find which lets me position the turtle in the center of the construction, which is necessary as I'm stacking domes and spheres of different radius on top of each other.

The version I'm running is http://pastebin.com/SUJsjAqi

Unfortunately when I go for a dome with the command line: sdbuild 24 -sz 24 the result is:

Unrecognized argument: 24
Usage: sdbuild <radius> [-c] [-sz
<start layer>] [-ez <end layer>]
sdbuild:218: attempt to call nil

I verified that it's the argument for -sz that's the problem by trying sdbuild 24 -sz 28 and got back

Unrecognized argument: 28

I'm hoping you have a fix for this.

[Vas]

This thing needs a fuel checker so when it runs out of fuel, it can be resumed when more fuel is added.

[Drazlak]

could you add something to build a floor for you because i use ftb and i have lots of rooms i like making

[Jevoney]

This turtle program looks fantastic sadly I have been unable to get it to even activate. I have downloaded the cc-get file (unpacked it) then merged it with computercraft.zip once in game however I get a program not found error when I enter "cc-get" into the turtle ....so either I have done this incorrectly over and over or this does not support multiplayer server?

Any assistance would be appreciated!

Update: Managed to get it working did not realize had to do a "pastebin get (filename) rename" to get it to work , again nice work excellent program!

[Niseg]

happydude11209, on 25 March 2013 - 01:07 PM, said:

Shini, on 25 March 2013 - 03:01 AM, said:

>_> is there a way to make continue its work after reloading/restart

I'm working on it but it is very hard. My solution is to write to a file its current X, Y, Z coordinates, then facing, the radius, the type,and it's current used blocks. The program correctly writes the file and when it starts back up again it correctly reads the file, but due to the complexity of the loops used i don't know where to put ways of rewriting the variable to the values from the save file.

I can tell you exactly how to do this conversion in the code but it has two parts - 1 converting the code into a state machine 2 finding a reliable way to keep the state

if for example we have this code

for i=1,16 do
a()
for j=1,16 do
b()
end
c()
end
d()

this is how it would look as a state machine

local endstate=10
local state=0
local i=1
local j=1

while state~= endstate do
	if state==0 then
	a(); state=1
	elseif state==1 then
		b()
		if j==16 then
			state= 2
		else
			j=j+1
		end

	elseif state == 2 then
		c()
		if i==16 then
			state=3
		else
			i=i+1
		end
	elseif state==4 then
		d()
		state=endstate
	end
-- save state ,j and i here
end

(part 1)
I think I did it correctly if i didn't mess it up . the whole idea is to have 1 loop which is "infinate" until reaching the end state . In the example code you actually have 3 states to save - state,i and j . So if you write a function with this state machine and you want to continue the process you will need to give it the state,i,j values it stopped in and it will continue from that exact point.

When getting into coding you should keep in mind that you don't have to keep a state to every action. You only need to save actions that drastically change the environment or position/face of the turtles . Digging air for example doesn't necessarily effect it but placing an item from inventory over a block can depend on how your program handle it (if it doesn't dig it - nothing happens).

(part 2)
Recovering with a state machine will work provided you can save your state reliably but unfortunately in Computercraft it's not always the case especially if using the file system to save variable because on servers the turtle inventory and position are usually asynchronous to the turtle file saves (instant) which makes figuring out the state you are in a gamble.

There are a few solution for this one of them is use the inventory to keep track of the state - because you have a certain amount of blocks at the beginning of the program you can figure out i and j according to the number blocks you started up with . after that you will also need to identify what state you are in and where are you facing.

Because of the inherent problems of saving states this can make identifying the state you are in even more complicated than turning your whole build function into a state machine. this makes it a better idea to keep the turtle in a predictable spot at all times.

You can let the user identify the state of the turtle or bring it to some predictable location but automatic restart can be a real gamble.

[Keridos]

Niseg, on 03 July 2013 - 02:22 AM, said:

Recovering with a state machine will work provided you can save your state reliably but unfortunately in Computercraft it's not always the case especially if using the file system to save variable because on servers the turtle inventory and position are usually asynchronous to the turtle file saves (instant) which makes figuring out the state you are in a gamble.

There are a few solution for this one of them is use the inventory to keep track of the state - because you have a certain amount of blocks at the beginning of the program you can figure out i and j according to the number blocks you started up with . after that you will also need to identify what state you are in and where are you facing.

Because of the inherent problems of saving states this can make identifying the state you are in even more complicated than turning your whole build function into a state machine. this makes it a better idea to keep the turtle in a predictable spot at all times.

You can let the user identify the state of the turtle or bring it to some predictable location but automatic restart can be a real gamble.

This is why me and happydude kind of decided that we need gps functionality for the persistency of the whole program (the versatile shape-builder) since the save file really often is not synchronized to the current position/facing of the turtle. The problem lies in the fact that you managed to describe very accurately, saving instant but the movement actually takes time. Basically you will end up with an invalid save file almost all of the time. In our code, since our buildscripts all are all kind of hardcoded we can retrieve all information needed to return by using a simple function to get coordinates and facing -> and using that to correct the position of our turtle and then start executing the functions again. But that makes us limited to a certain design of functions, making some thing pretty hard to implement (like inverted building or improving build routines or optimizing them.

/edit: Made our programs resume function work in most cases now. Basically I assume that the turtle gets stuck while moving or turning around. So I just save the progress before I actually move and return the building process after reaching the saved state. That actually worked pretty good so far.

[Sangar]

Regarding the persistent position issue, shameless self-plug: I wrote an API that should properly take care of keeping track of a turtle's position. It exploits the fact that you can check whether the turtle moved after a forced reboot by comparing the current fuel level to the one before the last move command was issued: if it's one less, the turtle moved, if it's equal it did not. This obviously only works when the turtles use fuel. I'd be curious to see how it holds up in more complex projects such as this one

[Geforce Fan]

Upload it to pastebin! That way we can use it on SMP without having to upload ourselves.

[Keridos]

Sangar, on 21 July 2013 - 04:04 AM, said:

Regarding the persistent position issue, shameless self-plug: I wrote an API that should properly take care of keeping track of a turtle's position. It exploits the fact that you can check whether the turtle moved after a forced reboot by comparing the current fuel level to the one before the last move command was issued: if it's one less, the turtle moved, if it's equal it did not. This obviously only works when the turtles use fuel. I'd be curious to see how it holds up in more complex projects such as this one

You might want to check out the shape builder from here: http://www.computerc...-updatedactive/
We have a pretty good resume functionality even without gps. WE keep track of the blocks used and the moves done in a safe file. If the turtle restarts during that it is assumed that it has moved at the point of the restart (which is the case really often) and it continues to build correctly in most cases. For perfect resumability you need to have GPS though.

[Sangar]

Ah, I see. When placing blocks that's a pretty robust way to keep track of movement for sure.

[Geforce Fan]

Hey, could you add the option to made domes pre-filled with dirt or something? For like, underwater support. Maybe not remove the dirt because that's pretty easy but hard to do with a turtle, but at least place it. Maybe have like 8 slots (1-8) have glass, and 8-16 have dirt to make sure it doesn't fill it with glass, lol. It's too hard to fill, let's say 16 radius domes with dirt
Also, you need to add "refuel" at the thing where it stops b/c it can't move so if it's stopping b/c there's no more fuel you can refuel it.

[sha263]

Hi iv got this and it keeps saying it cant move and to press enter but there is no blocks around it

[Acuena]

Found a bug.

I am making a sphere radius 20 and at the begining it worked well with the check if it has blocks in the selected slot. But now when it is on slot 9, it complains it don't have blocks even if slot 10 have blocks. It looks like it dont go to the next slot. Did a test when I had to refill the turtle, and it happened on slot 9.

[gunther222]

I've made modified versions of this program to optionally clear blocks in the way of biulding, and also to get it's fill material from an enderchest.

My bases tend to be large 64x64 squares, and I used your code, with the above modifications to biuld a glass dome over the entire base.
I would have been clearing land and refilling the turtle with glass constantly if not for the added features.

Other than that, this is great peace of code. It makes really clean domes/spheres. Thanks!


Setting the two variables clear_blocks and ender_fill enable this behavior.

The ender chest linked to your fill material should go in slot 16.


http://pastebin.com/7wFqnhr3