Bukkit

NOTE: CommandSigns will not work with ScrollingMenuSign v0.8 or newer. This document is only here for historical reasons. CommandSigns is no longer maintained and does not work well with newer permissions plugins, in particular superperms. Please use ScrollingMenuSigns's built-in command parser/executor.

If the CommandSigns plugin (minimum v0.9 recommended) is also installed, then all commands can be passed to CommandSigns for parsing and execution. This allows the possibility to run commands with elevated privileges and economy support, among other nice things. See CommandSigns own documentation for more information on getting this to work. A quick example:

/sms add mymenu Gold->Iron|$;41,2 $;42,-1
/sms add mymenu Iron->Gold|$;42,2 $;41,-1

This allows two gold blocks to be traded for one iron block, and vice versa!

Another example:

/sms add mymenu Daytime|/@time day|It's daytime!

The "/@" notation allows commands to be run with the permissions of the special "&CommandSigns" user. So you can give that user permission to run certain commands via ScrollingMenuSign/CommandSigns that they would not normally have. (See also the CommandSigns documentation for the "/*" notation which has a similar effect but works quite differently behind the scenes).

Note: the syntax for running double-slash commands (like those seen in WorldEdit/WorldGuard) in conjunction with /@ etc. is a little odd. You will need to do /@//command, e.g. /@//wand.

One ScrollingMenuSign configuration setting affects how commands are processed: always_use_commandsigns, which is true by default. If true, all commands will be passed to CommandSigns for processing. If false, commands will be handled by the (very basic) built-in ScrollingMenuSign command handler, unless they are prefixed by "cs:". As an example, if always_use_commandsigns were set to false, you would need to specify the above Gold->Iron command like this:

/sms add mymenu Gold->Iron|cs:$;41,2 $;42,-1

ScrollingMenuSign's built-in handler has no support for elevated permissions, economy, etc. It only allows commands to be run with the user's own permissions.

There is one other important difference to note between CommandSigns and ScrollingMenuSign's handling of chat commands: if you want to make the player say something, you must prefix the string with a backslash (\) when using CommandSigns to handle commands. If using ScrollingMenuSign, you must leave out the backslash.

CommandSigns permission nodes

CommandSigns has its own permission nodes, and it is important to ensure that they're correctly configured, even if you're not using CommandSigns directly:

To run any command from a menu using the CommandSigns API, you must have the commandSigns.use permission node.

To add a "special" command to a menu (i.e. one starting with @, /@, /*, or $), you will need one or more of the following permission nodes, just as if you were adding the command to a real CommandSign. The permissions are (copied from the CommandSigns documentation):

• commandSigns.super - Required to create, enable, or disable a command sign using @, /*, /@, or $. (Allows all four; basically the same as commandSigns.super.*)
• commandSigns.super.cost - Required to create, enable, or disable a command sign using $.
• commandSigns.super.elevated - Required to create, enable, or disable a command sign using /@command.
• commandSigns.super.fakeuser - Required to create, enable, or disable a command sign using /*command.
• commandSigns.super.restricted - Required to create, enable, or disable a command sign using @player/group.