Automated Blaze Grinder

From MC Public Wiki
Revision as of 23:40, 16 May 2012 by Totemo (talk | contribs) (Thinkin' about it...)
Jump to navigation Jump to search
Automated Blaze Grinder
2012-05-13 16.13.05.png
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

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:

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.