- No databases. In-game signs only.
- Super permissions support ONLY.
- Protects any type of furnace, dispenser, chest, door, trapdoor, cauldron, enchantment table, or brewing stand.
- Broadcast specific admin actions to those with "deadbolt.broadcast.xxx"
- Denies explosions, pistons, and redstone from circumventing protection
- Timed doors, [Timer:#], that toggle after a certain delay
- Server-wide protected blocks, use [Everyone] on line 3 or 4
- Modular plugin hooking system, add your own easily
- Compatible with Lockette
- Optional sign coloring
- Localization support
As this is a Lockette-type plugin, also similar to Alerter or BlockLock, things may seem similar. This plugin was originally created as a continuation of Lockette by Acru to add trapdoor support and other recent developments. Portions of this project were reverse engineered from Lockette and the original idea for a sign-based locking system still belongs with Acru. Credit where credit is due. As this only supports super permissions, if you need a plugin that is more backwards compatible with older configurations, you may want to look at Lockette.
If you have another plugin such as Cenotaph or ChestShop3 that you have integrated with Lockette and would rather use Deadbolt instead, I have created a LocketteSimulator that will allow you to use Deadbolt.
Check GitHub for the most recent files, there is a slight delay in getting files posted here authorized by the staff.
Place a sign next to the item you want to protect and type in the following
- Line 1: [Private]
- Line 2: Your name will be automatically filled, users with "deadbolt.admin.create" can specify someone else.
- Lines 3 and 4: You have a couple options for these lines
- Another player's name
- Unrestricted access via [Everyone] while preventing breaking
- Create an automatic timed door using [Timer:1] through [Timer:9]
Not enough room for all the names you need? Make another sign with the [More Users] on line 1
For ease of use in maintaining your signs without having to break them:
- Right click the sign to select it.
- Use "/deadbolt <line number> <text>" to directly modify that line.
When placing signs, valid locations are to the NORTH, SOUTH, EAST, and WEST of the target block.
Other valid blocks include:
- Doors: The blocks above and below.
- Trapdoors: The block that it is attached to (hinge-block) and directly above/below the trapdoor itself.
- Fence gates: Any block horizontally adjacent to the gate itself.
Use your imagination and hide those unsightly signs under walls.
Also, color is now available! Just add "deadbolt.user.color" and use &1-9,a-f in your sign.
DeadboltListener is a new system designed to incorporate your favorite plugin directly into Deadbolt.
To create your own or to view Deadbolt's static API, head over to the Developer's Corner
Currently available for download
- PermissionsBukkit, PermissionsEx, bPermissions, GroupManager
[TownName] [NationName] (All residents) +TownName+ +NationName+ (Assistant/Mayor only) 4 Config options: mayor,assistant,wilderness overrides.
Have a completed localization? Drop me a link to it and Ill add it to the repository.
Once added, it is available for automatic downloading by changing the "language" setting in config.yml.
The following issues are known:
- Double timer doors are broken
- Force coloring of Signs placed directly onto walls is broken.
- Vertical trapdoor chaining has been removed because it was only half implemented
Visit github and open an new issue.
Alternatively, try and find me at play.arkcraft.net.
Builds were released as recently as 8 days ago with fixes for some stuff you mentioned. http://ci.md-5.net/job/Deadbolt/ But yeah with uuids this plugin becomes slightly less appealing.
The author hasn't addressed any of the comments posted here in well over a year.
We all know of the issues with the hoppers and hoppercarts and such sucking items out of locked containers, he has not addressed that in a year, not even if you hunt down just the dev versions.
The author is involved in a great number of projects.
The simplicity of deadbolt (and the plugin it was meant to continue when that author dropped off the world and the plugin went unrepaired, broken for ages) is based on the fact that the name is on the sign, the sign interaction gets the info needed, bam, done. No heavy database overhead storage system like other lock solutions, and bright and simple and visible to see.
The switch to UUIDs as the persistance identifier with namechanges means the entire infrastructure plan of such plugin is out the window, as the readable names on the sign will not be reliable. A heavy database is required to store the information one way or another, taking the simplicity of the solution out of the equation.
_A_ possible db-compromise solution would be to log every sign location and uuid, and a cross-up of uuid/username in the db, and check when a player logs in if their name has changed and uuid is found in the db, then update every sign on the map with their old name to the new name. Then rather than using the db all the time for lookups, only those rare instances where an existing sign-holder name changes, and the rest of the time the plugin still works based on the sign-coverages. However, this could turn into a great way to lag out a server as well during the login event, and would require some well done scheduling and checks to avoid lag. But even if only one sign per minute got changed I'd call that fair punishment for the user to have to wait.
I will be using such a solution in one of my own server plugins that uses names on signs.
I have serious doubts that this plugin will continue, even the Lockette curator has expressed in other threads that there is no sense in continuing with Lockette since the whole point was lightweight security and the neccesity to have everything now in a database to make any bridge solution like mine work is still a lot of trouble and bother. I expect this author to have similar "Let this be the end" plans, and spend time and resources on other battles that are worth fighting.
Assume that we have seen the last update here eons ago, and make contingency plans. Be pleasently surprised with myself if the author corrects me "Alas, I am working on a transitioning device, and will support this! And it will have the hopper-theft issue sorted out too! " but otherwise, for practical considerations, this plugin should be marked as abandoned and considered as working, but at high risk. It will continue to work in 1.8, the same way it is now, it just wont support the player changing his name - those signs are locked in stone and might as well be some other user - and if a user abandones his name and a different person picks up the old name, the locked in stone signs will allow the new person to have access to all those signs.
Block users with changed names from logging into the server, period (and there will be an infinite supply of such plugins to pick from, that will be the new my-plugin-du-jour here) and deadbolt will function just as it has for the past year... Dont block them, and its just a low risk situation of the A->B, C->A two player renaming event with player C now getting all of player A chests, both A and C end up losing their original sign lockages as soon as they change names... I dont know about your servers, but mine has enough regulars who are going to race to change names, and I dont want to chase around breaking all their signs one by one... But I wont block changed-names from joining, so I need to plan on Deadbolt being Dead then.
Will it work in 1.8? Absolutely, the same as it is now, treating each name-change as a new and different person, and doing a perfect job of allowing only the named players access to the locked system. But it wont support x=Joe, Joe changes name to Bob, now x=Bob.
Will it be updated? It hasn't been updated in a year to address one particular well-harped, broadly known single-test case scenario, nor gotten a response from the author... The changes required for name-change support are not changes so much as totally rewriting the plugin and dropping a tonne of more stuff in on top of that, plus, a tonne more for coming up with a migration-solution getting servers from where they are now into a new solution. Thats like writing two whole plugins,with one being just a one-time task of importing/converting.
Based on that history, and that amount of future work required, and the fact that the plugin would be so incredibly different that it defeats the original purpose and may be insanely inefficient to code... dont count on this plugin changing one bit more without some other author picking up the ball and running with it.
Will this plugin be updating to use UUIDs?
Is it going to update to 1.7.2?
I agree, also got an error because of it and server crashed. http://pastebin.com/jdzgH6t5
Placing hoppers and hopper-carts below protected containers needs to be disabled.
1. The expire expires instantly when set to 30 days when a player tries to lock chest. I turn it off and it's all fine. Not sure whatsup. 2. Minecart hoppers can steal items..
Yeah your way behind. Even lockette has this issue as well.
If I will change from Lockette to DeadBolt will it reclaim all things or at least chests?
Possible to get an update to LocketteSimulator?
erm Hopper Minecarts can bypass the locks, is there a 1.6 beta build for this?
I am using PermissionsEX 1.19.5 and I only added deadbolt permissions to Veteran and above rank but defaults can lock too and the perms for locking are granted to all groups for some reason, why? how can I fix this?
Works fine with 1.6.2.
Can you add support for jukeboxes? I dont want my beats stolen :/
will this be updating to 1.6.2?
If you explain this a bit more, I could add this into FactionsPlus.
Is it possible to limit how many chests players can lock? So only one locked chest/item per player? That would be great.
Umm, the use of protecting signs has no use at the moment as you can use hoppers underneath to funnel items out! (I have tested this on my server) Please fix it, many griefers/raiders will use hoppers to funnel out items out of chests which makes players unhappy!
Can you add in a feature so that you can set Admin (op) Bypass off?