Minecraft Forums

Glitches provide some of the most interesting engineering opportunities in this game. Intended or obvious behaviors are all fine, but it's the unintended and subtle behaviors of glitches that make you think sideways about problems and come up with solutions that push the envelope of redstone engineering.

The fact that the glitches may get fixed/removed in the future does little to diminish my enjoyment in that process. After all, in a sandbox game with no definitive endpoint it ought to be the process that you enjoy most rather than the lasting results (at least that's my opinion on the matter). I enjoy figuring out unintended behaviors and making use of them, if only temporarily. Additionally they can enable much more advanced and capable devices for the time they persist.

I use this one:
http://www.minecraftforum.net/topic/137113-32x32-tronic-revamped-v10/

Nice linear redstone wire with good contrast. Pastel-tinted wool that's easy on the eyes and easily distinguishable.

Quote from PaulthePhilosopher

That is a very interesting asymmetry around the F1 blocks, I'm sure it can be put to use somehow.

I agree that it's interesting. There's got to be some clever way of making an XOR, JKFF, RSNOR latch, etc using that behavior. Maybe if I think about it long enough I'll come up with something useful.

It is only a few more blocks to test, may as well be complete. There are known E/W and N/S quirks for rails and redstone so it should be checked out. Having checked it out completely, we now know there are no other asymmetries in mechanically (non-redstone related) provoked block updates.

Right now it's only a few more blocks to test, but I'm worried about the complexity of testing all the various possible trigger materials (redstone wire placement, redstone wire state change, repeaters, levers, minecart track, furnaces, etc) in all the possible locations. I haven't observed any evidence that tells me there would be any violation of the symmetry. Hopefully if there is an asymmetry it will show up as a difference in our testing methods, since I am paying no attention to piston orientation and it sounds like you are (maybe I will start randomizing my piston orientation to increase the chances of uncovering an asymmetry without having to double testing iterations).

The asymmetry in the F1 plane can be explained as follows: mechanically provoked block updates have a range of 1 from the changed block. When a piston is extended it acts like a 2 block long entity, and is adjacent to the F1 blocks. When it is retracted, it is not adjacent to them and so they do not provoke an update. By this theory, placing or destroying the block F2 should provoke an update to make an extended horizontal piston retract. I tested it, and it does (oops, I see you tested it too and recorded it). It also works for downward facing pistons to make them retract.

This is my thinking too. A state update trigger needs to interact with a location containing part of the piston. When the piston is retracted, only position zero fits that description; when extended F1 fits that description too. In the future we will of course have to be careful to test specifically extended vs retracted states.


I'm going to proceed with another phase of testing, replacing wool blocks with single pieces of unpowered redstone wire as my test material. Since it seems to matter if the redstone wire is connected to other redstone wire, I will be testing only isolated single pieces at first.

[edit]
Isolated redstone wire placement:

Triggers in all cases:
D2

D1
D1L1
D1R1
D1B1
D1F1

F1
L1
R1
B1

U1F1 (only testable for 0->1 piston state change)
U1L1
U1R1
U1B1

U2

Triggers only when extended:
D2F1

D1F1L1
D1F1R1
D1F2

F1L1
F1R1
F2

U1F1L1
U1F1R1
U1F2

U2F1


All testing was done with a solid layer of inert blocks one layer below the testing layer. For example when testing redstone wire placement on layer D1, a layer of inert blocks formed a floor on layer D2. No blocks were above the test location, except for the obvious piston blocks when appropriate.

This is what all the "always trigger" locations look like:


And with the "only when extended" locations added:


The "piston" in these conceptual representations is at the geometric center in all directions, so there is an empty space in that spot. Due to practical limitations (you can't place redstone directly on top of a piston), there is also an empty space above the "piston".

These patterns seem like they could be the result of a mathematical convolution of an impulse function created by and centered on placement of redstone wire with the current valid coordinates of the piston block. Since the retracted piston is essentially a dirac delta function, the impulse function would be equal to the output function. In other words, placing a redstone wire triggers block updates in a pattern like this:

D2

D1
D1L1
D1R1
D1B1
D1F1

F1
L1
R1
B1

U1F1
U1L1
U1R1
U1B1

U2

where the redstone wire position is at zero. If the target piston is within this impulse function, it will be updated.

The shape of blocks that only trigger when extended can be explained in the same manner - it is the intersection of their impulse functions with the temporary location of the piston plunger.

[edit2] I found you overlooked U1F1 as a valid "only when extended" update location for inert blocks. At least it worked for me when using wool.

Using the complete set of inert-block locations we can go through a similar process of determining the impulse function:






Putting this together, it seems that redstone wire triggers primary block updates at U1 and B1, then all three of those blocks trigger secondary updates at all immediately adjacent locations. Inert blocks only trigger a single set of updates at immediately adjacent locations. It will be interesting to see if the redstone wire behavior holds true for other active materials too.

Your sine is not a sine. For it to be a proper sine, you'd have to set the outputs of your circle signal generator to start on the transmission line at a single x-coordinate (assuming x is in the propagation direction). Right now if I'm not mistaken you have a y = sin(t+cos(t)) waveform.

Make sure you don't actually make any "rings" with repeaters in them. If current can travel in a loop from the output of a repeater back to its input, the repeater will stay on.

I bet you need to just make a small break in your reset line "ring" and have it go 3/4 of the way around the circle rather than all the way around.

There have been a couple topics popping up lately describing what appears to be a bug/quirk in piston update behavior. You can read about it here:

http://www.minecraftforum.net/topic/554776-a-not-gate-without-a-torch/
http://www.minecraftforum.net/topic/554668-173-piston-oddity-power-via-induction-wirelessly/

I was inspired by this behavior to create a D-Flip Flop. I'm not really abreast of the current state of logic gate development, so this may or may not be useful or superior to other DFF designs in use now.

Updated version:


Size: 4Lx3Hx1W
Speed: 1-tick delay off->on, 0-tick delay on->off

Old version:

I am pretty sure no one has ever thought of this before, but I made this myself today and I think it's a really great idea. (I didn't hack I swear!)



You can use the lever to activate the redstone circuitry which will extend the elevator so you can get on top of the wall. It took me a while to figure out the redstone part since I'm not very good at redstone, but I will make a tutorial for anyone who wants to build this if I get enough requests for it. (Don't forget to upvote and subscribe to my youtube channel in my signature!)

If anyone finds this useful and wants to use it in their world just ask and I will upload a schematic just be sure you give credit to Krackor the guy who thought of this first.

Quote from Mecha*Rage

Correct me if I'm wrong, but you can use redstone in place of the repeaters :unsure.gif:

It would destroy the one-way signal transmission feature. That means you could replace one of the switches with a redstone torch and use it as a way to cheat and look at some of the internal signal generation information.

i.e. replace the first lever on the line with a redstone torch, which then acts as an indicator of whether you've got the code right on all levers within redstone transmission distance of that torch. In effect it cuts down the complexity of the combination lock from 2^29 to 2^15+2^14, since you could do it from both ends and solve the two halves separately. Effectively replacing repeaters with redstone cuts down on the effectiveness of the lock by a factor of the square root, which is a pretty huge loss.

Quote from Kamil

It's not more useful, it's just more visible. What possible use do you have for a door 10 blocks high?

Keeping the Millenium Falcon from leaving.

Impossible to obtain a diamond without using a pickaxe?

...So I put some Minecraft in your Minecraft so you can Minecraft while you Minecraft.

People TALK about playing "Minecraft in Minecraft", but I decided to finally do something about it.


I gave a good overview in my Preview Thread: http://www.minecraftforum.net/topic/561924-hans-lemurson-gives-a-preview-minecraft-in-minecraft/

Quote from Hans Lemurson

You all know that joke when somebody is showing off their brand new Redstone Computer and somebody asks: "Can it run Minecraft?" You have a chuckle at how clever you are while people variously chime in "LOL" or "It's impossible numbskull!!!".

I was one of the people in the latter group, continuously annoyed by people who don't understand the orders of magnitude of difference in computing power between a Redstone Computer (they are on par with 1930's technology) and a modern computer. After a fresh session of apoplectic rage however, I began to ponder: "What sort of program could you feasibly run on a Redstone Computer that would still retain the essence of Minecraft?" And thus a dream was born.

That was 3 months ago. After months of planning and sporadic construction work, I have finally completed this great and grand project which I intend to be my "Magnum Opus". I have made "Minecraft in Minecraft", or "Mini-Minecraft".

Features:
-2D Graphics!
-8x8 Pixel Screen
-64 bits of Landscape Data
-Blinking Lights!
-Directional Control Interface
-Solid Terrain
-Gravity
-Moderate Signal Latency (4,000ms)
-Color-Coded Circuitry!

If you're interested in seeing a tour of the machine, there's a video for that too:


I will likely expand this post at some point when it's not sleepy-time to go into the technical details of its operation.

In the mean time, feel free to give a +1 if you think Minecraft in Minecraft is cool. Also thanks to Conundromer for not beating me to the punch, since I'm not the only person to have come up with this idea. I'm just the first with a video.

Update: After utterly neglecting this thread for a few months, I give to you schematics and downloads!
http://www.planetminecraft.com/project/hans-lemursons-minecraft-in-minecraft/

Hopefully everything will work fine, but I did have some troubles with the sticky-pistons when I imported it onto my plot on the RDF server.

You all know that joke when somebody is showing off their brand new Redstone Computer and somebody asks: "Can it run Minecraft?" You have a chuckle at how clever you are while people variously chime in "LOL" or "It's impossible numbskull!!!".

I was one of the people in the latter group, continuously annoyed by people who don't understand the orders of magnitude of difference in computing power between a Redstone Computer (they are on par with 1930's technology) and a modern computer. After a fresh session of apoplectic rage however, I began to ponder: "What sort of program could you feasibly run on a Redstone Computer that would still retain the essence of Minecraft?" And thus a dream was born.

That was 3 months ago. After months of planning and sporadic construction work, I have finally completed this great and grand project which I intend to be my "Magnum Opus". I have made "Minecraft in Minecraft", or "Mini-Minecraft".

Features:
-2D Graphics!
-8x8 Pixel Screen
-64 bits of Landscape Data
-Blinking Lights!
-Directional Control Interface
-Solid Terrain
-Gravity
-Moderate Signal Latency (4,000ms)
-Color-Coded Circuitry!

And now to show that I'm not just full of ****, I give you screenshots:

Display viewed from control-box

Here you're staring at the crazed mish-mash of all the terrain created/destroyed in my debugging attempts. Player position is not visible, since that square is currently OFF in its blink-cycle.

Display Side-View

The orange and pink lines are carrying the Vertical Position data from its register to the display. The sharp-eyed will notice that there is a torch lit on right side of the middle pink line. That's the current height of the player. I placed those torches there for debugging purposes when I was having problems with data corruption.

High view of back of Display

Light and Dark Green helixes carry new data to the Display, one Bit per column. Purple lines in the background carry the "Write" command to an individual Row to update its D Flip-Flops when a block there is placed or removed.

Guts of the machine

Here you see all the parts of the machine that do the actual calculations. Underneath the green lines is the 64 bits of RAM (the green lines are its input) that store the terrain information for calculations. In Blue at the far end are the Horizontal positional controls which both keep track of the player's horizontal position and govern interaction with blocks. The Gray stuff to the left is the circuitry needed for the "Jump" command, and underneath it is the rest of the Vertical positional controls.

Control-Bits

Here you can see 4 of the 9 Control-Bits that govern the machine. Combining "Shift Up" with "Place/Remove Block" results in the block above your current position toggling between ON and OFF. Note the long chains of Repeaters on some lines: It was necessary to introduce carefully tuned signal-delays to ensure that the Positional/Terrain actions don't happen until they have already been pointed to the right location. Getting the signal-delays synchronized like this took many hours of frustrating debugging even after I thought I was "95% done!". Well, I'm done NOW.

Wires Leading to Command Decoder

Here you see the wires from the Control-Box going down to be converted into signals sent to the Control-Bits that actually govern the machine. Pink/Orange are Down/Up and Light Blue/Teal are Left/Right. They split into 2 lines in the decoder: one for Movement, the other for Block manipulation. The Red line is in charge of triggering an extra "Move Downward" command after every action you perform in order to simulate gravity. A solid block underneath you will prevent this downward motion.

Control Panel

Here are the 5 controls that will let you move through the world. 4 directional controls and a switch to toggle between Movement and Block Placement/Removal. It's humbling to realize just how much work is required to convert a simple button-press into an executable command. It takes about 4 seconds for the effects of a button-press to be visible on the screen.

So, that's the sneak-preview of my machine.
I'm calling this a "Sneak Preview" because the real presentation is going to be the Youtube Video I'm planning on making which will show this thing in action, accompanied by mad laughter and melodrama and will get its own dedicated thread. My intention is for that video to go viral and explode the internets.

Oh, and also I'd like to give thanks to Conundromer for deciding not to beat me to completion of this project while I was on vacation, even though he probably could have if he'd set his mind to it(he's good).

If you think that "Minecraft in Minecraft" is totally awesome then feel free to +1 my Reputation. The higher it gets, the sooner my video comes out!

Edit: The video is out as of Aug 31st.
See this thread:http://www.minecraftforum.net/topic/590096-hans-lemurson-makes-minecraft-in-minecraft/

Why do so many tutorials make use of glitches?
It's Minecraft goddamit.

OT: Sometimes it can make the circuit work faster/more compactly. But also, as someone said before it is sometimes difficult to tell what is a bug and what isn't, especially with hyper-sensitive pistons. Generally, if it can be done without bugs do it, bugs will get patched and leave you with a mound of useless redstone.

As for exploiting them... Well guys, remember the days where we had to use the North-South Quirk to get a synchronised double-door working?

Bugs and glitches can help out. For example people have made D flip flops using glitches with piston, which help save space. If there is a glitch, why not use it to its potential? And if it gets patched, oh well.

Quote from Yohosh

Alright

So to spare myself from being insulted, I may be posting a very stupid (or legit) question. (inb4 no such thing as stupid questions)

Anyways... I know absolutely NOTHING about redstone at the moment, lets leave it at that. I have watched some videos on peoples minecraft creations and I noticed that a lot of them say that they "programmed" it (mostly computers). Does learning minecraft (and later experimenting with, after learning most things) teach you programming too? Or is this kind of programming not related to any other kind of programming and relatively useless while not in minecraft?

Thanks!

Haha, I'm not going to insult you.

Redstone logic has enough in common with real-life digital logic that it can teach you certain aspects of real-world electronics!

It is not the same thing as computer programming (i.e., writing code in a programming language), but when people speak of programming devices in-game, what they are doing is related to "computer programming".

Programming takes place on the software level rather than the hardware level. Let's say you're making an electronic combination lock. Wiring the lock to open on a specific combination is not programming. But if you build it so that you can set a combination by pressing buttons and a set switch, that is programming, changing the behavior of a device by changing the state of its (digital) memory rather than the arrangement of its hardware.

Using a programming language like Java or C is a little more complicated, because it also has to interact with an operating system and other intermediate layers above the hardware level. Generally the devices we program in Minecraft do not have operating systems (but I wouldn't be surprised if some did!).

In addition, there is a relationship between logical operators for if-statements used in programming languages (and, or, nand, nor, not, etc.) and the logic gates used in redstone wiring as well as irl electronics. If you understand how one works, you have a sense of how the other works.

That's my short answer.

Download the World

TaviRider's Seal of Approval:


Huge thanks to TaviRider for developing InstantWire, and for going through to verify my invention. And thanks to Etho for bringing us all the Block Update Detector concept which made this possible.

It's worth noting some of the limitations. If you toggle the input line too quickly, the pistons in the repeater/NOT gate will get out of sync, and usually you will need to manually fix the pistons. So a pulse limiter might be necessary if you plan to use these in any way that's accessible to users. Also, if you have a signal coming from an outside source to the output of the gate, it can mess up the gate, so when putting two repeaters together in an OR gate, use the 15 redstone limit to make sure that the output of one repeater doesn't send a signal to the output of another. Similarly, as I described near the end of the video, there can be double-pulse issues on the same powered redstone line, so using the door-update trick on any repeater that has an OR gate feeding into it is probably a good idea.

3 things


1: Stop saying ace so much, it makes me want to kill the neighbor's dog.
2: Stop double- and triple posting- that is counted as bumping your own topic, which is against the rules.
3: This thread is absolutely pointless. If you want to see creations, browse the fricking forum. That's what it's here for.

Quote from inspectormoshi »

Getting toomanyitems!!!

Quote from inspectormoshi »

So i'm still looking for a computer!!!

Quote from inspectormoshi »

Sorry I haven't been on for a while, it was because I was away!!! On holiday!!! (did I sound dum?? LOL) So now I'm back on track!!!

I'm sorry, but it's not your blog. it's a forum.
Also, stop double/triple posting.

When redstone first came out, I invented a method of sending messages to everyone on the server. I called it "the chat". You access it by hitting 'T'.

One thing I want to get out of the way first is to setup a notation system for this exercise so I can refer to block locations exactly avoiding ambiguity and without a picture.

Everybody faces the piston when it is placed, so that will be the default orientation for the notation system I use. The piston itself is block zero when counting blocks. Facing the piston, blocks to the left are number 1, 2, etc and prefixed with L. "L2" refers to the block 2 spaces to the left of the piston, so that there is one intervening block between that block and the piston. R is for right, U is for up, and D is down, and let F be front and B be behind. L1U1 is what I have been referring to as an "upper diagonal". The other upper diagonals are B1U1 and R1U1. Here is a picture with some blocks labelled, where the labels are on the front surface of the block referenced.



On the D2 level, the piston is sensitive only to the block directly below the piston (named block D2), but with odd conditions.

Placing and removing blocks has no effect, unless what is being placed or removed is redstone, a repeater, or redstone torch. Changing a repeater delay setting has no effect.

Pistons, wooden pressure plates, torches, had no effect. Placing water had no effect. Lava was not tested. Placing a bed down and sleeping on it had no effect. Oddly, placing a lever had no effect, and clicking the lever had no effect. Ditto with buttons and clicking the buttons (tested on all four wall surfaces facing block D2). Trap doors were not tested.

A redstone wire in place here causes a block update when the redstone changes state. A "redstone state change" refers to a change in the signal strength of the redstone, not merely "is the redstone on or off". So if a redstone signal source close to the D2 activates and then another on the same span of redstone but further away, when the first and closer redstone source turns off the redstone signal strengths are recalculated and the piston goes through a block update.

Running active redstone up to a solid block at D2 has no effect, and neither does a repeater pointing into the block. A repeater occupying location D2 causes a piston block update when it changes state. A repeater state change is when it generates output after its delay.

All this to test one location so far. Thorough testing is a pain in the ass. I started testing various timing relationships between signals arriving at D2 and B1U1 but decided timing can wait for another post. I'll edit this one with further test results later.