Automated Blaze Grinder
 | |
| 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, 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.
Revision A
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
Revision 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
- No sticky pistons used (it 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 (but: never saw a stuck repeater, maybe just because it wasn't used enough)
- The redstone circuitry in revision 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.