Automated Blaze Grinder (r7)
 | |
| Location | |
|---|---|
| Server | PvE |
| Map revision | 7 |
| Coordinates | 158, -180 |
| Creators | |
| Contributors | totemo |
| Timeline | |
| Started | 2012-02-23 |
Introduction
totemo designed and built this blaze grinder on PvE revision 7 for public use. The design was loosely based on Ethos's Blaze XP Farm, but departed from Etho's design in an attempt to address perceived deficiencies when implemented on a server. Specifically, it was observed that when Etho's design was constructed on revision 6:
- Sometimes, the blocks (pushed by sticky pistons) that concentrate blazes in the centre of the trap would get stuck in the extended position (if the piston was only powered for a single tick), and
- Redstone repeaters would frequently get stuck in the "on" state. This was apparently due to redstone not updating properly after a server restart. That is, redstone had to be quiescent immediately prior to a restart in order to avoid problems.
Model A
Operational Principle
Etho's grinder is shaped like an upside-down pyramid, built around the spawner. When blazes contact pressure plates inside this chamber, sticky pistons push blocks, which in turn push the blazes towards a central 2x2 drop shaft at the apex of the pyramid. There, they are crushed with pistons down to a low health so that they can be punched to death for XP. An important principle of the design is that undamaged blazes should be kept separate from those that have been damaged by the crusher, so that the number of hits required to kill all blazes is the same. To this end, the spawning chamber is separated from the crushing/punching chamber by a gate.
When you remove the moving blocks and use non-sticky pistons to push the blazes, they can get trapped inside the piston extension. Since they are standing on the pressure plate, the pistons stays extended, and the blaze is stuck inside it. To address this problem, totemo's design omits the plates and instead uses a clock signal to extend all of the pistons and push the blazes toward the central drop shaft at regular intervals. Whereas Etho's spawning chamber is 8x8 at its widest point, and has 3 tiers (8x8, 6x6 and 4x4), totemo's design uses a numerically odd width for this chamber, with just two tiers of 5x5 and 3x3, and a 1x1 area for the drop shaft. It is unclear to what extent the smaller size of this chamber impacts the spawning rate of blazes.
Structure
Model A was comprised of the following components:
- The spawning chamber and pushing piston assembly.
- Clock circuit.
- Gate - an iron block moved by a sticky piston, above the chamber where blazes are crushed.
- The crusher block - an iron block pushed into the blazes by a sticky piston.
- Fire shield - a glass block that prevents the blazes from shooting the operator.
- Clock enable lever.
- Operator detection plates.
The gate and fire shield were controlled by the same lever, shown on the right wall in the overview image. When the gate was open, allowing undamaged blazes into the chamber, the fire shield was closed, and vice versa. The crusher was controlled by a lever. It was up to the operator to estimate how long to crush the blazes so that their health was sufficiently low to easily kill. This was typically a count of 15 damage sounds.
Since continuously running clocks load the server for no benefit, the clock that drove the pistons in the spawning chamber was only active when both the clock enable lever was switched on and an operator was standing on the stone pressure plates. The clock circuit consisted of a minecart on short rail loop which went up two blocks and had a downward slope of two blocks made from gold (powered) rails. The gold rails were only powered when the clock was active (enable lever on and operator present). In the inactive state, the cart would come to rest on the slope. When activated, the cart would roll down the slope, accelerated by the powered rails, and pass over two separate detector rails that would activate the pushing pistons at different phases of the clock cycle.
Using a rail-based clock avoided issues with stuck repeaters. However, this setup was still vulnerable to getting stuck if the cart was moving during a server restart. The pushing pistons required signal repeaters to boost the redstone signal. However, the use of compact repeaters was avoided in favour of old-style repeaters made from blocks and torches.
First look: rail-based clock circuit to the left, controls and spawner centre
Close up of the rail loop
Operating instructions
Spawning chamber and pistons
Blazes falling into the crusher
Model B
For a time, minecarts were disabled on PvE, following the discovery of a duplication glitch. When they were finally re-enabled, they had been rigged such that the rider always entered the cart upon placing it on the rails. It was no longer possible to use riderless carts as a timing mechanism. Somewhat reluctantly, the timer was redesigned to use a chain of redstone repeaters.
The most difficult aspects of this redesign was creating a clock circuit that would only run while a "clock enable" input signal was high (on). The clock circuit that was used is pictured below:
Full clock circuit showing inputs, outputs and repeaters
Loop gate assembly
The second image - the loop gate - starts the clock when the "clock enable" input signal goes from low to high, and the clock pulse continues to circulate around the chain of repeaters only while the "clock enable" input signal is high. Examining this second image more closely:
- The "clock enable" input signal enters from the left of the frame.
- It is inverted by the torch that is mostly obscured behind a sandstone block, and finally is delayed by the single visible repeater.
- These two signals - the "clock enable" input and the delayed and inverted version of it - are ANDed together. The resulting signal, just below the workbench in the image, means "if the clock enable was off AND is now on". So this circuit detects when the clock is first switched on.
- The other AND gate combines the unmodified "clock enable" input with the redstone pulse after it has circulated through all of the repeaters, entering the AND gate from below the bottom of the frame. The output perpetuates the clock signal only while "clock enable" is high.
Design Review
Pros
- Very few sticky pistons were used. In this regard, the design was both cheaper (slime is initially very scarce) and more reliable (since blocks can get stuck in the extended position, but non-sticky pistons can't).
- Minimal use of repeaters. However, stuck repeaters didn't seem to be the problem that they were in the clone of Etho's grinder that someone built in revision 6. This may have been due to the signs warning people to turn off the clock prior to a restart, or it could simply have been that the grinder wasn't used that much.
- The redstone circuitry in Model A was very simple.
Cons
- One block width of the spawnable area around the spawner was obstructed - it is 8x8, but the spawning room was 7x7.
- Blazes not in the crushing chamber were not moved 8 blocks away (down) from the spawner. Doing so would have allowed unlimited blazes to accumulate and may have improved the spawning rate. This can probably be remedied in the PvE revision 8 version.
- Crusher timing was not automatic.
- Some people eschewed the use of the crusher entirely in favour of simply bashing the blazes with a sword. For them, the relationship between the gate and the fire shield made this somewhat inconvenient.