I think I have this worked out conceptually, I just need to put it into practice.
Input is a single horizontal piston. A line of 10 vertical pistons pointing down above the input stream. 10 blocks leaves space for a sensor at the end to tell when the line is full. This becomes important later. A wall of 10 x 10 pistons on the other horizontal axis. A stream of single blocks gets pushed forward into a line, that line gets pushed down into a wall, the wall gets pushed left into a block. 10 forward x 10 down x 12 left = 1200 block storage.
Output is opposite the input corner (on all axis), bottom left back. There is a single piston pushing down from the top, so the output is pushed down. There is a vertical line of pistons on the forward face along the left edge, pushing forward into the output column. The other horizontal axis reuses the 10x10 wall. There is also a line of pistons along the bottom left edge, below and to the left, facing right, thier purpose is the extended piston supports gravity blocks, thier retraction allows a wall of gravel to fall.
Triggering output will feed gravel into the stream. Single pushes output down, Line pushes forward (only top moves), Wall pushes left (only closest moves). This action first fills the top forward edge, then top forward and top left edges, then back left edge, at which point a gravity filter has all the gravel drop out of the back left edge. The same action has the left edge advance toward the exit, then fills up front left edge. Front Top, Front Left, Top Left and Back left all fill with gravel, then gravel drops from back left again. Again front left advances, this time with 2 layres of gravel. Left wall of desired block is cleared and replaced with gravel in this fashion. At this point, one block of gravel goes in, one block of gravel falls through the gravity filter. A sensor detects this (not sequential gravel, which happens when a pillar of gravel falls, but gravel, new block pushed, gravel again) and retracts the piston line supporting the leftmost wall of gravel. The entire left wall falls, leaving space for the predifined action to push the remaining storage rectangle left. The rightmost wall fills with gravel, then this is repeated, until only gravel remains.
The action of filling, because it waits for the sensors to push the line down, and then the wall out, pushes the gravel left, the retracted pistons fail to support them and allow them to gravity feed into storage to restart the output cycle.
This should work with any blocks barring sand and gravel, even glass and ice. It may take me a couple days to complete a prototype though, this is a massive project. If anyone else wants to give it a go, by all means, let me know how it works out.
- Registered Member
Member for 9 years, 5 months, and 3 days
Last active Fri, Jan, 27 2012 18:38:11
- 0 Followers
- 5 Total Posts
- 5 Thanks
Sep 12, 2011Gorzak posted a message on Challenge - 1k block buffer for piston pushed blocksPosted in: Redstone Discussion and Mechanisms
Sep 10, 2011Gorzak posted a message on Challenge - 1k block buffer for piston pushed blocksThe design concept is this:Posted in: Redstone Discussion and Mechanisms
Pistons push blocks into a storage area that can contain a massive amount of blocks. Upon input, the storage area empties back into a piston fed stream, clearing the stored blocks.
As for the basics, I am thinking 1 piston feeds into a line of ~10 pistons, which feeds a wall of ~10x10 pistons, a typical block storage. The trick will be the triggered outlet, and feeding in clearing blocks in such a way as to empty the desired blocks. The clearing blocks will likely be gravel. It is not necessary for the clearing blocks to be removed themselves if the action of filling the storage removes them.
I'm going to be working on this, but I don't have a whole lot of time to put into it. Some of you geniuses will likely beat me to the punch, and I am ok with that.
I've started 2 projects that require this. I had the same idea as another inventor in dropping gravel/sand on trees to move their wood into a piston stream automatically. I got the automatically moving the wood part, and saw a video doing the same thing, but it is somewhat pointless unless the wood is stored, and then retrieved to be fed to a central harvesting location, otherwise you must manually move throughout the area the wood feeds to, which is as much work as chopping them down to begin with. A block buffer would do this job.
Also, I intend to bring Ice to my base. I have an ice factory going, feeding into 1 piston stream generating ice at a fair clip.... but my base is half a map away. I have reached the point where the chunks generating the ice and feeding the block stream unload, and the blocks stop coming at that point. I need a clearing mechanism to push it through. Even after I do that though, it will only be as many blocks as are in the stream at that time. Much more efficient to make a buffer at each end of the loaded chunks, and feed hundreds of blocks from one end to the other.
Is anyone up to the challenge? This buffer can be used for countless other things, storage for generated cobble to autorepair buildings quicker, and all kinds of things I haven't thought of. Who wants to make their mark on the inventing scene?
May 26, 2011This is how I do randomly wandering roots, it should work for birch or pine, but standard oak doesn't work as easily*. This method really helps you feel like you are "growing" a root system, and avoids the problem I had the first time with a surface terraformed with logs or log patterns.Posted in: Survival Mode
This shows two blocks of root going up from a top down perspective. I plant a torch at the end of the root, and 3 saplings on the other side of the root as the picture shows. Eventually one of them grows.
When I revisit, it looks like it does in the second picture, with a full grown tree above the disconnected log. I pick up the ungrown saplings, and torch, and place a log block where the torch was. I leave the bottom log, to incorporate it into my root system, and chop down the rest of the tree. Now we are back to square one, the end of a root.
I like to follow the random direction it chooses and place my torch in line with that direction, then arrange the saplings around it, the middle one in line, and one on each side. This makes roots that randomly wander over the landscape.
Random isn't always good, this shows a root that tries to circle around on itself. This is an example of this method delivering a result I am not happy with. Another example is if you wanted your root to go mostly in one direction, but wanted to incorporate some randomness. By altering the sapling and/or torch placement, can bias or limit its possibilities without just placing roots arbitrarily where you want them to go.
I tried out doing it like this, but felt it made turns too densely and quickly. Your milage may vary, but I found extending the root in 1 block the direction it chose made it look better.
*For Pine and Birch, when one tree grows it excludes the rest of the saplings. With birch I have seen 2 grow when one is short and the other is tall and they are 2 apart, I figure thats a good place to fork out into 2 roots. With oak, the other trees arent excluded, just limited to using the 10% (33% rain forest) big tree growth algorithm. If there isn't a solid trunk shortly above it, the oak sapling will eventually grow. If you check frequently this method can still work with oak, but if the saplings are given excessive time, you may find all have grown.
- To post a comment, please login or register a new account.