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.
2
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.
1
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.
1
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.
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).
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.
1
1
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.
3
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:
D input is the lever at top left.
Clock/Enable input is the button at bottom left.
Q output is the repeater at right.
This design can be tiled with no insulation space between DFFs:
My current understanding of the piston update mechanism is as follows:
Pistons use adjacent blocks as input to their extended/retracted state. For some reason blocks that are diagonally adjacent (one up, one behind) are polled as input, though not all the time, only when a state update of the piston is triggered from elsewhere. The D input in this design applies an input signal to one of these diagonally adjacent blocks. The clock input is at the right distance away from the piston such that it forces an update but doesn't actually transmit the clock signal into the piston state. Since the piston "reads" the D input whenever the clock signal forces an update, the output updates both on the rising and falling edge of the clock. I'm not sure about the canonical definition of the DFF behavior, but this could be easily modified to use a 1-tick clock pulse (or maybe even one of those mystical 0.5 tick pulses) to limit the DFF to a single update per clock cycle.
I'm pretty bad at compacting redstone designs, so feel free to offer suggestions on the layout.
2
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.
1
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.
1
Keeping the Millenium Falcon from leaving.
5