If you read my last post you’ll know that I’ve been building a sailing canoe. If you didn’t read my last post you now know that I’m building a sailing canoe. I decided the perfect block for mast on the canoe would be mud brick walls.
I don’t have a large mangrove swamp near spawn and am short on mud. I thought I would build a mud converter rather than harvesting mud from a biome. The converters I’ve seen are small, appeared simple in videos and I’ve never built one.
Without looking up a tutorial I thought I would jump in and figure it out. I looked forward to trying something new and I thought I knew how they worked and built mine around an observer.
Redstone basics (why an observer was the wrong choice)
An observer detects a state change for a block. When converting dirt into mud using an automated farm there are 3 state changes. These state changes are:
- a block is placed
- dirt is converted to mud
- a block is destroyed
3 pulses is a challenging number to manage in a redstone circuit. 2 is a much better number as it can be managed through a t-flip-flop like this one:
A t-flip-flop creates an output every second pulse in a circuit. It’s my experience that you often only want one of these pulses in a system. Either one of the state changes is not relevant to the next system component or the next stage is more efficient or has higher capacity.
A sticky piston receiving a signal from an observer acts in an interesting way. It will move a block in 1 direction rather than push it out and pull it back. This is because the observer pulse is so short. If the block is in the retracted position it will extend it and drop it there. If the block is in the extended position it will grab it and retract it.
If this block is a redstone block you can create an on off switch (the two images above). If this block is another observer; it’ll create a pulse when the piston pushes or pulls the observer into position. The observer will successfully transmit the pulse only when it’s being placed into position. It will not successfully transmit the signal when leaving position.
For example, in this picture, if we want the signal to be used in the extended position. There would be redstone dust, a repeater or a redstone component such as a piston next to the observer in the extended position.
When the first pulse comes into this system the piston would retract the observer from the extended position. The observer would not pass on the redstone pulse. The next pulse would re-extend the piston into position. That second pulse would pass the pulse on in this example.
Eliminating a pulse
The first hurdle to over come was turning 3 pulses or block state changes into 2. I went back to a previous world in a modded instance I put together on forge. There I learned something while using the create mod that could work for the mud converter (it’s a vanilla mechanic). I made a tree farm and used a wall in front of an observer to detect the tree growth.
The observer wouldn’t detect the planting of the sapling, it only detects the growth (placing of a block) and chopping of the tree (breaking of a block). The wall changes state when it connects to the tree and when it disconnects after the tree is chopped.
You are using the wall as a probe of sorts. The observer sends a signal when the probe detects a change. This probe doesn’t detect state changes of blocks, it detects the presence or absence of a block and the wall changes state accordingly. The observer detects the wall or probes state change and emits a pulse.
Mud farming theory
If you aren’t already aware mud can be created by using a water bottle on a dirt block. This water bottle can be in the players hand or it can be dispensed from a dispenser. A dispenser can fill a water bottle from a single source block and without depleting it.
One dispenser can be used to dispense a filled bottle to convert the mud without player interaction if it receives a redstone signal. The empty bottle collected and returned to the first dispenser to be filled in perpetuity.
ilmango has one of the most widely used mud farms from what I can tell. The player places the dirt block, it’s instantly converted to mud and then broken by a shovel in by the player. The shovel needs to have very low efficiency or it breaks the block too quickly. This is a Java mechanic as bedrock players can’t hold items in their off hand just yet.
This is mud conversion. If you want to farm mud you would need a infinite “dirt” source such as a rooted dirt farm or podzol farm. With either of these a tree farm is used to convert stone into a dirt variant which is converted to mud and later broken in a TNT blast chamber.
First draft
This was my first draft. It uses another method of creating a t-flip-flop that uses 3 droppers and a hopper. An item rotates through the system as I’ve indicated with the arrows.
This system needs comparator to pull a signal out of one of the droppers. I started with this thinking I could pull 3 signals but that is not possible. The item can only be detected while resting in 2 of the 3 droppers (it quickly passes through 1 because of the observer sending 2 pulses). There are other problems with this design you might be able to see if you understand redstone mechanics.
You can see the brick wall that will detect the block being placed and destroyed; the water bottle dispenser facing upwards that the block will be placed on and a dispenser pointed into a water source.
Second draft
This was working, however, it was not fast enough to use with a shovel in one hand and the dirt in your other. You could do this, but you had to place the dirt, wait, then break it.
It would probably have been completely fine and works just as well as the final iteration. I just wasn’t happy with a poor performing contraption that didn’t look or function in an interesting way.
Third draft
Rendog built a converter on Hermitcraft this season that pushes the mud into a stockpile where he then mines it with a shovel. For me this solves the issue of my farm operating too slowly. If I broke and/or placed a block too quickly I just ended up with dirt, a water bottle and a broken farm.
In this version after the dirt is converted to mud a sticky piston lifts the block up then a normal piston pushes it forward. As long as I waited for the block to be moved the farm worked.
Stockpiling
Step 1 in making the stockpile was to push the blocks coming from the converter upwards. I want to have a stockpile that is 1 full stack of blocks (64). That’s 4 rows of 8. My approach to this was to have a 2x2x8 stockpile of mud blocks. This kept the machine within a single chunk; even with the cactus farm sharing this chunk.
I used a t-flip flop with the observer detecting the extrusion of the mud blocks from the machine. every 2 blocks the pistons will fire and push the mud upwards.
Another t-flip flop feeding off the vertical pushing circuit pushed a 2×2 slice of mud blocks into the stockpile area. I’m using furnaces as non movable blocks in the design phase. These are here as a fail-safe to avoid blocks being pushed out of the machine if something breaks.
An observer at the end of the stock pile with a t-flip-flop and a redstone block makes a cut-off switch. When mud is pushed over the observer the redstone block is pushed forward and locks the machine. It turns on a indicator lamp, and overrides the initial observer. This means no signal is sent from a dirt block being placed next to the detector wall and the system stops functioning.
It’s about problem solving
I have watched many redstone tutorials and have watched many more explanations in let’s play episodes from the many you-tubers I follow. Lately I’ve found myself more and more trying to find ways to solve redstone problems on my own rather than copy something I’ve seen from someone else.
I may take inspiration for an idea or component from someone else’s design; however, I want to try to get there with the components and mechanics I’ve learned. It’s almost certainly going to perform worse and be less reliable.
In this case the end result was a machine that feels like some type of industrial press. Operating the system brings tactile and sensory joy. I enjoyed solving the challenges of the a system I didn’t fully understand and making the tools I do understand work to achieve a new goal.
The system is not optimized for efficiency but my needs are minimal. The amount of mud I’ve created building and testing the machine will last me for a while. Thanks for reading and I’ll see you next time.
Build Stats
Real Life Days: 57
Minecraft Days: 230
Hours: 4
ChunkShift.com 
Leave a comment