Minecraft

[spoodie]

Looks like the world is screwed. May be related to my Internet going down, but that doesn't seem likely. Perhaps it was The Nether. I don't know that it causes problems but not tried it. It may well be fixable, but I don't particularly want to spend time on that. I'm uploading the world on to Dropbox if someone else would like to have a go at it.

I did say it was temporary.

/edit
World file - http://dl.dropbox.com/u/722828/world.zip

[Dog Pants]

Noooooooo! Castle Duckula!

[Mr. Johnson]

I was building an inn. there is absolutely not point to that, but I could.

[spoodie]

I remembered I took a copy of the world yesterday morning, to have a look at in single player. Unfortunately that errors all over the place as well. I guess that means the corruption happened before I restarted today.

If there's interest (and if no one has managed the fix the broken world) I can put up another server once there's a proper release for the server tool Bukkit for 1.8.x. That will allow auto backups and restarts.

[Stoat]

The seed is -3804446118942569114. I generated a new world with that seed and copied its level.dat over. I can at least load the world now. I've only had a cursory look around though - where are the errors?

[spoodie]

Stoat got it working but I can't replicate it. Is that world seed supposed to have a negative number, that's what I'm using?

[buzzmong]

I'm not too bothered about doing a new world.

A few hours on a Friday or Sat evening would see us complete massive constructions again.
Besides, we were short of sand.

[Grimmie]

There was a stonking great dessert just over the hill, near the portal, Buzz :p

When I entered the nether the first time I think I might have made the server upset - it came up saying something about "End of stream".
Worked fine after a few hours, but I do worry that I might have sent it on a downwards spiral.

[Stoat]

Stoat got it working but I can't replicate it. Is that world seed supposed to have a negative number, that's what I'm using?

Yes, negative. Even if the seed is different, all that would happen is that newly generated chunks wouldn't fit seemlessly. All I did was stick the freshly generated level.dat in to the world you posted above. I loaded it in Single Player to have a look around. Then I downloaded the server jar, copied the world save over and pointed it to it. It loaded up fine- even spawning in my basement with my inventory.

[buzzmong]

There was a stonking great dessert just over the hill, near the portal, Buzz :p.

Really? Obviously I was too busy building walls and other structures in the swampy biome we were in as I didn't go exploring at all

[fabyak]

You should have done, it was an epic blancmange

[Baliame]

Heavily insane sounding (and actually insane) concept ahead. Please proceed with caution.

When I first came on the 1.8 server, I began experimenting with a seamlessly working 'rising bridge', so to say - which in concept first was a three block deep pit with a lever extending a bridge in front of the door. The concept does sound simple enough - stack three sticky pistons on each other with a block on top of it and connect their predicted positions with redstone...

...Nope. Piston physics are a bit more complicated and unintuitive than that.
The first discovery I made was that you cannot push or pull extended pistons due to the way the engine works, but to even further complicate things, upon pulling back sticky pistons, the block on top of the piston being pulled isn't pulled back either. After a long time of figuring this out, I came up with an ordered list of actions for extending and retracting this bridge. Assume that the pistons are labelled, from bottom to top pistons A, B, and C. Obviously, this is for working with blocks unaffected by gravity, such as cobblestone.
For extending, it's rather simple:

Code: Select all

Extend piston A
Extend piston B
Extend piston C

Now, retracting is where it becomes a horrible headache to even attempt to complete this construct:

Code: Select all

Retract piston C
Retract piston B <- Piston C gets pulled back, the block stays afloat
Extend piston C
Retract piston C <- The block gets pulled back
Retract piston A <- Piston B gets pulled back, piston C stays afloat with the block on top
Extend piston B
Retract piston B <- Piston C gets pulled back, the block stays afloat
Extend piston C
Retract piston C <- Every block returns to its original position

Note that this sequence hasn't been tested live, simply because it's a mess, something you probably can't even do with two, let alone four "piston towers" placed below each other. As you may note, for N pistons, it takes N steps to extend and N*N steps to retract, therefore the complexity of the system is quadratically proportional to the amount of pistons vertically stacked.

I decided to simplify the construct to a two blocks deep hole, therefore requiring only two pistons to work in a sequence. At first, to the naked eye, this appeared to be a two output level (as in, you have to provide output to the pistons on two different heights) problem, and I began to work with this assumption, just to see it fail as you probably could see it on the map if we could successfully restore it.

For retracting two pistons, the sequence is a bit easier: (assuming the bottom piston is A, and the top piston is B)

Code: Select all

Retract piston B
Retract piston A
Extend piston B
Retract piston B

After large stack of failed drafts (yes, I actually have at least 30 pieces of paper scattered on my desk describing circuits attempting to do this), I realized two very important things:

First off, output must be provided to the pistons on three levels, as the upper piston will be in an intermediate area when it needs to pull the block back. This realization finally made me able to describe the entire system with a finite state machine. For those who don't know this term, a finite state machine is an arbitrary mechanism that stores its current state and shifts its state depending on the input provided to it while providing the output specified to another, arbitrary mechanism.

The following diagram illustrates the way a two piston bridge will work properly. Explanation is provided below the diagram.

Code: Select all

0/000
,-,                            ,----,
| v    1/10X         X/1X1     v    | 1/1X1
Strt --------> ExtB -------> BrUp --'
 ^                             |
 | X/000                       | 0/1X0
 |                             v
RetB <-------- ReXB <------- RetA
       X/010         X/000

A bit of explanation then. The four characters (such as Strt) are the names of the state, this is really the least important part. The arrows are state transitions, from the source state to the destination state (the pointy end, duh). Now, the state transition arrows have a five-character code next to them, #/###. The part before the slash is the input provided for the state transition - if the input is 0, the state transition with the '0/' part will happen, if the input is 1, the state transition with the '1/' part will happen. Obviously, 0 means the redstone input is off, and 1 means the input is on - the input is the result of logical arithmetics applied to any number of power sources, such as, if there is a lever L and a pressure plate P, and the input is active if either one of these is active, then the input is "L OR P". If the input is marked with an X (called, literally, in the trade as "Don't care"), then the transition will happen after some delay regardless of input. As the diagram shows, there are two stable states, Strt is the input is 0 (the bridge is constantly inactive), and the BrUp if the input is 1 (the bridge is constantly active), both of these are knocked out of state if the input changes at some point, ie. the lever is pulled. The part after the slash is the output - I have assigned three bits to the different output levels, here the three bits define the state of the three output levels from the lowest one to the highest, this will be explained in a moment. The value X in the output means the bit in that position may be either 0 or 1, as it doesn't affect the transitions at the current point.

The second realization I came to is that pistons need not be powered directly - if a piston is placed face-adjacent to a powered block, the piston itself will be powered by the block. This mechanic makes it easier tenfold to actually construct such a contraption. Below is a side-view diagram of the placement for one such 2-high piston tower.

Code: Select all

X X . X
B B . B
B B X 3
B B P 2
B B P 1

On this diagram, . represents air, B represents an arbitrary block, P represents a sticky piston, T represents an arm extended by a piston, X represents the bridge's pieces, and 1, 2, 3 represent blocks which we consider the output levels - so if the output provided by the finite state machine is 101, that means blocks 1 and 3 are powered and 2 is not, which results in:

Code: Select all

X X X X
B B T B
B B P 3
B B T 2
B B P 1

The finite state machine itself is simple enough to realize in an electrical circuit, if we number the states from 0 to 5 starting from Strt and heading in a clockwise order. (Therefore, Strt is state 0, ExtB is state 1, and so on...)

What you see on this diagram is representing this finite state machine. The three small things labelled "D" on the left are D flip-flops (you may laugh now), which are capable of storing 1 bit of data. D flip-flops store whatever value is on the D input on the positive edge (a 'positive edge' is the moment in time when a certain variable changes from 0 to 1) of the clock input and start provide the same data on the Q output until the next positive edge of the clock input. The three of those together store the ID of the current state, from 000 (state 0, Strt) through 101 (RetB). The big thing on the right is a ROM with four pins on the left - these are the addressing pins, used to tell the ROM that which address should it extract data from to send to the output, and eight pins on the right - these are the data output pins. The address input for the ROM consists of four bits. The most significant bit, A3, is connected to the input, and A2 through A0 are connected to the registers storing the current state. This way, if the input is 1 and the current state is Strt, the data at address 1000 will be sent to the output. On this address we store 8 bits of data. The two MSBs, D7 and D6 are insignificant. On D5 through D3, we store the ID of the next state, in the current case, 001, and on D2 though D0 we store the actual output the state transition should trigger, which is 100 or 101.

In theory, and electrical engineering, this is an near-optimal solution to this finite state machine (although, since states are consecutive, it would be more optimal to use a counter with an enabling signal). However, we're talking Minecraft here, and in Minecraft, this isn't a simple construct.
Therefore, the construct must be simplified.

In comes an excellent thing which is much harder to represent in combinational circuits, but easy to create and use in Minecraft: Delays. The finite state machine can be simplified by replacing state transitions with delaying. The replacements are even too mind-boggling for me to document, if you are interested how I came to this conclusion, do ask, and I will tell, but I'll probably stop semi-wasting forum space now.
After two days of work, I present you the much less scientific way of creating a two blocks high piston tower which nearly seamlessly raises a block by two and retracts it correctly.

Code: Select all

1. Place two sticky pistons on top of each other and a block on top of them.
2. Place three blocks on top of each other next to the pistons, in a manner that the bottom block is adjacent to the bottom piston. From now on, I will refer to the bottom block as A, the middle block as B and the top block as C.
3. Create an input stream. This may draw power from any power source, such as a lever.
4. Separate the input stream into three different streams, make sure the wires do not touch.
5. On one of the streams, place a very short delay, and make sure it powers block C.
6. On another stream, make a longer delay, and connect it to block A.
7. Construct an AND gate separately. I will refer to this as gate D.
8. Construct an XOR gate separately. I will refer to this as gate E.
9. Construct a NOT gate separately. I will refer to this as gate F.
10. Create a fork in the third stream. Connect one fork endpoint to the input of gate F, and delay the other fork endpoint by a longer time than the delay is for block A.
11. Create a fork in the stream you just delayed. Connect one fork endpoint to one of the inputs of gate E. Further delay the other fork endpoint by a reasonable amount of time and connect this to the other input of gate E.
12. Connect the outputs of gate E and gate F to the inputs of gate D.
13. Connect the output of gate D to block B.

In theory, the following happens here, assuming I is the original input:
Upon a change from 0 to 1 on the input, the charge first reaches C, but nothing happens. Then, the charge reaches A, thereby activating the lower piston, placing the upper piston next to C, and therefore activating it.
Upon a change from 1 to 0 on the input, the charge first disappears from C, retracting the upper piston. Then, the charge disappears from A, retracting the lower piston. Then, the shorter delay input reaches the XOR gate. If we name the inputs on a XOR gate X1 and X2, we can say that the output of the XOR gate will be 1 if and only if X1 does not equal X2. Now, if the charge reaches one of the inputs before the other one, obviously, the two inputs will not be equal, and the output of the XOR gate will be 1, generating an impulse until the charge reaches the other input. This short charge will reach the AND gate, whose other input is the negated I, which in this case is 1. Since both inputs on the AND gate are 1, for the duration of the XOR gate's impulse, block B will be powered, therefore extending and immediately afterwards retracting the upper piston. This sequence corresponds entirely to the one described above.

In the end, you should have the following circuit in redstone:

If it doesn't work try increasing the delay time gaps a bit.

I hope you found this little essay interesting, have fun with your extending bridges... if you still think you want to build them.
A little note, this works not only vertically, but horizontally as well.


PS. Yes, this is why I'm not going anywhere with Trevor right now, because I apparently have a serious case of OCD.

[Grimmie]

[Mr. Johnson]

Why thank you for the excellent lecture Professor Bubbles.

[spoodie]

Sorry I can't spend time getting the server running right now. Got shit going on that's getting in the way of fun stuff.

[fabyak]

When I get a few minutes I really want to read that, looks di

[Mr. Johnson]

I miss playing on our server, and don't have enough technical know-how to start my own. Might be worth investing in one just for a month or so?

[buzzmong]

I understood all of that. Obviously I actually absorbed something from my Comp Sci degree

Good stuff Bali!

[fabyak]

Question: Can pistons push chests?

Fright railway, I wants one

[buzzmong]

Question: Can pistons push chests?

Fright railway, I wants one

Use these for a freight railway?