Automatic Tree Farm Discussion

[JammerUno]

Very nice design, inspired use of gravel.

You could probably fix the sapling issue by shifting up the dispenser and shooting them into a shute directly over the hopper, they should all hit thesame target down below then. One could also replace the bottom BD with two pistons (piston-gravel-dirt-piston setup) and shift in the gravel at the start of the harvesting cycle to save on BDs.

[SterlingRed]

And here it is:

-snip-

You win an internet for the week. Thats quite impressive. I couldn't tell exactly how the cobblestone clock worked but it appeared that the system attempted to push the gravel stack up multiple times after all the logs had cycled through. This delay could be eliminated I think since you have a known stack height it should stop after pushing gravel to x height and then reverse. It could speed things up just a tad.

I've always wondered what a good way to transport a tree from the growth location to a mill would be since I never really liked the inefficient/not so aesthetic stack of saws against a tree method. This is quite brilliant. Looks like after I finish my current project, I know what I'm doing next.

[ServantOMallard]

After watching this I've decided to give it a go but instead pushing the wood downwards. Thanks for the inspiration, I had never thought of this sort of thing before!

Nath

[Robilar]

And here it is:

-snip-

Holy dung on a doughnut, that's amazing. I don't imagine you just kind of plopped the design down and it worked, but that's far more advanced piston mechanics than I could understand, given I don't have any experience with them (I just updated to 1.7.3 yesterday, I stayed in 1.6.6 for Millenaire). I believe I learned four redstone tricks just by watching that video (I even recall exclaiming as the piston pushed the glass block into the circuit to break it "You clever bastard").

I think it's a bit beyond my current skill to replicate, since I barely comprehend it, so I'd love a copy of it on a test world (feel free to tell me that it isn't happening, I'll just learn as much as I can from the video) so that I can dissect it and better get an idea of what's up.

To further compliment the design, I usually hide my devices as they tend to be rather ugly, since I'm a rather ineffective redstone user, but your design is actually very aesthetically pleasing. Watching the pistons push the tree right out of the leaves and then being pushed away into a sawmill (which I was expecting to be very simple, I was incorrect) is both entertaining and very pleasing to someone such as myself, who loves mechanics.

All in all, aside from the sapling launcher (which is clever *and* entertaining, even if it isn't perfect) losing some saplings, I can't bring myself to give this anything short of a 10/10. Bravo good Sir (or Madam), Bravo.

[Adjudicator79]

Yeah, so, given my automation of hemp, wheat, reed, slimes, and mobs so far, trees and dung are next on my list.

Since this has become the generic automated tree farm discussion thread (which is a good idea, I think. We should have a comparable thread for all of our automated farms), I'm soliciting designs! I'm looking for easy to build with small footprint. I'm happy to build multiples of it to get enough wood, but I can't undertake something like finite8's work. I simply don't have the time to put into Minecraft that this would require. I want something that might take an hour or two to build and, once built, I could duplicate in half that time.

Suggestions?

[ServantOMallard]

Definitely nothing like finite8's stuff then, the footprint is pretty big! Although slightly compactable using turntables.

[finite8]

The footprint could be smaller using smarter redstone logic. The key limitations are though:
- cannot have anything above the 2 block line above the Sapling. Anything there i found prevented the tree from growing. That's why i couldn't have a water channel to push saplings into the hopper, nor could i put anything up the top to drop them straight down into it. Perhaps if i adjusted the angle from where the Sapling Planting BD was, i could have it so that the flow from where the saplings is coming from did not get in the way of where the trees are being pushed away.
- Going down wasn't an option. If you go down, you can't get the blocks you used to push down out of the way. That's why going up using Gravel was ideal as it fell back down when it was time to get rid of it, and the sticky couldn't hold the gravel so the material i used to push the tree up didn't get caught in the Milling line (and thus, break the saws).

Yeah, apologies for the overcomplicated Redstone. Being my prototype, i kind of just did the components "so it worked". If i rebuild it, i think i can do a better job with the lessons learned (i.e: the messy Axle Layouts). Mainly, it is a proof of concept to see if i could have a self-replenishing and harvesting tree farm... which it is. The timing with the pushing up and back down again can be improved as i originally had timing issues between (1) the tree trunks being pushed up, (2) being picked up by the sticky up the top and pushed away, and (3) with it being pushed into the mill for processing. Now that (1) and (2) are in sync using the same clock, it isn't a problem so the extra cycles on the push-up cycle aren't needed.

I was lucky with having the entire system turn off when there was no tree to collect. Was a bit of a lucky fluke with the design that i did that by shutting off the gears when the Detector couldn't see anything. Wasn't a part of the original plan.

I'm still not happy with the Mill process so i may change that later. It is too random with what is produced between the Panels, Moulding, Corners and Gears. There is too much of a Bias towards Gears based on pure probability so i need to tweak this or redesign somehow.

Anyway, Glad you all liked it! I'm hoping for some more inspiration to improve it further. Now to make it all pretty (with a lift to move between each of the "Factory" floors) and then it is off to build my Epic Mob + Slime Extractor :)

[gftweek]

I've thought it over, and figured more out about how it works. I must say it's a great idea as it leaves plenty of space around the tree so it can grow more often, and I see why you used pine, since they never have branches.

I'm going to try building a similar design, except I'll try and integrate the piston control logic into the gravel stacking list, so it knows when to stop without requiring a timing/counting circuit or the sticky piston, then it can just start reversing immediately and replant more quickly. I'll also try chaining 3 together (pushed logs probably need to meet in a T so they can grow in any order, rather than in a line).

I think I have some ideas about how the wood processing section works, I'm guessing timing of pistons/lifts randomly splits processed items between going to storage and back into the BD that places blocks for sawing.

[finite8]

I've thought it over, and figured more out about how it works. I must say it's a great idea as it leaves plenty of space around the tree so it can grow more often, and I see why you used pine, since they never have branches.

I'm going to try building a similar design, except I'll try and integrate the piston control logic into the gravel stacking list, so it knows when to stop without requiring a timing/counting circuit or the sticky piston, then it can just start reversing immediately and replant more quickly. I'll also try chaining 3 together (pushed logs probably need to meet in a T so they can grow in any order, rather than in a line).

I think I have some ideas about how the wood processing section works, I'm guessing timing of pistons/lifts randomly splits processed items between going to storage and back into the BD that places blocks for sawing.

The only way i could figure out how to detect that Gravel had reached the top was to check and see somehow that the sticky piston hadn't held the block before the normal piston pushed it out of the way, or that the flow of trees had now stopped. Either one i couldn't be stuffed fitting the required redstone circuit and lines into my design so I'm keen to see your solution to it (I may steal it if it isn't too hard).

Chaining 3 together would be pretty straight forward however, you may find that the intersection would fill up, meaning that your attempts to push the trunks up out of the growing area may get banked up and have nowhere to go. If you can't detect the difference between gravel and a trunk, your circuit may not know that it still needs to keep pushing and thus, your next grow cycle will fail (because you will still have a tree trunk in the trees growing area.

And the wood processing area is a bit tricky. I have two pistons push cobblestone together UNDERNEATH the saw. I anticipate that 50% will go one way, and 50% will go the other assuming an even distribution of where the cut pieces land on the block below. From this i expect half to go straight off for collection, and the other 50 to be fed BACK into the platform and mill process to be cut again thus, one Saw is automatically used to process Wood->Panels->Moulding->Corner->Gears. It is also because of this that Gears are over biased.

Ideally, i would have 75% go straight to storage and 25% go though the process again... but i have NO idea how to achieve that kind of precise selection control with the limited space i had. Perhaps using two hoppers partly filled with clay and one of them having 4 slots available and the other only 2 would provide a 75/25 balance. When both register full, the 25% one empties its contents back into the mill while the 75% one feeds straight into a chest.

[gftweek]

I have no idea if it will work, but I'm imagining using 3 pistons a DB and a BD to stack up the gravel/sand.

The DB will face opposite the BD and detect if there is gravel there or not will be hooked to a T-flip-flop that will control whether the gravel is on it's way up or down.

BD will pulse to output or suck in gravel depending on what is already in front of it, and two pistons will shuffle the gravel left or right towards or away from the up-facing piston (still not sure exactly how you did this, so my design might fail right here), again depending on the state of the flip-flop.

Once the gravel is all been sucked in again the dirt block will be replaced and a new sapling planted once the DB detects the gravel has been removed.

I'll mock up a test world and try this when I get home and post a screenshot, either showing if it works or asking for help!

[finite8]

BD will pulse to output or suck in gravel depending on what is already in front of it, and two pistons will shuffle the gravel left or right towards or away from the up-facing piston (still not sure exactly how you did this, so my design might fail right here), again depending on the state of the flip-flop.

The Gravel Piston setup:

SP} * * [BD
^P C


SP} = sticky piston facing right (SP)
^P = Normal Piston Facing UP (P)
C = Cobblestone
[BD = Block Dispenser facing LEFT (BD).



When pushing Gravel up:
- P Retracts
- SP extends (immediately after P retracts so gravel doesn't fall down.
- BD Sucks in block (should be nothing there, so nothing happens).
- BD Places Gravel
- SP Retracts
- P Extends

When lowering Gravel, P is NOT USED and is locked in Retracted position.
- SP Extends.
- BD Pulses from ON to OFF. ON will do nothing as a block is already in front of it. OFF will suck in Gravel.
- SP Retracts.

Therefore:
Mode Raising:
- Normal Piston is active.
- BD's signal is set to the same as the Sticky, but with a delay so that Block is placed AFTER it is extended, and air is consumed AFTER it has retracted with the gravel.

Mode Lowering.
- Normal Piston is inactive.
- BD's signal pulses from on to off quickly AFTER the Sticky has extended. The ON does nothing as Gravel is already in front of it, and the OFF will then consume that Gravel.

If you are not familiar with a piston used to create a pulse, i will show you one in action.

[ServantOMallard]

I've managed to get a downwards pushing version working (sort of) I just need to sort out a sticky piston arrangement to retract the top piston when it's not needed e.g when a tree is growing; as at the minute this is messing with the tree growing sequence so it doesn't grow. I have to say finite, how you got the footprint anywhere near that small is beyond me! This thing is huge!

My question is this, I know you can't have anything over 2 blocks higher than the sapling but at how many blocks high do these stop affecting the growth?

[gftweek]

I guessed it might be something like that. I'm was planning to amend it to this:

Code: Select all

P} * * BD{P
  ^P C C

With BD behind one space (away from us). So BD places block in front of right hand piston, then right hand piston and lower lifting piston fire in a similar sequence to your BD and lifting piston. In the down cycle the left hand piston fires instead of the right hand piston and the BD sucks them back in again.

There is a DB opposite the BD (towards us) which detects the presence or absence of a gravel block, and triggers a T-flip-flop when the gravel disappears (either last one is sucked into the BD, or last one is pushed away to be lifted. The T-flip-flop changes between the up and down cycles.

Been experimenting for 3 hours now, the timing is a nightmare. Basically I ended up replacing your piston timing chain with redstone and it just got too complicated. The up cycle and down cycle both work perfectly by themselves, but getting them to trigger the next stage reliably and reset correctly isn't working yet.

I think part of the problem with my system is that I'm using turntables for timing and as a flip-flop, but because of the delay with gearboxes switching on and off, they are overshooting on occasion, I might try pistons instead as they are faster to react to redstone changes, this should simplify my timing and logic circuits a bit.

[Thalmane]

Ideally, i would have 75% go straight to storage and 25% go though the process again... but i have NO idea how to achieve that kind of precise selection control with the limited space i had. Perhaps using two hoppers partly filled with clay and one of them having 4 slots available and the other only 2 would provide a 75/25 balance. When both register full, the 25% one empties its contents back into the mill while the 75% one feeds straight into a chest.

You could use a turn table with 3 red stone torches. So for 12 secs you'll send a signal and for 4 it won't. So when the 4 seconds of no signal comes a DB sucks in a block under the waterway allowing wood to goto your processing area amd the other 12 seconds itll just goto storage. I don't see it being 100% accruate on the division of the logs but you just avg out over time tp the 75/25 you want.

[BigShinyToys]

i dont know how big this would be but it might make youre 25% 75% bit work accuritly.

if you have the line of wood blocks have three pistions facing one way and one facing the other direction then when a BD sees a block it trigers the pistions to push 3 onto one side and 1 the other way. these lines would then be pushed sepriatly. one to storage the other to milling

[AgentPaper]

For a non 50-50 chance, just have the processed items flow down a stream, which has two hoppers under different parts of it. The first hopper has a piston that sometimes extends over it, causing the items to flow past to the second piston. Then, to control the percentages, simply have the piston be extended or retracted for different amounts of time. Note that the piston needs to be extended at least long enough for the items to flow over it, though.

[finite8]

if you have the line of wood blocks have three pistions facing one way and one facing the other direction then when a BD sees a block it triggers the pistions to push 3 onto one side and 1 the other way. these lines would then be pushed sepriatly. one to storage the other to milling

It's not bad. The catch however is that:
- Once you have the three pushed down into one new direction, there is no easy way to then push them out of the way. They joy of a single flow line is that a single stream is easy to control and add to. Having to them move 3 blocks out of the way along a line to make room for another three is really messy. It can be done by using sticky pistons to push another pistons that in turn pushes it all in the direction we want, but that adds some massive redstone overhead i didn't really want to deal with.
- Avoiding pushing them out of the way, you could instead just have a Saw for each block. While this works, it again adds a messy Axle overhead my current space and design couldn't afford.

The original plan i had was to have a separate milling process for each stage... Wood-> Panels, Panels -> Moulding, etc, but it got too complex and took up too much space.

The way i have cheated is i got the whole system working with only 2 saws. One to get the Wood planks in the first place and another to saw the Wood planks down to Panels, moulding, corners and gears.

Actually, the more i think about it, the easier the idea is getting. Maybe V2 will include this design idea. Obviously, my mill has 2 main sections, the Plank section and the Recycling section. If the recycling section just took any input from a Dispenser, put it into a line of 4, pushed 3 into their own Saw that deposited their contents into a chest while 1 is pushed into a different saw that fed back into the dispenser, i could get it to work.

Sir... you make my brain hurt with ideas.

For a non 50-50 chance, just have the processed items flow down a stream, which has two hoppers under different parts of it. The first hopper has a piston that sometimes extends over it, causing the items to flow past to the second piston. Then, to control the percentages, simply have the piston be extended or retracted for different amounts of time. Note that the piston needs to be extended at least long enough for the items to flow over it, though.

Not bad. As an alternate approach, in the section where i use pistons to effectively squash the loose items (thus pushing them towards the closest adjacent air block), i could also have ANOTHER piston block access to the Recycling side 3 out of every 4 pulses. In theory, this would allow fine grained control over the recycling flow. This may be a better solution using my current design. Hopefully, i don't end up with Items stuck in blocks or pushed in weird directions (like having a Mill Block with all but 1 side covered. You would think this would force it to spit everything out one side, but it doesn't. Sigh.).

[BigShinyToys]

I see the problem with the three one way 1 the other system .
so here is my second attempt.
you have one piston set up to push left and on to push right. The difference it you trigger one 3 times more than the other. ( using a turntable possibly ) I have almost finishes the clock i have been working on . after that I'm making one of your gravel tree growers.( for lack of a better name )

[finite8]

I see the problem with the three one way 1 the other system .
so here is my second attempt.
you have one piston set up to push left and on to push right. The difference it you trigger one 3 times more than the other. ( using a turntable possibly ) I have almost finishes the clock i have been working on . after that I'm making one of your gravel tree growers.( for lack of a better name )

Coolies. Good luck.

If you also make a sapling recycler, let me know how you go. I'm keen to find a way to improve on my current design.

[petrus4]

I think it's a bit beyond my current skill to replicate, since I barely comprehend it, so I'd love a copy of it on a test world (feel free to tell me that it isn't happening, I'll just learn as much as I can from the video) so that I can dissect it and better get an idea of what's up.

You can massively reduce complexity, if BTW by itself, isn't the only mod you're using. You can get Eloraam's Red Power, and use one of his integrated timers, to get rid of all the naked redstone. Also, while the Block Dispenser will work for planting, I had to get ToggleBlocks in order to be able to do automatic tree fertilising with BTW's Foul Food, because the Block Dispenser won't do it.

ToggleBlocks is a great compliment to the Block Dispenser. There are things that TB can do that the Block Dispenser can't, (such as outputting Foul Food, and I've also used it to give my Nether Portals an on/off switch, which I wanted to do because I have a Portal in my main workroom, which is convenient, but I got sick of the constant noise) but there are also other things which the BD can do that TB can't, (TB is primarily focused on output; the BD is able to accept/suck in input, such as wheat, hemp, etc) as well, so they work very well together.

BTW's Foul Food is a fantastic form of fertiliser. There are initially a few extra steps, when compared to bone meal, but once you've got production set up, it's possible to generate large quantities a lot more quickly, (using Flour) than if you're having to farm skeletons. This is mainly because, even if you find a spawner, you'll still likely have only one; whereas BTW's Mill Stones, Cauldrons, and wheat fields can be duplicated as much as you want.

I'm also actually using the Planter and Harvester from Faenor's MineFactory. Having to build a stack of saws right next to your sapling, reduces fertiliser efficiency, because while they eventually will, trees don't like to grow with pillars immediately next to them. The Planter is also good, because you can put that one block below ground; which again means that the sapling doesn't have more than a single block (the Harvester) next to it, to reduce the chance of it growing immediately when fertilised. I get a 100% fertilisation success rate, as well as full reclamation of saplings. Then because I've also got BuildCraft and Pfaeff's Allocator, I can run a sapling-filtered underground pipe between the collection hopper that I've got attached to the harvester, and the planter, which means that my saplings go straight back into the planter as soon as they are received.

Overdesigning might be fun, but consider that if parallel duplication (running a lot of instances of a given machine at once, to increase output) is one of your goals, simplicity is going to make that a lot easier, than if you're trying to duplicate something gigantic. Simplicity has other benefits as well; if something breaks, with a simple design it's a lot easier to isolate problems and fix them.

http://www.catb.org/esr/writings/taoup/ ... #id2879078

As I've already said, I love Better Than Wolves, and use it when it is appropriate, (which truthfully is pretty much all the time) but I also find that there are certain things which BTW doesn't do particularly easily on its' own. So for such situations, I get other mods as well, to fill in the missing pieces.

[gftweek]

I've redesigned my interpretation of finite8's gravel harvester. It's still in development, so I'm cheating with items and building it in a test world.

The timing of the BD and piston firing was getting too complicated using turntables, since they have the delay when turning on and off, so I started again.

It's got a bit of work to go, but I think I can reduce the footprint a bit by using pistons for a T-flip-flop and timing, and using the stack of gravel itself to control when the tree has all been pushed into the processing conveyor.

Once I get it working reliably, I can post the world for others to play with.

[finite8]

I've redesigned my interpretation of finite8's gravel harvester. It's still in development, so I'm cheating with items and building it in a test world.

The timing of the BD and piston firing was getting too complicated using turntables, since they have the delay when turning on and off, so I started again.

It's got a bit of work to go, but I think I can reduce the footprint a bit by using pistons for a T-flip-flop and timing, and using the stack of gravel itself to control when the tree has all been pushed into the processing conveyor.

Once I get it working reliably, I can post the world for others to play with.

I slightly modified my original design.

Now, there are only two timers in the entire system: the Tree Extraction Timer and the Wood Mill Timer (As it will need to continue for an unknown period of time after the tree has been harvested).

Harvested trunks are pushed immediately into a saw. A Monostable Circuit with a short pulse is used to push the trunks extracted (along the top line) down into a Saw which then gets pushed into the main Mill cycle as required.

Sadly, careful timing is everything. I tried using a shorter Turntable timing which as expected, doubled the extraction speed. It did however result in random stuff ups such as the top sticky piston grabbing the Gravel and the Horizontal piston pushing it before it had dropped back down or worse... the Gravel is pushed up into the empty space made by the sticky BEFORE the gravel drops down thus either placing the gravel on top of the whole stack (Bad as the gravel will then get pushed on top of the hopper and not only prevent it from being refilled, but stops the tree from growing) or breaking a gravel block (Long term bad as the system would eventually run out of Gravel) messing the whole system up.

For the record... long term tests have proven that the Sapling recycle process works well. You just need to make sure it is reasonably well stocked up to begin with so no single space in the dispenser empties otherwise it will pick up the trunk when the harvest cycle begins.

[finite8]

Also, thank you plats98. I too encountered that Saw Breaking issue that did quite a lot of damage to my setup. Had to slow down the mill process to prevent it from happening. I was going to try to reproduce, record and report it when i saw your post. As a safety measure, i have placed Obsidian under the water where the piston pushes towards so that it the saw does break, it doesn't damage everything else.

Learn From My Fail: ALWAYS use obsidian at the end of a Piston Line unless you are working on the Maximum piston push distance or have an Entity Block at the other end (chest, Dispenser, Hopper, etc). If something screws up, the Piston will keep pushing and may do a lot more damage than you realise.

[Battosay]

You can use a chest of a furnace too, it's cheaper, and the piston can't move it either.

[finite8]

You can use a chest of a furnace too, it's cheaper, and the piston can't move it either.

Yeah. Any block that has Inventory (or an extended Piston) will work... but not as pretty.