04 Why Your Tree Farm Is Slow — Introduction to High-Speed Tree Farms
Barring any surprises, the tree farm you designed in the previous chapter probably tops out around 10,000 efficiency, with processing cycles easily stretching past 30 or even 40gt.
What's causing this? Let's break it down.
1 Before We Begin — 0-tick
In 1.1.2, we mentioned that Minecraft's timing is divided into inter-tick timing and intra-tick timing. If we can move functionality from inter-tick to intra-tick timing, we've successfully sped up a tree farm. The most important way to do this is through the piston action and wiring pattern known as 0-tick.
1.1 The Concept of 0-tick
In 1.1.2, we also mentioned:
BE components (pistons and note blocks) execute operations in the order they receive updates confirming state changes. This order is sometimes called depth. Note blocks do not increase depth (i.e., they don't delay the execution order of objects they update within BE).
So imagine a piston:
At 0gt BE, it receives a rising edge signal at a certain depth. After it extends, it receives a falling edge signal at a deeper depth (deeper means later in the BE execution queue).
Obviously, it should extend when powered and retract when depowered. This completes a 0-tick action. Specifically, for sticky pistons, the first block it pushes arrives one piston depth deeper than the falling edge signal, while pulling behaves normally.
In fact, using piston-added depth as a depth unit isn't precise. Due to differences in piston push order, you can actually create depth differences smaller than "one piston" by creating b36 order during extension. Sometimes "coral" is used as a unit (because the most widespread use seems to be in coral-based TNT duplication). This is occasionally useful, but doesn't have a major impact on overall wiring.
1.2 Common 0-tick Generators
The idea is very simple: before BE ends within the same gt, give the piston a rising edge at an earlier point and a falling edge at a later point, and we get a 0-tick action.
For example, here's a very classic 0-tick generator based on the execution order difference between comparators and repeaters in TT:
Since repeaters generally have priority over comparators, at 2gt TT, BE gets added to the 0-tick piston first, then to the depowered piston. So the depowered piston must act later than the 0-tick piston, thus creating a falling edge signal that comes after the 0-tick piston extends, completing the 0-tick.
Here's another very classic 0-tick generator based on Redstone Dust (hopefully you still remember that Redstone Dust is instantaneous):
At 0gt NU, the redstone block is placed. At 1gt BE, the sticky piston removing the wire-pressing block moves. Since the sticky piston removing the redstone block is quasi-connected (QC'd), BE only gets added after the sticky piston removing the wire-pressing block updates it, thus creating a rising edge at 1 piston depth and a falling edge at 2 piston depth at 1gt BE. This signal is enough for the powered piston to complete 0-tick. Of course, you can also add depth to the falling edge through more QC pistons updating along the way, thereby activating pistons at the output end that can only be QC'd and are updated by other pistons.
Note that Redstone Dust turning only triggers PP updates. We need additional NC updates to the target piston being powered to complete the rising edge signal (that is, for pistons, rising edge and falling edge signals actually refer to receiving NC updates and confirming the need to extend or retract).
Actually, the 0-tick here refers to the depth at which the normal piston updates the sticky piston, not the depth of the Redstone Dust turning (although there's no big difference here).
2 "Base"
For high-speed tree farms, we need to design bonemealing, detection, trunk processing, and sapling cycling as an integrated unit, called the base.
2.1 Trunk Processing
This time we need to choose the trunk processing mode first.
In 1.2.2, we mentioned:
Trunk processing generally has four methods: processing together with the trunk, upward push, downward suction, and side suction.
If you think about it, processing together with the trunk means we can only use one dispenser for bonemealing. With upward push, we can plant trees at the earliest at 6gt of tree farm operation. Downward suction gets us to 3gt, and side suction can be as fast as 0gt. In high-speed tree farms, we generally choose downward suction or side suction.
@Scorpio 天蝎君
Side suction:
@Qonctrol, Dreaming_Galaxy, BFladderbean, Feng_Bl PUTF std2
Since player operations happen in the NU phase and dirt returns to position in the BE or TE phase (at the end of the gt), we can plant trees in the same gt that dirt returns.
In fact, upward push has problems beyond just slowness. Remember that jungle trees can grow up to 12 blocks tall? Including dirt, that exceeds the piston push limit. And remember acacia side branches? Upward push can result in up to three logs at the same y-level, greatly increasing processing difficulty. That's why upward push is now basically abandoned.
2.2 Bonemealing and Sapling Cycling
Although Scorpio really wants to explain the bonemealing mechanism, I don't think it's necessary, because bonemealing in high-speed tree farms essentially means stacking dispensers. Simply put, don't worry about bone meal consumption. Place as many bonemealing dispensers as possible to increase the number of pre-bonemealing cycles between when the player plants the sapling and when it can grow, and to widen the growth window after the sapling can grow (this is why we introduce cross bonemealing, which staggers when dispensers fire bone meal, generally by 2gt).
@PUTF std2
@Scorpio 天蝎君
Self-explanatory cross bonemealing/synchronized bonemealing switching device diagram.jpg
The biggest problem high-speed tree farm bonemealing structures actually face comes from sapling cycling. Crowded base space causes the bone meal supply chain and sapling cycling hoppers to constantly clash. Generally, we design the bone meal supply chain to be as neat and compact as possible, leaving more space for sapling cycling. In fact, there's nothing that can really be written into textbooks; you just have to do it yourself a few times.
An example of a very compact bone meal chain:
@Islyric, Qonctrol, BFladderbean PUTF+
You can see that even a very compact bone meal chain still gets packed with other components.
For sapling cycling, since Mojang's annoying random changes to leaf drops caused leaves dropping sticks, we need more droppers to handle the large quantities of items. We also need to "straighten" the hopper chain as much as possible and adopt a zoned collection strategy to maximize item transfer efficiency:
@Chuo_di, Islyric, Qonctrol, BFladderbean, Sarumi_QAQ PUTF std2c
In fact, sapling cycling is also affected by the trunk and leaf processing architecture. For high-speed tree farms, you sometimes need to add hoppers and hopper minecarts for collecting saplings to the trunk and leaves processing wiring.
2.3 Push-Limit Detection
This is a push-limit detection unit made by Bright_Observer
When the upward-pushing piston is updated during the TT phase, it plans its push. When a piston plans to push, it checks whether it has reached the push limit. At this point the glass above hasn't retracted yet. If the lever is pulled down and the piston extends, it will be unable to push. This activates two normal pistons, which update to the sticky piston during the BE phase. The sticky piston self-checks again and extends. If the lever is released, everything proceeds normally: the sticky piston extends normally, whether the upper of the two normal pistons extends depends on orientation, and due to depth influence the lower piston never extends. This completes the detection. — GTMC Timing Theory 5.10.1
In summary, this unit runs at an 8gt cycle. To align with the cross bonemealing clock, we can stack four layers of this unit, each staggered by 2gt, place them under the dirt, and connect them with slime block linkages. This gives us a detection module that takes up almost no dispenser or other wiring space. \Magic Detection/
@Islyric
3 Core Architecture — Trunk and Leaves Processing
This is the part that determines the minimum operating cycle of a tree farm. Think carefully about this.
Before designing the architecture, we first need to understand how to analyze an architecture's timing.
3.1 Timing Design
For a given architecture, we need to analyze how it processes trees and design the shortest possible timing.
Taking the PTHSUTF architecture as an example, let's try to design the shortest processing timing for acacia (review processing principles in 3.1.2):
@Fallen_Breath, CCS_Convenant
0gt Main push and side wall first level extend Perform first-level centering on all side branches
3gt Main push and side wall first level in place, main push second level extends Let main trunk direction side branches center first to avoid conflicts
6gt Main push second level in place, left side wall second level extends Center side branches still not pushed out to the center and right one block
9gt Left side wall second level in place, activate main push third level and begin retracting, making main push third level 0-tick; then, right side wall second level extends Clear side branches located in the center and center side branches in the right one block to the center
12gt Right side wall second level in place, activate main push third level and begin retracting, making main push third level 0-tick Complete processing, begin reset
15gt Main push second level begins retracting, side wall first level begins retracting
18gt Main push first level begins retracting
21gt Reset
In tree farms, we can generally think of time in 3gt units, although this isn't strictly correct. In fact, this architecture's acacia timing only needs to satisfy: at 6gt the first side wall second level extends, and at 9gt one side wall retracts while the other extends, to complete a 21gt reset. This isn't the only timing design method.
Try designing the timing for TT1998's 6gt jungle architecture (Note: the image below is an architecture modified by @大尸凶一只, but it doesn't affect timing analysis)
First layer:
Second layer:
(Here we only analyze the trunk processing and "redstone block wheel" timing):
0gt Side pseudo-double-recursion first level 0-tick, then second level 0-tick, extracting the log in front of the front pseudo-double-recursion; then the front pseudo-double-recursion pulls away the log at the trunk position; redstone block wheel first piston extends, activating the leaves processing piston on the other side, then the second piston extends, 0-ticking the leaves processing piston and activating the trunk processing piston, finally the third piston 0-ticks to retract the redstone block, 0-ticking the trunk processing piston
3gt Two pseudo-double-recursions first level 0-tick retract; redstone block wheel last piston 0-ticks to retract the redstone block
6gt Reset
Performing timing design on a given architecture is very useful for wiring. It also helps you understand where the culprit behind a long operating cycle is, enabling targeted optimization.
3.2 Architecture Design
If timing design on existing architectures still doesn't get you to the speed you need, you need to design faster architectures.
Here are two classic approaches to speeding things up:
- Nutstory architecture: In 3.1.2 we mentioned that acacia side branches can be handled not only by centering but also by increasing log output. Now that we've learned timing analysis, you should notice: this architecture doesn't need timing for side branch centering, so it can run at 12gt, much faster than the PTHSUTF architecture.
@Nutstory
- TT1998's 6gt/Shixiong's 4gt architecture: They're actually the same architecture. We've already done timing analysis above. Additionally, at 4gt, the second-level piston of the pseudo-double-recursion has already been removed and created b36 at the target position, so saplings can grow normally. As long as we build another pseudo-double-recursion on the other side and solve the sapling problem, we can easily get a 4gt tree farm.
First layer:
Second layer:
In fact, designing faster architectures comes down to a simple idea: reduce piston actions that must occur at different macro timings. Be sure to think about the corresponding timing while designing the architecture, otherwise you'll easily lose track of what you're doing.
In fact, timing and architecture design also have their exceptions. yunj's STFU is an 8gt all-tree-species tree farm, with some architectures not running on 3ngt timing.
But since we now have 4gt tree farms, we don't need to worry too much about this
For side-branch trees, we don't need to obsess over the minimum operating cycle; we can instead increase side branch processing capacity.
You can totally build a 12gt cherry blossom tree farm that outperforms certain 6gt ones
In summary, an excellent architecture is the most important prerequisite for a good tree farm. Before starting wiring, optimize your architecture as much as possible.
4 Wiring
4.1 Wiring Methods
Let's look at the simplest and most useful high-speed tree farm wiring method:
This is a very classic double-edge 0-tick generator based on Redstone Dust and depth (i.e., both rising and falling edges of the input signal get converted into a 0-tick signal). We can connect a sticky piston to its output, pushing and pulling a redstone block, to get a signal with the same macro timing as the input that doesn't increase macro delay but has a deeper rising edge. Using this, we can easily control wiring depth: just connect the Redstone Dust that activates pistons in sequence, following the designed depth order in the same way.
Classic example based on this wiring method
4.2 Wiring Inspection
Although we keep saying "economic base determines superstructure," we can't design a 6gt architecture and end up with wiring that runs at several dozen gt, can we? Analyze your wiring and see exactly where the timing problem is that's dragging down the overall tree farm speed.
However, for high-speed tree farm wiring, we can't give you a more specific method. The best approach is to study and wire a few yourself.