The Korot is implementing some secondary features to the design to protect against time-sensitive vulnerabilities (described by apophys's post here), such as logging on just after the user enters the vault, then following their path into the vault in the narrow window of time in which the entrance is unlocked.
All time-insensitive methods should already be guarded against, meaning a single griefer/intruder will not be able to create a meaningful breach in the absence of someone who knows the code.
I'm actually honestly surprised you hadn't seen my prototype yet. For some reason I thought I remembered seeing you reply to it, but looking back I see that's not the case. Since you were the only other person to come close to building an effective design, I look forward to your input and criticism. Thanks for the combination lock design too, btw!
I already asked this in the MCedit thread, but does anyone know how to edit the nether with MCedit? It's kinda important if we want a layer of portals (blocks, no frame) directly above the vault.
Regards,
Korot
This might make you feel stupid, but there is a button on the bottom right of the GUI window that says "Go to Nether".
I was intrigued by this challenge and built something a bit like this:
I like this idea, and I think it has potential. It sidesteps many of the common problems associated with other ideas that are posted here.
One problem that I could see making trouble is the firing of tnt through the entrance hole. One tnt is placed in the hole itself and ignited just after a second tnt is ignited behind it. The second tnt explodes and sends the first tnt through the hole and destroys part of your entrance mechanism.
It may not be the easiest method of griefing, and it may be pretty easy to defend against, but it might be worth thinking about it as you build.
This is going to frustrate people, but why not forsake the whole "unbreakable vault" thing (which I believe is impossible) and just put the Multiverse 2 plugin on your bukkit server? That way, you can simply place valuables in another world, create a portal to it and restrict access to that world. Bam, safe goods.
If it's impossible, why don't you look at the prototype I posted, and which Korot is working on implementing the full design? No one has been able to break in yet, and no criticisms of merit have been presented. As far as we can tell, the "unbreakable vault" is not only possible, but solved already.
If the challenge were altered to include the use of mods, making secure storage would be trivial, thus destroying the entire point of the challenge.
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.
This is my new account i am the creator of this video so i just wanted to say that yeah this is my new account and come check the parkour map me and my friend penguinshavepower created My Map really cool! :smile.gif: enjoy!
If yes, I'll try to make it in MCedit, so we have something to test.
On that note: The Boat-phasing protection was a pyramid of lava, right?
Regards,
Korot
I don't think the pyramid of lava is necessary everywhere in the vault walls. Grizdale added some lava above the inputs to his combination lock, which I copied along with the lock design when I added it to mine. I think it's only necessary there because the wall has to be thinner to transmit the redstone signals.
What you've got there is an edge detector or a pulse limiter. They are actually pretty common and if you search for those terms you'll find that many people have used them before.
Could you post a download or screenshot of the DFF part? I'd be interested to see just how you put it together. Did you encounter any difficulties using it?
You would need a row of indestructable portal blocks above the vault, otherwise the intruder can wait until the owner opens the vault (activates the portal), then use his own portal to gein access.
And please tell me, how do you activate the portal, and how do you deactivate it? The only way I can think of would be to start a fire for opening it, which takes a random amount of time (intruder will have Xray pack and act immediately), and the only way I know for deactivating the portal is damaging the frame (does shoving a block into it with a piston work too?).
So unless I'm missing a reliable way of remotely spreading fire, the owner of the vault would have to use an Xray pack himself, and even then he could only tie with the intruder in terms of speed. So he would have to check the entire bedrock complex around the vault for signs of intrusion.
We have already addressed these concerns ~10 pages back, but I'll humor you.
My prototype has a layer of indestructible portal blocks both above and below the vault (in both the overworld and nether). Both layers are 1 block tall. The layer below the vault sits on top of the void, and is bounded by bedrock. The layer above the vault is about 8 blocks above the vault ceiling and is bounded on all 6 sides by bedrock. These layers are indestructible because there is no valid adjacent location to drop a block or fluid (water and lava extinguish portal blocks). The bedrock occupies the space nearby, and the portal blocks occupy the layer (you can't place anything directly into portal blocks).
The only locations that can possibly lead to the correct portal inside the vault occupy a very small volume in nether-space, and that region is bounded by the nether bedrock box.
The vault entrance portal is nearby some lit netherrack blocks. When the vault is triggered to open, two wood blocks are pushed into position close enough to the obsidian frame to catch fire from the netherrack such that the obsidian frame is ignited by the wood blocks are not consumed. This is a pseudorandom process and takes anywhere from 1-20 seconds for the flame to propagate. When the vault is triggered to close, a piston is retracted briefly allowing a splash of water into the frame which extinguishes the portal. Another block is extended by a piston into the frame, blocking off the necessary 2x3 open space which could otherwise be a valid destination for a portal from the nether.
And yes, Mystify is correct; all this has been discussed and explained before. Please make an effort to read that discussion and examine the prototype I've uploaded before asking more questions.
I updated it so it now always works without using a glitch. The bug will only appear about 7/100ths of the time (in tests).
If you use 16 of these for a 16-bit data register, a 7% failure rate means you have a 71% chance of an error every time you write a 16-bit word to the register. This is unacceptable.
I suppose I mean most compact by simplest. I want to increase the amount of time it takes for a piston to retract while using up the least amount of space. I would prefer not to increase the extension time, but it doesn't really matter.
The shorter of the two delays determines how soon the piston extends. The longer determines how soon it retracts.
128 bpm * (1m/60s) = 2.13 bps (beats per second)
2.13 / ((4 quarter notes / 1 measure) * (1 measure / 3 quarter note triplets)) = 1.6 quarter note triplets per second or 0.625 seconds per quarter note triplet
Redstone ticks are 0.1s long, so the closest you can get is 0.6s per quarter note triplet. If you're using the rising edge of the signal to trigger your note block, you need a 3-clock for the right timing. Unfortunately that doesn't mix well with any clock you'd use to create standard quarter notes since the equivalent would be 3/4 * 3-clock = 2.25-clock which isn't possible to make.
The next best thing to do might be to use a 4-clock for your triplets and 3-clock for your quarter notes. This would make your song a bit slower though:
0.6s per quarter note = 1.667 quarter notes per second = 100 bpm
0
My most recent version is at post #1395.
The Korot is implementing some secondary features to the design to protect against time-sensitive vulnerabilities (described by apophys's post here), such as logging on just after the user enters the vault, then following their path into the vault in the narrow window of time in which the entrance is unlocked.
All time-insensitive methods should already be guarded against, meaning a single griefer/intruder will not be able to create a meaningful breach in the absence of someone who knows the code.
I'm actually honestly surprised you hadn't seen my prototype yet. For some reason I thought I remembered seeing you reply to it, but looking back I see that's not the case. Since you were the only other person to come close to building an effective design, I look forward to your input and criticism. Thanks for the combination lock design too, btw!
0
This might make you feel stupid, but there is a button on the bottom right of the GUI window that says "Go to Nether".
0
I like this idea, and I think it has potential. It sidesteps many of the common problems associated with other ideas that are posted here.
One problem that I could see making trouble is the firing of tnt through the entrance hole. One tnt is placed in the hole itself and ignited just after a second tnt is ignited behind it. The second tnt explodes and sends the first tnt through the hole and destroys part of your entrance mechanism.
It may not be the easiest method of griefing, and it may be pretty easy to defend against, but it might be worth thinking about it as you build.
0
If it's impossible, why don't you look at the prototype I posted, and which Korot is working on implementing the full design? No one has been able to break in yet, and no criticisms of merit have been presented. As far as we can tell, the "unbreakable vault" is not only possible, but solved already.
If the challenge were altered to include the use of mods, making secure storage would be trivial, thus destroying the entire point of the challenge.
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.
0
What happened to your old account?
0
Yeah that's the one.
I don't think the pyramid of lava is necessary everywhere in the vault walls. Grizdale added some lava above the inputs to his combination lock, which I copied along with the lock design when I added it to mine. I think it's only necessary there because the wall has to be thinner to transmit the redstone signals.
0
0
Could you post a download or screenshot of the DFF part? I'd be interested to see just how you put it together. Did you encounter any difficulties using it?
0
We have already addressed these concerns ~10 pages back, but I'll humor you.
My prototype has a layer of indestructible portal blocks both above and below the vault (in both the overworld and nether). Both layers are 1 block tall. The layer below the vault sits on top of the void, and is bounded by bedrock. The layer above the vault is about 8 blocks above the vault ceiling and is bounded on all 6 sides by bedrock. These layers are indestructible because there is no valid adjacent location to drop a block or fluid (water and lava extinguish portal blocks). The bedrock occupies the space nearby, and the portal blocks occupy the layer (you can't place anything directly into portal blocks).
The only locations that can possibly lead to the correct portal inside the vault occupy a very small volume in nether-space, and that region is bounded by the nether bedrock box.
The vault entrance portal is nearby some lit netherrack blocks. When the vault is triggered to open, two wood blocks are pushed into position close enough to the obsidian frame to catch fire from the netherrack such that the obsidian frame is ignited by the wood blocks are not consumed. This is a pseudorandom process and takes anywhere from 1-20 seconds for the flame to propagate. When the vault is triggered to close, a piston is retracted briefly allowing a splash of water into the frame which extinguishes the portal. Another block is extended by a piston into the frame, blocking off the necessary 2x3 open space which could otherwise be a valid destination for a portal from the nether.
And yes, Mystify is correct; all this has been discussed and explained before. Please make an effort to read that discussion and examine the prototype I've uploaded before asking more questions.
0
0
If you use 16 of these for a 16-bit data register, a 7% failure rate means you have a 71% chance of an error every time you write a 16-bit word to the register. This is unacceptable.
0
The shorter of the two delays determines how soon the piston extends. The longer determines how soon it retracts.
0
2.13 / ((4 quarter notes / 1 measure) * (1 measure / 3 quarter note triplets)) = 1.6 quarter note triplets per second or 0.625 seconds per quarter note triplet
Redstone ticks are 0.1s long, so the closest you can get is 0.6s per quarter note triplet. If you're using the rising edge of the signal to trigger your note block, you need a 3-clock for the right timing. Unfortunately that doesn't mix well with any clock you'd use to create standard quarter notes since the equivalent would be 3/4 * 3-clock = 2.25-clock which isn't possible to make.
The next best thing to do might be to use a 4-clock for your triplets and 3-clock for your quarter notes. This would make your song a bit slower though:
0.6s per quarter note = 1.667 quarter notes per second = 100 bpm