SecretPassage
Secret Passage
Have you ever wanted to create a wall that could disappear at a touch? Or a massive pit to trap your "friends" in? Are pistons just not enough to make the secret door of your dreams? Look no further!
Credit:
I did not come up with the original idea of this plugin. During the days of hMod and Alpha, I played on a server called "Kingdom of Strongholds", run by Rockslide. A few weeks before the server was shut down, a plugin similar to this one was added, and it was a blast to use. Sadly, I haven't been able to find anything like this for hMod or Bukkit, so I opted to write my own version from scratch...
Also, I would like to thank @nisovin for helping me solve an inventory issue.
How to Install:
Download the .jar file and place it in your plugins folder. Start the server as normal. Then, stop the server and modify the config.yml file in plugins/SecretPassage/ to your liking. Finally, restart the server.
How to Use:
1) Start by building the shape of the structure out of any of the "active materials" you chose in the config. If you didn't change the config, use either Netherrack or Sponge. (I made this for a server with no nether, so netherrack isn't common...)
2) Type in the command below to create a passage. It's worth noting that you can change the "create" part of the command in the config file, so it may be different based on what you entered.
3) Hold the block that you want to replace the active material with, and punch it. If the material is allowed (also in config), the active material will absorb the item you're holding, and change to look like it. Repeat this until you have the structure built - you can safely place more active material if you need to, the plugin will only respond if the active material is punched while holding another item. By default, any solid block unaffected by gravity (aside from netherrack and sponge) can be used to decorate a passage.
3b) If you punch (and activate) the wrong block, you can break it to remove it from the structure. Doing so will not return the active material used, so that will need to be placed again.
4) Place another active block somewhere that you'll remember, then hold one of the items you chose for creating switches (in config) and punch it. The block will absorb the item and change into another material (chosen in config) to show that it is now a switch block. By default, you use a stone button to make switches, which turn into wooden planks for confirmation.
5) If desired, break the switch block and replace with another block of your choosing. It must be selectable with a right-click to work (so no water, lava or air).
6) Right-click the switch to test if the gate is working. If so, all the blocks you placed in step 3 will turn into air. Right-click the switch again to bring the structure back.
7) Type the command /spass to end the passage construction process. You can always come back and modify it by using the create command again.
Command List:
- /spass [Alias: /sp, /secretpassage] The main command for the plugin. Also ends the passage building process.
- /spass create* (PassageName) - Starts building on the named passage, creating it if necessary.
- /spass destroy* (PassageName) - Destroys a passage you own (blocks are not removed). You can give a permissions node to let people destroy any passage on the server.
- /spass destroy* switch - Sets you up so that a switch bound to the next block you right-click on is destroyed.
- /spass list* - Lists all the passages that you own, in order of creation.
- /spass list* (PlayerName) - Permissions-based command that lists passages owned by the named player.
- /spass toggle* (PassageName) - Permissions-based command to toggle a named passage, provided you are in the same world.
- /spass reset* - Permissions-based command that resets all passages based on redstone power to switches.
- /spass timer (ticks) - Adds a reset timer to auto-close the passage after a set delay (specifically built to prevent making it accidentally auto-open...)
- /spass timer 0 - Removes the timer of the passage you are working on.
- /spass info (Passage Name) - Provides information on the listed passage. If you do not give a passage name, it provides information on the passage you are working on (if any).
- /spass help - Lists all basic commands you have access to, as well as the proper structure for typing them.
- /spass access - Lists the commands for working with white or black lists for passages.
- /spass access allow (Name) (Name) (Name) (Name) - Adds the names included to the whitelist of your current passage, and sets the passage to use a whitelist.
- /spass access deny (Name) (Name) (Name) (Name) - Adds the names included to the blacklist of your current passage, and sets the passage to use a blacklist.
- /spass access remove (Name) (Name) (Name) (Name) - Removes the name from the whitelist/blacklist of your current passage.
- /spass access clear - Removes the access restrictions on your passage, allowing anyone to use it.
Features:
- Create structures that can disappear.
- Includes option to prevent blocks in passages from being broken (to stop easy duplication)
- Includes options to consume resources when decorating passages, as well as the ability to choose what can be used in their creation.
- Choose your own commands to replace create, destroy, toggle, and list.
- Includes option so that only the owner of a passage (or an op) can modify it, while anyone can use the switches made by them to toggle the passage.
- More than one switch can be assigned to a passage, but only one passage can be assigned to a switch.
- Passages do not have to be continuous, but cannot have blocks on multiple worlds. You could build a disappearing village if you felt so inclined.
- SuperPerms support (as of v1.0)
- Preliminary Redstone support (as of v1.2)
- Ability to have passages close themselves after a set delay (as of v1.4)
- Provide access on a passage-by-passage basis (as of v1.6)
- If passage protection is active, pistons will break when trying to push a passage block, and cannot pull out a passage block if sticky (as of v1.6)
Permissions Nodes:
- secretpassage.* - Provides all nodes other than lockout and deny (Default: Op)
- secretpassage.create.other - Allows user to bypass the owner-only protection option if it is enabled
- secretpassage.destroy.other - Allows user to destroy any passage on server, regardless of owner
- secretpassage.list.other - Allows user to check passages owned by other players
- secretpassage.toggle - Provides access to the toggle command
- secretpassage.reset - Provides access to the reset command.
- secretpassage.lockout - Prevents user from using any portion of the plugin
- secretpassage.antilockout - Prevents admin using all-nodes plugins from accidentally barring themselves from using plugin
A Note on Other Plugin Support: While a lot of other plugins are great matches with this plugin (iConomy, etc), I will not be personally adding support for these options. However, the source code is included in the .jar file, so that anyone who wants to make changes can take a crack at it. Sadly, I'm not the greatest at uniform code structure or commenting, so the only assistance you'll find in there is a small comment at the top of each function to describe it.
If you add a feature that you believe should be shared, I have a request: share it here and alert me, that way I can take a look at it. I'll test it and add it as a proper version, making sure to include your name in the credits section.
timer reverse.. its in help but doesnt appear to work.
I want my "door" ... er draw bridge, default open
Does it work for 1.7.9?
I don't mean to sound pushy, but I was wondering if you've forgotten to upload a new build, or put off working on this plugin due to other priorities and such. Either way, totally understandable, but I just wanted to ask.
@CommodoreAlpha
Like I said below, it was during the early days of Bukkit having a permission system (the permissions plugins had been out for a while, but were all using their own methods). I had tried checking for nodes to allow or deny, but issues constantly occurred with them. Hilariously, the exact same logic worked just fine when determining op-level bypass for passages, so I eventually scrapped it and put in the white/blacklist that currently exists. I'll see what I can do to make a permissions option work alongside the white/blacklists.
And I'll add the "ID-Name" option as well, as that's relatively simple to do.
@Professor29
Wow, you really responded much earlier than I thought.
I didn't realise that server-owned, permissions-based passages would be difficult to implement (but then again, I'm ignorant in how coding plugins actually works). Couldn't you just check for "x" custom node (e.g. secretpassage.use.<passagename>) when a player tries to open up a passage via a secretpassage-button?
For your "ID-Name" paragraph, that's exactly what I mean. Have a certain item in hand, "admin punch" a block, and get the information on the passage it's tied to. But only if you have the permission node to get this information (don't want normal players admin-punching blocks).
I don't really mind when you'll finish the update, actually; just take your time. And thank you for responding to my comment. :)
@nunnun23
I can't really do passwords with how the system is currently set up, as it would have to be command-driven plugin toggling (which currently is an all or nothing permission node for admin control).
@CommodoreAlpha
While I haven't done any work on this for the last several months, I am planning on doing an update to ensure that the plugin doesn't break when item IDs are removed from the system, as well as to incorporate some great improvements that IBCodin was willing to send me code for. As such, I have no problems with extra features being added at the same time, as long as I can guarantee they work.
For the "owner-less, permission node" passages, I'm willing to give it another shot. When Bukkit first added their internal permission system I attempted to have allow/exclude permission nodes for passages, but it was NOT working correctly. As such, I will TRY, but I am sadly skeptical.
For ID-name, I'm not quite sure what you're asking for. Are you asking to be able to "admin punch" a block and have it declare information on the passage its tied to? If so, that's not hard for me to add, I'm just trying to determine what you're looking for.
As far as when the update will be done, I don't really have an ETA, sadly. However, I do check this page at least once a week, and I have PMs notify me via e-mail to get my attention sooner.
I don't know if you're still willing to add extra features, but I've a few feature requests concerning the creation of secret passages.
Would it be possible to create owner-less passages, then add permissions to groups rather than players? Or perhaps each passage could be set to require some customised permission node.
Would it also be possible to get the ID-name of a secret passage by punching a secret-passage-block with a certain item and permissions node? That way, it will be easier to perceive which blocks are part of a secret passage (and which passage it belongs to) and which aren't.
Hey! Could you add passwords for the secret passages :)
Thanks ! (does it work with 1.6.2 ? )
@IBCodin
I'd love to take a look at the changes. I'm not the best at object orientation, and I know the code has a lot of issues. Honestly, been debating on reworking it from the ground up, and it sounds like you've done a couple of the changes I've been looking to implement. Send me a PM when you can. :D
I was having some issues with the 1.6 version, so I took advantage of the source in the jar and re-built the plugin.
One thing i did, that I didn't need to, but that might make importing my code problematic was to strengthen the object orientation. I made things more private and had to re-arrange quite a bit of code.
I 'lost' the lockout and antilockout permissions and added use permission (if you don't have it, you're locked out) and an admin permission which allows you to act as the owner of all passages. I also disabled the redstone update (I found it didn't quite work like I expected and it used a lot of cpu).
The other thing I did was to re-vamp the file storage to one file per passage. I used the bukkit yaml support to do it. This is a sample passage file:
I haven't posted the code anywhere, I originally only planned to use it personally.
If you would like to see the java code that reads/writes the passages let me know.
We could share code fragments here or all of the code somewhere else. I use GitHub and would be willing to put my code there if that would work.
@CommodoreAlpha In 1.6 it does not. Since I had the listener for redstone tied into block updates, the only thing disabling in the config will do is make it not react to redstone, but the plugin will still listen. This is changed in 1.7, which is awaiting approval from the mods. When disabled, the listener for redstone is never activated, and it should run faster. As far as a more efficient way of running it, I'm unsure if there's a way to do so, as I have to check each passage to see if a switch was activated by any part of the redstone...
@dalatorabvon21 In 1.6 there is not. However, there is an option in 1.7, but it's in two parts. Your config file will get an extra option called "use-command-permission" (just before the part that lets you name the main commands). Set that to "true", and anyone who is authorized to use commands will need a new permission node "secretpassage.useCommands". Anyone without that node cannot use commands, but they can activate switches just fine.
Hate to be a bother, but I've wondered this for a while. Is there a way for me to make it so my players can hit switches without giving them the permission to create a passage? I haven't seen a permission node that would allow that.
Any suggestions?
For some reason, whenever I run something that is repetitive and "redstone-intensive", this plugin tends to take a bigger chunk of the CPU than I expected. According to NoLagg, it's based on the BlockRedstoneEvent coming from this plugin, more specifically the SPBlockListener. Why I was surprised was that I was using redstone circuits that had absolutely nothing to do with this plugin, yet this plugin still consumed more CPU than I thought it would. And it only occurs when playing with redstone.
I was wondering if there is any method you can implement that would be more efficient than the current method. The plugin isn't causing any massive lag spike, it's just taking more CPU than I thought it would (which occurs in spikes, not at a constant rate).
I noticed you can turn off activation of SecretPassages via the config.yml; if I did that, would it disable the redstone aspect of the plugin from activating at all (and thus reducing lag)?
The 1.4.7 version works perfectly fine on my 1.5.1 server. Great, great plugin, and please keep it up!
@harryjamesuk
Glad you enjoy it and keep it around. And yes... I've stalled making this page for far, far too long...
@MAXIMUSSPRIME
Great suggestion, and I actually have that in the version I'm working on finishing right now. Main thing is to add a permission node for basic features, as well as modifying the config to actually update itself like I planned to a very long time ago. I hope to have it out soon... I am horrible at maintaining deadlines.
Yey! BukkitDev!
I've been with your mod for 14 months now, It's awesomez.
I've got a suggestion: Timed close, maybe you could make it so that if you punch the active block with a lever the passage works how it does now (stays open), but with a button it closes after a possibly configurable amount of time.
Anyways, please consider this suggestion and thank you :)
@MAXIMUSSPRIME
Happy to help. This plugin is actually about 18 months old (hence why I released at 1.6), but I've been delaying making a page on BukkitDev. If you have suggestions, don't be shy! I've only got a few more ideas for this plugin, but I'd love to keep expanding it. Just post 'em in the forums thing for the project - I'd love to hear them.