If you use pressure plates as the input devices, phasing is entirely prevented, because you can't phase downward (or so I hear).
Or you could do this to transfer power down through corners:
Regarding portals:
The number of dummy portals you have equals the size of the griefing party you can thwart. Build as many as the number of people the server can allow, and you're secure.
EDIT: No, wait, you could break them one by one and kill yourself to come back to the real world. It would be a massive waste of diamond picks, but it's possible.
I believe recessing the buttons in a 1 deep hole also solves this problem.
Rollback Post to RevisionRollBack
The opinions expressed in this post do not necessarily reflect the views of speaker, and may contain significant levels of: a) trolling flaming c) spamming
I do or do not use periods and capitalization based on my mood.
Don't credit me with that I think I first saw it in Grizdale's prototype :smile.gif:
Rollback Post to RevisionRollBack
The opinions expressed in this post do not necessarily reflect the views of speaker, and may contain significant levels of: a) trolling flaming c) spamming
I do or do not use periods and capitalization based on my mood.
The number of dummy portals you have equals the size of the griefing party you can thwart. Build as many as the number of people the server can allow, and you're secure.
Not quite. since the portal is destroyable, it is possible to suicide in them. Destroy the portal, then drop sand above your head. Suffocate. Respawn. Now the portal is disabled. Detectign that this is the case, and fixing it, through bedrock, would be tricky to impossible without editing aids, so they could probably disable the dummy portals before you even arrive to enter your code.
Not quite. since the portal is destroyable, it is possible to suicide in them. Destroy the portal, then drop sand above your head. Suffocate. Respawn. Now the portal is disabled. Detectign that this is the case, and fixing it, through bedrock, would be tricky to impossible without editing aids, so they could probably disable the dummy portals before you even arrive to enter your code.
Hmm...I don't think there's a way around this. There's always a way to suicide, even in a Nether Portal. Perhaps an admin could hack the spawn? (I don't know much about changing spawns, sorry).
I was only thinking about this in regards to the trap portals, but it is a vulnerabilty of the current design. If a greifer gets through the first gate, they can destroy both nether portals in the cooridor, and there would be no way in.
How about we have a "Takes a long time to access" locks to the cooridor itself? If it is greifed, it allows access to repair it. You still have to check the cooridor and make sure noone is trying to break in, and be sure you spend less time in the vault than it takes to get through the lock.
To detect the "other person is portaling past you" issue, you create a redstone counter hooked to a clock. This has a visible redstoen torch display iin the cooridor. This allows you to see how long the circuit has been active. So you check, and note the current time. Leave to the overworld. Make sure no one is here. Go back. If the time has advanced since you were present, somebody is there. Make the clock have a long enough time that it is not going to complete a complete cycle in the timespan of the checks. This will also detect people nearby in the nether, so you want to set up a "no access allowed" region. This could be done by making the entire area solid bedrock.
So you can ensure nobody is withing the outer vault, enter your code, enter the inner vault, and leave.
If someone cannot breach the outer vault in time, then the inner vault is unbreachable. The outer vault does not even have the possible vulnerabilty of someone finding the code, since it is locked and unlocked from inside. It only prevents access while someone is accessing the vault.
So now the issue is to make sure there is no fast way into the inner vault. The main vulnerability I see is someone making their own portal that will link to the nether coordidor. To combat that, there can't be anyplace you can make a portal close enough to the vault to connect to those portals. I have no clue what scale is required for that.
But we need to ensure there is no possible monkeying with nether portals to establish a link.
Not quite. since the portal is destroyable, it is possible to suicide in them. Destroy the portal, then drop sand above your head. Suffocate. Respawn. Now the portal is disabled. Detectign that this is the case, and fixing it, through bedrock, would be tricky to impossible without editing aids, so they could probably disable the dummy portals before you even arrive to enter your code.
Enclosing the dummy portals in something other than bedrock might be an option. Remember this is a countermeasure to time-sensitive intrusion, so the criteria for success are more flexible than for the vault itself. Nearly-enclosing the dummy portal in bedrock, then leaving a 1Wx2H space in the enclosure filled with obsidian instead, would make the dummy portal repairable without admin support, and would provide a means of verifying your countermeasures are intact before attempting to access the vault. Each dummy portal would still take at least 15s to disable, and since the only point of these dummy portals is to delay intrusion while the user is between the code entry and vault re-locking steps, I think it still serves its purpose.
Enclosing the dummy portals in something other than bedrock might be an option. Remember this is a countermeasure to time-sensitive intrusion, so the criteria for success are more flexible than for the vault itself. Nearly-enclosing the dummy portal in bedrock, then leaving a 1Wx2H space in the enclosure filled with obsidian instead, would make the dummy portal repairable without admin support, and would provide a means of verifying your countermeasures are intact before attempting to access the vault. Each dummy portal would still take at least 15s to disable, and since the only point of these dummy portals is to delay intrusion while the user is between the code entry and vault re-locking steps, I think it still serves its purpose.
Except they could disable the portal, then plug the hole back up with obsidian, or whatever else you are using. Now the portals are disabled, but a quick visual check does not ensure that it is the case.
To detect the "other person is portaling past you" issue, you create a redstone counter hooked to a clock. This has a visible redstoen torch display iin the cooridor. This allows you to see how long the circuit has been active. So you check, and note the current time. Leave to the overworld. Make sure no one is here. Go back. If the time has advanced since you were present, somebody is there. Make the clock have a long enough time that it is not going to complete a complete cycle in the timespan of the checks. This will also detect people nearby in the nether, so you want to set up a "no access allowed" region. This could be done by making the entire area solid bedrock.
This is a fantastic idea, thanks. The implementation is even simpler than you describe though. We could just set up a monostable circuit in both overworld and nether. Hit the 'activate' button on a monostable circuit that takes 2x the portal phase time (the time between stepping into portal frame and being transported to other realm) to reset. If no one comes near, the next time you come out you'll see the monostable circuit on for about 3-4s before it turns off. If someone was present, the monostable circuit will be off as soon as you come back.
So now the issue is to make sure there is no fast way into the inner vault. The main vulnerability I see is someone making their own portal that will link to the nether coordidor. To combat that, there can't be anyplace you can make a portal close enough to the vault to connect to those portals. I have no clue what scale is required for that.
But we need to ensure there is no possible monkeying with nether portals to establish a link.
If we have no dummy portals nearby, we'd need to fill the overworld at a radius of 1024 blocks from the overworld-coordinates of portals B and C.
Dummy portals significantly cut this requirement down though. If we have a 1-block thick wall between portal B and its dummy portal, I believe that leaves only a 12 block radius in the overworld that would prefer portal B over its dummy portal. We could have 5 dummy portals surrounding the nether corridor (1 each for +x, -x, +z, -z, and +y; -y is not needed since it is built on the void). We'd then build walls for the outer vault such that no space outside the outer vault is within 12 blocks of portal A or D.
Except they could disable the portal, then plug the hole back up with obsidian, or whatever else you are using. Now the portals are disabled, but a quick visual check does not ensure that it is the case.
I am assuming that we'd need more than a quick visual check. It may not be practical, but I don't think it's a requirement annoying enough to constitute a successful grief.
A long 1x1 hole leading into the dummy portal enclosure, with a glass block on the end proximal to the portal, would give the user a viewport to confirm the portals are active. I think you could design it to be difficult enough to enter to deter time-sensitive intrusion.
This is a fantastic idea, thanks. The implementation is even simpler than you describe though. We could just set up a monostable circuit in both overworld and nether. Hit the 'activate' button on a monostable circuit that takes 2x the portal phase time (the time between stepping into portal frame and being transported to other realm) to reset. If no one comes near, the next time you come out you'll see the monostable circuit on for about 3-4s before it turns off. If someone was present, the monostable circuit will be off as soon as you come back.
What stops the intruder from activating the circuit themselves?
Your all over thinking it - its this simple:
The correct code will launch a Storage minecart over to a 1 by 1 window in the bedrock, so you can get to your items.
Unless the right code is put in, the minecart won't come over to the window, and there isn't another way in, as its made of bedrock!
and if you pour water into that hole it is griefed and you can't get your items
Rollback Post to RevisionRollBack
The opinions expressed in this post do not necessarily reflect the views of speaker, and may contain significant levels of: a) trolling flaming c) spamming
I do or do not use periods and capitalization based on my mood.
What stops the intruder from activating the circuit themselves?
Nothing, I suppose.
I now see the significance of what you said "Make the clock have a long enough time that it is not going to complete a complete cycle in the timespan of the checks." We'd have to design/protect the circuit in such a way that the intruder can't re-activate the circuit mid-cycle. This would be easy enough to do by putting the circuitry inside the inner vault, and gating the activation button with a piston transistor.
I now see the significance of what you said "Make the clock have a long enough time that it is not going to complete a complete cycle in the timespan of the checks." We'd have to design/protect the circuit in such a way that the intruder can't re-activate the circuit mid-cycle. This would be easy enough to do by putting the circuitry inside the inner vault, and gating the activation button with a piston transistor.
That would work, but you'd need to fine-tune the timing so would be obvious if its turning off at the wrong time, but long enough that it won't turn off early and let them reactivate it.
That would work, but you'd need to fine-tune the timing so would be obvious if its turning off at the wrong time, but long enough that it won't turn off early and let them reactivate it.
couldn't you have a button linked to a series of repeaters ending in a note block? you hit the button and go through portal A, when you come out of portal D if you don't hear a note you know someone is nearby.
You could encase all but the button in bedrock.
Rollback Post to RevisionRollBack
The opinions expressed in this post do not necessarily reflect the views of speaker, and may contain significant levels of: a) trolling flaming c) spamming
I do or do not use periods and capitalization based on my mood.
That would work, but you'd need to fine-tune the timing so would be obvious if its turning off at the wrong time, but long enough that it won't turn off early and let them reactivate it.
I'm thinking an intruder would be in the vicinity of the circuit at least 10s before he makes from outside the sight range of the user to inside portal A. Should be easy to keep track of the timing to within a 10s resolution.
so here is a quick prototype not adding pictures though my internet seems a bit slow right now and wont let me upload them. http://www.mediafire.com/?y5qfn1gmmw8lrk3
it's pretty simple to understand so it's probably easier to just play the map rather than me explain it all.
What is with all of this discussion with portals? Last time I checked, this was the most viable design (also one of the simplest), what happened to it?
Or you could do this to transfer power down through corners:
Regarding portals:
The number of dummy portals you have equals the size of the griefing party you can thwart. Build as many as the number of people the server can allow, and you're secure.
EDIT: No, wait, you could break them one by one and kill yourself to come back to the real world. It would be a massive waste of diamond picks, but it's possible.
I do or do not use periods and capitalization based on my mood.
I will leave the anti-phasing techniques to you.
Don't credit me with that I think I first saw it in Grizdale's prototype :smile.gif:
I do or do not use periods and capitalization based on my mood.
Not quite. since the portal is destroyable, it is possible to suicide in them. Destroy the portal, then drop sand above your head. Suffocate. Respawn. Now the portal is disabled. Detectign that this is the case, and fixing it, through bedrock, would be tricky to impossible without editing aids, so they could probably disable the dummy portals before you even arrive to enter your code.
Hmm...I don't think there's a way around this. There's always a way to suicide, even in a Nether Portal. Perhaps an admin could hack the spawn? (I don't know much about changing spawns, sorry).
How about we have a "Takes a long time to access" locks to the cooridor itself? If it is greifed, it allows access to repair it. You still have to check the cooridor and make sure noone is trying to break in, and be sure you spend less time in the vault than it takes to get through the lock.
To detect the "other person is portaling past you" issue, you create a redstone counter hooked to a clock. This has a visible redstoen torch display iin the cooridor. This allows you to see how long the circuit has been active. So you check, and note the current time. Leave to the overworld. Make sure no one is here. Go back. If the time has advanced since you were present, somebody is there. Make the clock have a long enough time that it is not going to complete a complete cycle in the timespan of the checks. This will also detect people nearby in the nether, so you want to set up a "no access allowed" region. This could be done by making the entire area solid bedrock.
So you can ensure nobody is withing the outer vault, enter your code, enter the inner vault, and leave.
If someone cannot breach the outer vault in time, then the inner vault is unbreachable. The outer vault does not even have the possible vulnerabilty of someone finding the code, since it is locked and unlocked from inside. It only prevents access while someone is accessing the vault.
So now the issue is to make sure there is no fast way into the inner vault. The main vulnerability I see is someone making their own portal that will link to the nether coordidor. To combat that, there can't be anyplace you can make a portal close enough to the vault to connect to those portals. I have no clue what scale is required for that.
But we need to ensure there is no possible monkeying with nether portals to establish a link.
Enclosing the dummy portals in something other than bedrock might be an option. Remember this is a countermeasure to time-sensitive intrusion, so the criteria for success are more flexible than for the vault itself. Nearly-enclosing the dummy portal in bedrock, then leaving a 1Wx2H space in the enclosure filled with obsidian instead, would make the dummy portal repairable without admin support, and would provide a means of verifying your countermeasures are intact before attempting to access the vault. Each dummy portal would still take at least 15s to disable, and since the only point of these dummy portals is to delay intrusion while the user is between the code entry and vault re-locking steps, I think it still serves its purpose.
Except they could disable the portal, then plug the hole back up with obsidian, or whatever else you are using. Now the portals are disabled, but a quick visual check does not ensure that it is the case.
This is a fantastic idea, thanks. The implementation is even simpler than you describe though. We could just set up a monostable circuit in both overworld and nether. Hit the 'activate' button on a monostable circuit that takes 2x the portal phase time (the time between stepping into portal frame and being transported to other realm) to reset. If no one comes near, the next time you come out you'll see the monostable circuit on for about 3-4s before it turns off. If someone was present, the monostable circuit will be off as soon as you come back.
If we have no dummy portals nearby, we'd need to fill the overworld at a radius of 1024 blocks from the overworld-coordinates of portals B and C.
Dummy portals significantly cut this requirement down though. If we have a 1-block thick wall between portal B and its dummy portal, I believe that leaves only a 12 block radius in the overworld that would prefer portal B over its dummy portal. We could have 5 dummy portals surrounding the nether corridor (1 each for +x, -x, +z, -z, and +y; -y is not needed since it is built on the void). We'd then build walls for the outer vault such that no space outside the outer vault is within 12 blocks of portal A or D.
I am assuming that we'd need more than a quick visual check. It may not be practical, but I don't think it's a requirement annoying enough to constitute a successful grief.
A long 1x1 hole leading into the dummy portal enclosure, with a glass block on the end proximal to the portal, would give the user a viewport to confirm the portals are active. I think you could design it to be difficult enough to enter to deter time-sensitive intrusion.
What stops the intruder from activating the circuit themselves?
and if you pour water into that hole it is griefed and you can't get your items
I do or do not use periods and capitalization based on my mood.
Nothing, I suppose.
I now see the significance of what you said "Make the clock have a long enough time that it is not going to complete a complete cycle in the timespan of the checks." We'd have to design/protect the circuit in such a way that the intruder can't re-activate the circuit mid-cycle. This would be easy enough to do by putting the circuitry inside the inner vault, and gating the activation button with a piston transistor.
That would work, but you'd need to fine-tune the timing so would be obvious if its turning off at the wrong time, but long enough that it won't turn off early and let them reactivate it.
couldn't you have a button linked to a series of repeaters ending in a note block? you hit the button and go through portal A, when you come out of portal D if you don't hear a note you know someone is nearby.
You could encase all but the button in bedrock.
I do or do not use periods and capitalization based on my mood.
I'm thinking an intruder would be in the vicinity of the circuit at least 10s before he makes from outside the sight range of the user to inside portal A. Should be easy to keep track of the timing to within a 10s resolution.
What is with all of this discussion with portals? Last time I checked, this was the most viable design (also one of the simplest), what happened to it?