Inactive [MECH] CommandSigns v1.2.0 - Issue commands using signs[1317]

Discussion in 'Inactive/Unsupported Plugins' started by HansAnderson, Aug 26, 2011.

  1. Offline


    Version: v1.2.0

    This plugin is a complete rewrite of CommandSigns based off the original by Edward Hand. With CommandSigns, you can add invisible text or commands to signs. When the sign is right clicked, the command runs and/or the player gets a message.

    The /* feature of this plugin will not work properly with PermissionsExtended (PEX).
    There is a small issue where PEX doesn't utilize the permissions.yml from the root server folder.
    It has been tested with PermissionsBukkit and bPermissions.

    • Run commands from signs
    • Signs can have any other text on them, the commands are linked to the sign behind the scenes
    • Uses a new permissions node so that players can use commands they wouldn't normally have access to!
    How to use:
    1. Place a sign, add any writing you want
    2. Add lines to your clipboard with /commandsigns line<number> <text>
    3. Right click a sign to make it a CommandSign
    /commandsigns line<number> <text>
      - Add a line with one command (see Command Formatting). Number may be 0-9
    /commandsigns read
      - Read a CommandSign (the command lines associated with it)
      - Note: You need permission to create a sign in order to read
    /commandsigns copy
      - Copy a CommandSign to clipboard (the command lines associated with it)
      - Note: You need permission to create a sign in order to read
    /commandsigns clear
      - Clear your CommandSigns clipboard
    /commandsigns remove
      - Remove a CommandSign
    Command Formatting:
    In the place of <text> for a line, you may write a single command or sign formatting (such as @group). There are 10 total lines for separate commands or sign formatting. See Examples.
      -  Runs a command from the player who clicked the sign
      - Runs command with elevated permissions from the 'CommandSigns.permissions' node
      - Doesn't work for OP commands like /stop
      - (For WorldEdit //wand, use /*/wand)
      - Limits the sign use to only that group
      - **Check the permissions section below for usage!**
      - Print the message to the player's chat
      - Replaced in the command by the player's name
      - Replaced in the command by the player's x, y, or z coordinates
    examples (open)
    /commandsigns line0 \say Hello server! <NAME> just logged on.
      - "Hello server! <playername> just logged on."
    /commandsigns line0 \You just clicked
    \commandsigns line1 \a sign!
      - "You just clicked
          a sign!"
      - (Message sent to the  player who clicked)
    /commandsigns line0 /*warp point1
      - Warps the player to point1
      - (If the /* nodes are set up correctly)
    /commandsigns line0 @mods
    /commandsigns line1 /*warp point1
      - Warps the player to point1 only if they have the '' permission node
      - (If the /* nodes are set up correctly)

    permission nodes (open)
      - All permissions
      - All create permissions
      - Create signs without /* commands
      - Create signs with /* commands
      - Remove CommandSigns
      - Use all signs
      - Use signs without /* commands
      - Use signs with /* commands
      - Replace<group> with the group name from @group
      - Allows use of signs with the matching group name
    - Allows use of all @group signs

    In your permissions.yml (in main server folder) create parent node 'CommandSigns.permissions' and attach children nodes from plugins you want to give permissions for when using the /* prefix.
    permissions.yml example (open)
            warp.go: true
    Now using /*warp <somewhere> on a sign will allow a player who doesn't normally have access to the /warp command to use the sign.

    Download CommandSigns

    Version 1.2.0
    • Only one command per line now (commands can have many more syntax options)
    • Added ability to copy a CommandSign text to 'clipboard'
    • Fixed '*' permission node
    Version 1.1.0
    • Now supports all superperms permissions plugins!
    Version 1.0.1
    • Fixed a missing permissions node from the plugin.yml
    Version 1.0.0
    • Initial release

    I wanted the functionality of the old plugin, but the /* feature was broken. After becoming frustrated trying to figure out and update Fluff's version, I went back to the original and completely rewrote it. This is really my first plugin and Java experience.

    If this is not an acceptable submission, that is fine. I wrote it for my server and don't have time to go nuts adding features we don't need. However, I saw many people also wanted the /* feature, so I shared my work.

    I'm open to changing the name to something different, or withdrawing the submission. My main goal was to make this available to anyone who wants to use it.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 19, 2016
  2. Offline


    Thanks! I'm glad you like it. Economy support will be added. This weekend I should have some free time to work on it.

    I will be changing support from PermissionsBukkit to any superperms plugin very soon (that one defiantly this weekend). It's an easy change, and will only have a small impact on how it works. Basically, instead of inherent group support, you can assign 'group' permissions based off of permission nodes. If that sounds confusing, it will be explained more when the update rolls out.
  3. Offline


    Does it support annotate?
  4. Offline


    That would be quite neccessary for our server, too.

    Do you plan to add this?
  5. Offline


    It doesn't conflict with annotate, if that's what you're asking. If you are looking to add command functionality to any block, I believe that someone made a plugin for that.
  6. Offline


    I know, but it just hasn't the features of this plugin :3. I wanted to use as for buttons/plates like the old CommandSigns supported :D
  7. Offline


    UPDATE: 1.1.0
    I had a bit of free time. So I'm pleased to tell you that CommandSigns no longer is restricted to PermissionsBukkit use. It now supports all superperms permission plugins! Please refer to the new group usage in order to update your permissions to work accordingly. No changes in sign syntax are needed.
  8. Offline


    annotate originally hooked into commandsigns (or the other way around not sure) so you can place commands on ANY block
  9. Offline


    Thanks a lot for the update, there was some progress but still get "You dont have permission" when trying to use /* commands.

    I added commandsigns as a user to the admin group that has the '*' permission in permissionex but I'm guessing it doesnt translate properly.
    How exactly do I set up the group usage thing, its not very clear from the first post description.
  10. Offline


    I cannot get this plugin to promote guests to members with /*manuadd <NAME> Member, I was able to use that in the other commandsigns plugin, but it is outdated. It works for op's, but how would I get that command to make guests promote themselves to member? Whenever a guest hits the sign, it says "You are not allowed to use that command; (/manuadd <player> <group>)" Please help I need to get this to work!
  11. Offline


    Correct. However, as this is called CommandSigns, I kept the functionality strictly to signs.

    No, that does not work. You need to make a CommandSigns.permissions node in permissions.yml file. Then give that node children corresponding to the permission nodes you want a /* sign to work with. See the instructions , there is an example.

    The most likely cause is that you didn't completely read the instructions. You need to give permissions for the /menuadd command to the CommandSigns.permissions node in permissions.yml. There is an example.
  12. Offline


    I have:
            permissions.user.promote: true
    I assume the children node refers to the normal permissions of the plugins used?
    That is the permission node for pex to promote users as seen here:

    Your example of warp.go doesnt make sense to me because ive never heard of such a node or command other than the normal essentials.warp node.

    Also I NEVER use permissions.yml because PermissionsEx has a bukkitperms bridge - or is supposed to. I thought you said you made it so that we dont need to use bukkitperms anymore.
  13. Offline


    That node should be correct, I think (I've never used PEX). You have the syntax correct, anyway. It has to be in permissions.yml because that's the only place that you can create your own permission nodes.
  14. Offline


    only small problem is that it doesnt work, as admin im able to use the sign with '*' permission but the guest users with command.signs.use.* cannot use it, the /pex promote command tries to run as if it was initiated by that user instead if the "commandsigns" user thats in the admin group as well.
  15. Offline


    Thanks for continuing the plugin. But - the original CommandSigns had an important feature - it was possible to completely store the command on a sign, thus allowing to use it on a moving group of blocks. Could such option be implemented in this version (even as totally unsafe)?
  16. Offline


    I have a problem with the plugin D:

    My server needs some sort of command sign plugins. And after the previous one does no update I moved on to here. But permissions won't work with this plugin. I use permissions v3 and this is what I have.

            default: true
                prefix: '&f Noob'
                suffix: '&f'
                build: true
            - essentials.msg
            - essentials.list
            - buttonwarp.use
            - CommandSigns.use.*
    But I comes up with "Permission denied" or whatever it says.

    Please help!


    I need support for this D:

    It's inactive but I don't know how to change across and I don't want to have to re-program my whole system :(
  17. Offline


    This. The ability of Movecraft and (the old) CommandSigns to work together was a big part of my server and with the old CommandSigns now finally cactus, an alternative is desperately needed.

    I had the same problem as you and updating to PermissionsEx was so much easier than I thought it would be and in the long run is much easier to maintain. Even the developer of Permissions 3 doesn't want people using it or other developers supporting it anymore.
  18. Offline


    So does anyone know how to get the fake user working for the /* commands yet under permission systems like PEX?
  19. Offline


    I Am having a problem it says u do not have the permission when i have
    - CommandSigns.use.
    - CommandSigns.use.regular
    - CommandSigns.use.super
    in my permission file can u help me?:)
  20. Offline


    That is not how it works. There is no fake user. Only a fake permissions node. As for PEX, I will look into why it doesn't behave nicely.

    When I first made the plugin, it used commands written on the sign. Then I specifically changed the plugin so that the data is not stored on the sign. This was to eliminate the need for two plugins (Annotate and CommandSigns). It is unfortunate that I did not predict the circumstances where someone might still need the commands on the sign. Perhaps there is another solution to the problem.

    There is no way that this plugin will ever work with Permissions 3.x. Please search the forums for about 5 minutes and find out why Permissions 3.x will never be supported by a new plugin.

    :( I'm sorry that this plugin wont work with commands on the signs. It was specifically made to not use that feature anymore. I hope that you can find a good solution.

    Could you please provide some more detail about the issue?
  21. Offline



    Could you explain how it runs /* commands under different permissions, maybe I can help with a fix then. You said fake permission node? I'm not very clued up about the super perms structure (cos honestly i think its over complex and stupid compared to the original systems like pex)
    So somehow there is a node that allows users without the permission to execute a higher level command? How does it stop them from just doing it always with /command and limit it only to the commandsigns.
  22. Offline


    If you are unable to grasp the 'complexity' of how superperms work in the context of plugin development, then there is little hope that you could help with a fix. It is actually quite straight forward. A permissions plugin implements the handling of permissions nodes (as in reading them from a file, giving them to specific players... and whatever else), groups, ect. to whatever level of complexity that it desires. Those permission nodes are what is now inherent in the CraftBukkit API (what is called superperms). Whenever a plugin wants to check for permissions, it now only needs to run the player.hasPermission() method, whereas before it needed to first hook into the permissions plugin and utilize the API (different for every permissions plugin) in order to check for permission.

    My term 'fake permissions node' is actually a misnomer. It is a real permissions node, that has been defined by the administrator running the server inside of the permissions.yml file in the root server folder. That node has 'children' which are also inherited when that node is given to a player. This plugin raises a user's permissions by giving them that permission node (the CommandSigns.permissions node), runs the command on the sign, and then removes the permissions node.

    I hope that this explanation helps.

    I have looked over PEX and discovered the issue. PEX has very unwisely tried to still run permissions like the old days. They do not correctly utilize the CraftBukkit API for permissions. Therefore, PEX will not work.

    If you do not like PermissionsBukkit, then I suggest you give bPermissions a shot. Currently those are the only permissions plugins that correctly implement permissions. bPermissions also has a very nice feature to automatically import your permissions from PEX (so it says on the dev site).
  23. Offline


    I'll skip the part where I get frustrated with the nice way I'm being called stupid and move on...

    So CommandSigns changes the users permissions by adding the commandsigns.permissions node to that user temoporarily, so when bukkit does the haspermission() for "/pex promote" for example, it returns yes, the command runs and then the node is deleted from the user.
    This would assume that the server runs on something like bperms or w/e the new super perms managers are and makes full use of the permissions.yml in the server root.

    The problem with PEX is that the Permissions.yml in the server root is left empty and pex somehow intercepts the hasperm() function or whatever and returns the nodes from its own builtin yml files thats structured similar to how permissions 2.7 worked (with a lot of extras of course)

    To test I tried to add "Commandsigns.permissions" as a node to the groups in my PEX permissions file and left the superperms permissions.yml file with the nodes and stuff as before in the hopes that it would just magically draw from both yml's - of course that doesnt happen.

    As you know the previous version of commandsigns ran /* commands under a "fake" user called Commandsigns and it was possible to assign the needed permissions directly to that user, would it be hard to impliment that kind of feature again?
  24. Offline


    You are correct about PEX. I also tested different scenarios to check if it read in from the permissions.yml file, and it does not. I have no idea why they would leave such a powerful tool unused... but that means that the way that CommandSigns elevates permissions wont work. It would be possible to adapt the plugin to work with PEX, but that would be just like the old days where plugin developers would have to start supporting this and that different way of working with permissions. The whole point of the CraftBukkit permissions API is to eliminate this problem. I will be posting the source code in the near future, if you would like to patch it for your use.
    Fluff's very creative way of creating a fake user was very clever and worked well. However, with the new CraftBukkit permissions API, there was no need to create a fake user. Unfortunately, Fluff's method will break with every server (version) update, as it does some super fancy stuff, bypassing the CraftBukkit API.
  25. Offline


    *sigh* this might push me over the edge to finally start working on java, I really honestly dont like the language at all but ohwells.

    Thanks for the responses, I'll go do some research.
  26. Offline


    If anyone does do a fork of this that adds a "fix" allowing for /* perm elevation with PEX... please do toss up a link!

    Whether PEX did thing right or wrong by the CB api, there's still certainly a lot of us that would appreciate not having to switch permissions plugins in order to keep using commandsign functionality in 1.8
  27. Offline


    So this would eliminate the need of signs altogether -> Would it be possible to store commands on a button?
  28. Offline


    In theory yes. I really hope the dev will add that feature :)
  29. Offline


    So does this work with Essentials' Group Manager?
  30. Offline


    Yes, it could be easily converted... I considered doing that, but someone created a plugin called CommandBlocks. However, I see now that it is discontinued. So perhaps I will change the functionality and change the name. It really doesn't have much to do with signs anymore... specifically.

    No. At this time, the only permission managers that can fully utilize it are PermissionsBukkit and bPermissions.
  31. Offline


    Thank you very much!
    I saw that you mentioned you were making it compatible with PEX. Am I correct?

Share This Page