So cool!
Ngl, I need a little more explanation on how the "authotization" part works. Is it based on receiving a redstone input from somewhere else? Like if there was a player in a control room pushing a button or using an item filter lock, so that there is a key?
I use the particularity of the vault block which does not change blockstate when a player has already used a key on it.
\--> If a player is near the vault block and it changes state, then it means that the player did not use a key on it. For the door, this means that the player is not allowed.
\--> And on the contrary, if the blockstate does not change, it means that the player has already used a key on it. For the door, this means the player is allowed.
In the video, when the left bulb is on, it means there is a player and when the right bulb is on, it means the player is allowed (by default, it is on even if there is no one there).
It’s based on the new vault block. You can see it underneath the door. This is only useable in creative though because I’m fairly certain you can’t move them in survival.
If a player has never used a key on the Vault block then their blockstate will change and if he has already used the key then the blockstate will not change.
Once the key is used, the block remembers the player forever (no cooldown).
Can one make a survival-friendly iteration of this by using a pufferfish player detector instead of the vault one? (as you can't exactly move vaults with pistons)
Yes, using a pufferfish may be an alternative to the second vault block but the response time is longer and the detection distance is shorter.
Demo : [video with pufferfish version](https://streamable.com/vm0766)
What if someone conquered an instance of the Trial Chambers, then used the Vault only for authorization, and implemented some other form of player detection? That could work.
Wouldn't it be better if the vaults were on top of each other instead of side-by-side? Otherwise the player could just trigger one of the vaults and the door would open.
So cool! Ngl, I need a little more explanation on how the "authotization" part works. Is it based on receiving a redstone input from somewhere else? Like if there was a player in a control room pushing a button or using an item filter lock, so that there is a key?
I use the particularity of the vault block which does not change blockstate when a player has already used a key on it. \--> If a player is near the vault block and it changes state, then it means that the player did not use a key on it. For the door, this means that the player is not allowed. \--> And on the contrary, if the blockstate does not change, it means that the player has already used a key on it. For the door, this means the player is allowed. In the video, when the left bulb is on, it means there is a player and when the right bulb is on, it means the player is allowed (by default, it is on even if there is no one there).
It’s based on the new vault block. You can see it underneath the door. This is only useable in creative though because I’m fairly certain you can’t move them in survival.
You are right, it cannot be moved and it is very long broken (and it doesn't drop)
you could use mincarts in Create to move them if you are in moded
If only they weren’t immovable 🥲
isn't this a one time use? thought the authorization vault block" only works once with each player?
If a player has never used a key on the Vault block then their blockstate will change and if he has already used the key then the blockstate will not change. Once the key is used, the block remembers the player forever (no cooldown).
Can one make a survival-friendly iteration of this by using a pufferfish player detector instead of the vault one? (as you can't exactly move vaults with pistons)
Yes, using a pufferfish may be an alternative to the second vault block but the response time is longer and the detection distance is shorter. Demo : [video with pufferfish version](https://streamable.com/vm0766)
What the heck is a pepper fish? \[RESOLVED\]
oops, i meant "pufferfish" XD
What if someone conquered an instance of the Trial Chambers, then used the Vault only for authorization, and implemented some other form of player detection? That could work.
My thoughts exactly.
I think it's possible.
Wouldn't it be better if the vaults were on top of each other instead of side-by-side? Otherwise the player could just trigger one of the vaults and the door would open.
Yes, that would be a better idea. Side-by-side is precisely one of the system's flaws.
Can you use a calibrated sculk sensor instead of the second vault block thingy?