The Village Experiment

Forum Post: Click Here

The purpose of running this experiment is to observe how villagers and villages interact with each other. More specifically, to see what would happen if two villages touch each other. Would they merge or still be two different villages?

 I made a 32X64 home city for two separate villages 32 houses apart. I started each village with 17 testificates on opposite sides of the city. The houses I made have lights on the top so I'll know if they are in the home. I'll track the progress of the size and location of the village with the houses they chose.

 I'm also tracking the progress with the golems, they spawn for every sixteen villagers starting with the first sixteen. They don't out of the village boundary, so I can see the clear border.  

 I continued to observe and found that the villages not only began to expand, but migrate. One village began to move to the east and soon was really out of the starting area.

 The one village then became so dense that they started doing this. They started mating at a very rapid rate. They cramp into a tiny 3x3 area to mate all night long until I evenutally break the door down. I had to do this several times.

As the two villages began to get close to one another they began to act strangely. From what I saw, the two villages never actually touched one another, they just began to get bigger and bigger. They both became very large then I saw something very strange, villagers began to form a new village in between the two villages I started.

 In the end, two new villages formed and went their ways as they migrated. The results whether they merged or not was inconclusive.

 Another purpose of this experiment is to see if an iron golem farm can operate in a city full of villagers. I saw an iron golem farm in Docm77's youtube channel. First, I wanted to see how creditable the design was, so I made the spawning cells very close to each other. The distance between villages doesn't really matter to be defined by the game as villages. But they do interfere with each other's spawning.

 Since I couldn't clearly see two villages merge I decided to scale down for a second test. This is a 3x32 village with both villages starting at opposite ends. This is so they won't spread as much as last time.

 Soon, a golem spawned in both villages. I know now that the game defines them as two separate villages.

 For these houses, I McEdited the glowstone from the roof to get a better view of the lights.

 The black wool village soon moved a little closer to the center.

 I outlined with wool the progress of the villages. They seemed to have stopped that these lines. I had to encourage them to move.
                                       
I destroyed the houses they left behind to force them to move towards each other.

 I then outlined the village border. It seems no village or golem would cross this line. They eventually did, but it was probably because of their wondering AL.

 They don't seem to be interested in the houses near the border. With that, the experiment has ended. Here are my findings:
-Villages depend on the villager's location. The villager's location is dependent on the house's location.
-Where the golem spawns depends on the village center, the center can move as the villagers move.
-The distance between villages required to create another village is only because villagers would return to their own village if there is none around them. (The 40 block requirement from Wiki)
-The spawning location of golems depends on the village center and the number of villagers around the center.
-Villages created will be defined as separate from other villages. Villagers can wander and create a new village if the houses are at an appropriate distance.
-Villages cannot be destroyed by the game, only created. Well, mobs and players can destroy a village but you get what I'm talking about.

I suppose I can't place a golem farm in my city. I'll have to put it somewhere else.

Automatic TnT Cannon: Large Clip

This is what I was working on the past few days, an automatic TnT cannon. The cannon itself is relatively small compared to the redstone below. This cannon is actually quite complex so listen.

 The whole cannon works on a forty-eight tick redstone repeater clock, which means it takes eight seconds per cycle. The pistons loading the TnT as the propellant inserts them two at a time, or cycle. This cannon is designed so that after four TnT is inserted as the propellant, it'll ignite. Which means this cannon fires every sixteen seconds. Four TnT launching one TnT.

The picture above is the counter. It is used to move the sand when the time is right. The picture below shows the ammo used. Each row has ten TnT and when the piston is finished pushing the row, the counter will send a signal to push over the next row of TnT to be loaded.

 This is the mechanism used to store and push the propellant. Cobblestone from a generator is used to help push the TnT along.

 A vertical piston is used for pushing the ammo and the propellant along, they both use a redstone clock to time the cobblestone generation.

Redstone RAM, Simple Explanation

I'm sure all of you watched a video on Youtube where a person in Minecraft builds this massive redstone computer thing. I've always wondered how they worked. Perhaps I could do something like that in my Ambrosia map.


I believe I had figured it out. It's actually quite simple.

 This is a picture of a prototype cell. The piston t-flip flop is functioning as a memory cell and the "And" gate is controlling the input. I have this set up in a way where if I toggle the flip flop and push the button, the torch would turn off.

 Here I have a two bit RAM. Two cells working in unison because they are attached to only one button. Two inputs to toggle the flip flop.

 Here's what happens if I toggle both cells and hit the button.

Here's what happens if I toggle one and not the other.
Not really sure of what to use this for. All I can think of now is a pass-code door. If you hit the right buttons and push enter, the door would open. That seems too simple though.

Update 10-9-11 Multiplayer servers

I've been playing on some multiplayer servers and it's quite fun.

This is a timer mechanism I built on the server. Eighty-four redstone repeaters in a row set to four ticks. That equals sixty seconds. When the current goes to reset and start over, it triggers the powered rails. This sends a mine cart to the next unpowered rail. Every time a rail is powered and releases the mine cart, it will hit a detector rail. The each detector rail will send a current up.


So, every minute the current being sent up will changed. This a good set up for a clock tower I plan to build in my Capital city. However, if the player walks away, the redstone timer will stop. I feel that this isn't really a big problem.


Helios will have to be completed after Beta 1.8. All I've done is the endless cycle of gather material and placing it on Helios. I think I'm close to forty-thousand blocks.

Redstone Multi-Setting button

This is a good twenty minutes of work here figuring this out. This is not what I wanted, however I would like to share this with you guys before I search for a solution.

 First State.

 Second State.

 Third State.

 Fourth State. The outputs are the torches on the third layer of the wiring.

 When the button is pressed, the RS nor latch triggers and goes into it's second state.

 The RS nor will activate the redstone repeaters and deactivate the one torch on this double lock. A second circuit is sent when the button is pressed and travels to the right of the wiring to deactivate the second torch. The delay the repeaters give enough time so the wiring won't reset itself.

From the double lock, the circuit travels to another cycle of RS nors and Double locks. The more cycles it has, the more states the button will have when you toggle it.

At the end of the "cycles" there is a Double lock with no Rs nor to continue it. This acts as the reset. The second circuit from the button will end at the second torch of the Double lock.


The main purpose of building this is for a project I plan for in my Capital City. The three possible outputs aren't suppose to stay off when I press the button after the second press. It's suppose to be three possible outputs with only one staying active while I'm pressing to change the states. Solution please?

Redstone Button Toggle

I was trying to design a toggle button for the bridge at the Ground Port however, I got frustrated and went with a simpler design.


Even though I don't really need it anymore, I built it anyway. It's compact and very simple to make.

 This is in its off state.

 This is in its on state. It's all controlled by one button! It's the "switch" button!

 This is an "RS NOR latch", it acts as an memory cell recording the two possible states it could be. This is a picture when it's at its on state.

 When the button is pressed, the current travels to an "RS NOR latch" and a Duel lock. The duel lock makes it so both redstone torches most be off for the third torch to power on. This acts as a reset for the RS NOR and will turn the output off when I hit the button again as shown in the screenshot.

 When the button is first pressed to turn the output on, the redstone repeaters prevent the current from reaching the Duel lock too soon. If the delay was not there, the current would travel to the Duel lock at the same time the button is still sending it's current. Basically, it would reset itself, not by me pressing the button again.


To give you an update, I've been building houses on Erie's islands. However, it gets boring. Mostly because of the lack of designs I can think of. I'll start finishing the railway for now.

Nimbus Station Explained

No progress report today, I'll explain my simple rail system. If you saw my introduction video you'll understand I had to redesign this twice.

 The current system relies on powered rail for momentum. This screenshot shows how you would stop at the station. When you press the button, the cart will travel to the level below.

 The cart will come down here and travel up the in-climb.

 It'll drop into a trap door dispenser rigged to drop one cart when powered. This design uses two trap doors.

 It'll drop down here, onto a powered rail powered by a lever. 

 The redstone torch under the rail controls the direction of the in-coming carts. North bound or South bound.

The button controls the trap door dispenser and the lever controls the direction of the carts.