Command Reference

From ServerSigns
Jump to: navigation, search

ServerSigns Commands

There are 2 commands available in ServerSigns: /serversigns (/svs) and /serversignsremote (/svsr).

The primary command is /svs - This command supports all sub-commands and must be executed in-game by an administrator.
The secondary command is /svsr - This command supports a limited set of sub-commands and can be executed by an administrator, console, or another ServerSign. All sub-commands must be preceded by a <location> variable in the format of world,x,y,z - for example, world,22,33,44 or my_world,-123,64,999.

Sub-Command Reference Table (v4.5.1)

Parameter Descriptions:
<text> required parameter, text describes the parameter
{text} required parameter, text represents exact values to be entered
[text] optional parameter, text describes the parameter
(text) informational, not part of the command & should not be input
[text]... accepts multiple values separated by spaces

Click a row to expand it for more information

Command Aliases Syntax Description
+ add a /svs add [type] [params] <action> Adds an action to a new or existing ServerSign
Type: A type is defined in this format: <type>
Only 1 type should be defined per command

Available types:

Type Aliases Description
<server> <srv>, <s> The server executes the action as a command
<message> <msg>, <m> Player is sent the action as a formatted message
<broadcast> <bcast> Action is broadcast as is (with colour codes translated) to the server as a message
<blank> <bl> Player is sent the action as an unformatted message
<chat> <say> Spoofs the player typing the action as a message in chat
<addgroup> <addg> The player is added to the server group action
<removegroup> <remg>, <remgroup> The player is removed from the server group action
<addpermission> <addperm>, <addp> The player is permanently given the permission action
<removepermission> <remperm>, <remp> The player has the permission action permanently revoked
<canceltasks> <ctasks>, <canceltask> Removes all queued ServerSigns tasks for the player that MATCH the regular expression pattern action
The regex pattern action can be empty, in which case all queued tasks for the player are removed.
Params: A parameter (param) is defined in this format: [<ParamId>:<Value>]
Multiple different parameters can be defined in 1 command, but only 1 of each parameter type can be provided.

Available params:

ParamId Values Description
d integer (append optional time values: s|m|h|d|w|mo) Set a delay in seconds (or specified time value) for the command's execution
p permission string(s), separated by | Set permission(s) to be temporarily granted to the player during command execution
ap "true" or "false" Set whether this task should be immediately persisted to the disk (set to true for important tasks that should never be lost)
click "left", "right", or "both" Set which type clicks will trigger this command's execution
Action: The string value that is used in the execution of this task.
If the action is a player command, and the first character is an asterisk (*), then the player will execute the command as if they are a server operator.

The following special parameters are replaced in the action string:

Param Replaced by
<player> username of the player that clicked the sign
<name> username of the player that clicked the sign
<nick> the player's Essentials nickname
<group> name of the player's group
<uuid> the player's uuid
<r:x-y > a random number between x and y
<signLoc> the sign's location in the format world,x,y,z
Requires the ServerSign to be looped
<loopCount> the current loop count
<loopsLeft> number of loops remaining
Requires the ServerSign to have a use limit of >0
<usesLimit> the uses limit of the ServerSign
<usesTally> the tally of current uses
<usesLeft> number of uses remaining
IF Statements: A conditional IF statement is defined in this format: <if> [!]conditional operator key:parameters
Only 1 operator key & parameter pair can be defined per statement; an operator key must always be given, parameters may be required (depending on the operator)
Even if no parameters are provided, the ':' separator must be present at the end of the operator key.
Prefixing an operator key with ! will make that conditional check negative, so it will execute its block if the condition is FALSE rather than TRUE.
This statement should be concluded with an <endif> statement, although it is not strictly required.

Available Conditional Operators:

Operator Key Parameters Condition
hasPerm permission node The player must have the specified permission node
isOp none The player must be a server operator
loopIs integer representing the loop number The current loop must be as specified
random percentage in the format <number>% The specified percentage chance
usesTallyIs integer representing the uses tally The uses tally must be as specified
isBefore 13 character long date/time (*see below) It must be before the specified date/time
isAfter 13 character long date/time (*see below) It must be after the specified date/time
checkOption <ID>=<value>[|<value>|...] (^see below) The player must have chosen one of the specified answers
onlinePlayers <operator><amount> (~see below) The number of players on the server must match the statement
nearbyPlayers <radius><operator><amount> (~see below) There must be <amount> players within <radius> blocks
* Please see the "timelimit" command reference further down for a detailed explanation of the date & time format
^ An 'option menu' must be present on the ServerSign, where 'ID' is the menu's identifier & 'value'(s) are answer labels
~ The <operator> parameter can be either '>' '<' or '=' and <amount> should be an integer
ENDIF Statements: A conditional ENDIF statement is defined in this format: <endif>
This statement should follow an <if> statement, and defines the scope of the aforementioned IF statement.
RETURN Statements: A conditional RETURN statement is defined in this format: <return>
This statement should be used within the scope of an <if> statement
Once this statement is reached, the ServerSign will stop executing commands until the next interaction.

Std. Examples: /svs add <server> say This command is executed by console
/svs add *say This command is executed by the player as if they're an op
/svs add [p:bukkit.command.say] say This command is executed by the player with bukkit.command.say granted
/svs add say This command is executed by the player as if they typed it themselves

/svs add <msg> This message is sent to the player with the plugin prefix
/svs add <m> This message is sent to the player, with a random number here: <r:1-100>
/svs add <bcast> This message is broadcast to the whole server, and was executed by <player>
/svs add <blank> This message is sent to the player without any prefixes pre-applied formatting

/svs add [d:10] *say This command is executed by the player as if they're an op, 10 seconds after activation
/svs add [d:5m] [p:bukkit.command.say] say This command is executed by the player with perms granted, 5 minutes after activation
/svs add [click:left] say This command is only executed when the ServerSign is left clicked
/svs add [ap:true] say This command is immediately persisted to disk (entirely unnecessary for this command!)

/svs add <addGroup> group_name
/svs add <remPermission> permission.node
/svs add <remGroup> <group>
/svs add <server> pex user <uuid> group set group_name

/svs add [p:bukkit.command.say|bukkit.command.stop] say This command grants the player 2 permissions during execution
/svs add [d:15s] [click:left] [ap:true] *say This command has a 15s delay, is left-click activated, and is always persisted
/svs add [d:5m] [ap:true] <addGroup> group_name
/svs add [click:both] <addPermission> permission.node

Cond. Examples: /svs add <if> hasPerm:permission.node.example
/svs add <msg> This message is only sent if the player has the permission permission.node.example
/svs add <endif>
/svs add <msg> This message is always sent to the player regardless of the above condition

/svs add <if> random:15%
/svs add <msg> This message is only sent 15% of the time
/svs add <return>
/svs add <endif>
/svs add <msg> This message is sent the remaining 85% of the time

/svs add <if> usesTallyIs:99
/svs add <msg> This message is sent to the 100th user of this ServerSign
/svs add <endif>
/svs add <if> usesTallyIs:499
/svs add <msg> This message is sent to the 500th user of this ServerSign
/svs add <endif>
/svs add <msg> This message is always sent to the player regardless of the above conditions

/svs add <if> checkOption:question1=answer1
/svs add <msg> This message is sent to the player if their answer for 'question1' is 'answer1'
/svs add <endif>
/svs add <if> checkOption:question2=answer1|answer2
/svs add <msg> This message is sent to the player if their answer for 'question2' is 'answer1' or 'answer2'
/svs add <endif>
+ cancel setcancel, stopevent /svs cancel <mode> Set if/when a ServerSign should cancel the player interact event
Purpose: The cancel event mode determines if/when the PlayerInteractEvent should be cancelled during ServerSigns execution.
This is particularly useful for setting a ServerSign up on a redstone-producing block (like a button) - using the cancel event mode the admin can choose when the redstone signal should be emitted (i.e. only when the execution is successful).
Mode: The mode should be input as a literal string as shown below.

Available Modes:

Mode Description
always The event will always be cancelled, no matter the outcome of the execution
never The event will never be cancelled, no matter the outcome of the execution
success_only The event will only be cancelled if the execution is successful
fail_only The event will only be cancelled if the execution fails
Examples: /svs setcancel always
/svs cancel never
/svs stopevent success_only
/svs cancel fail_only
+ cancelpermission canpermission, canperm, cancelperm, cperm, cpermission /svs cancelpermission <permission> [message] Users with this permission will not be able to execute the ServerSign
Permission: The permission node that will be used when checking the player for a match.
Message: The message that should be shown to the player if they have the specified permission.
Examples: /svs cancelpermission permission.node
/svs cancelperm permission.node &eYour permissions are &ctoo high &efor this ServerSign!
/svs cperm permission.node You don't need to use this ServerSign!
+ confirmation conf, confirm, cf /svs confirmation <boolean> [message] Set whether this sign should ask for confirmation before allowing use
Boolean: If set to true, confirmation will be required; if set to false, it will not be required.
Message: The message that should be shown to the player when they are asked to confirm.
Examples: /svs conf true
/svs confirm true Are you &csure &eyou want to do this?
/svs confirmation false
+ copy cp /svs copy [persist] Copy and paste a ServerSign
Persist: If set to true, the admin will be able to paste the copied ServerSign infinitely until set to false.
Examples: /svs copy
/svs cp true
/svs copy false
+ create cr, new /svs create Create a new ServerSign
Examples: Create a ServerSign with no commands and attach it to a button - this button can connect to a redstone circuit; assign a price item cost to the ServerSign and set the cancel mode to fail_only - now the button will only send a redsotne current if the player has the required price items!
Create a ServerSign template with preset options and no commands which can be easily copy pasted and have commands added.
+ edit ed /svs edit <line number> <new command> Edit a command at the specified line on an existing ServerSign
Line Number: An integer greater than 0 and less than the number of commands on the sign.
New Command: A command formatted & processed in the same manner as with /svs add
Examples: /svs edit 1 <server> say This command has replaced the command on line 1
/svs ed 3 <msg> This message has replaced the command on line 3
/svs edit 5 *say This command has replaced the command on line 5
+ grant permissionsgrant, pgrant, grantpermission, grantpermissions, permissiongrant /svs grant <action> Add or remove a granted permission to/from an existing ServerSign
Action: If set to "delete" then all grant permissions will be removed from the ServerSign.
Otherwise, if set to "add " followed by a permission node then the ServerSign will temporarily grant all permission nodes defined to the player during command execution.
Examples: /svs grant delete
/svs pgrant add permission.node
/svs grantpermission add another.permission.node
+ hic helditemcriteria, holditemcriteria, holdcriteria /svs hic <enchants> <lores> <name> <durability> Set whether the listed item attributes should be ignored in held item checks on an existing ServerSign
Enchants: If set to true, all holding item checks will ignore item enchantments. If set to false, compared items must have the same enchantments.
Lores: If set to true, all holding item checks will ignore item lores. If set to false, compared items must have the same lores.
Name: If set to true, all holding item checks will ignore the item name. If set to false, compared items must have the same name.
Durability: If set to true, all holding item checks will ignore the item durability. If set to false, compared items must have the same durability.
Examples: /svs hic true true true true
/svs holdcriteria true true false false
/svs holditemcriteria false false false true
+ holding hold, held /svs holding <item> Add an item to the list of possible items the player must be holding to use this ServerSign
Item: If set to "hand" then the item currently held by the admin will be used.
If set to "0" then the held item requirement for the ServerSign will be removed.
Otherwise the item data should be specified individually. An item type MUST be given, all other parameters are optional.
The following parameters are available: id.<type> am.<amount> du.<durability> na.<display_name> lo.<lore>... en.<enchantment>.<level>...
Examples: /svs holding hand
/svs held 0
/svs hold id.STONE am.5
/svs holding id.DIAMOND_SWORD en.SHARPNESS.3 na.&4God_Sword
/svs held id.DIAMOND_AXE lo.&6First_lore_required lo.&4Second_lore_required
+ import imp import <file path> Import a text file of commands, 1 command per line without /svs
Usage: This command is used to import a list of /svs commands which can be applied to an existing ServerSign with a single click.
The administrator can use the import command then click an existing ServerSign and all the commands will be applied in the order provided.
File Path: The path to the desired .txt file, rooted from the server's main directory.
To load the file 'commands.txt' from the ServerSigns plugin folder, the path 'plugins/ServerSigns/commands.txt' could be used
Examples: /svs import plugins/ServerSigns/commands.txt
/svs imp text_files/example.txt
/svs import plugins/Essentials/why_is_this_here.txt
+ insert ins insert <line number> <new command> Insert a new command at the given index on an existing ServerSign;
The command at the index (and all trailing commands) have their index increased by 1
Line Number: An integer greater than 0 and less than the number of commands on the sign.
New Command: A command formatted & processed in the same manner as with /svs add
Examples: /svs insert 1 <server> say This command has been inserted to be the first action
/svs ins 2 <m> This message has been inserted to be the second action
/svs insert 4 *say This command has been inserted to be the fourth action
+ list ls, info /svs list [persist] List all information available for an existing ServerSign
Persist: If set to true, the admin will be able to continuously click ServerSigns and view their information until set to false.
Examples: /svs list
/svs ls true
/svs info false
+ longcommand long, longcmd /svs long Toggle 'long' mode, which allows commands to be applied to ServerSigns by writing over multiple lines
Usage: Using this command toggles 'long' mode; while enabled, the admin is able to type into chat over multiple messages and these messages are appended one after the other (with 1 space between each message) into one long command - when the admin has finished writing the command they can use /svs long again to toggle 'long' mode off and apply the command to a ServerSign.
Examples: /svs long *toggles on
<message> The maximum length for a single message in Minecraft is currently 100 characters, which is
less than you get to put in a tweet on Twitter! Luckily you can add commands to ServerSigns that are
longer than this by using the /svs long feature!
/svs long*toggles off, apply to a ServerSign
+ option opt /svs option <ID> {question|add|remove} Bind player-input option questions & answers to ServerSigns
Usage: This command allows administrators to create an 'option menu' from which a player can choose 1 of any number of options which can affect the sign's execution.
A defined 'option menu' can be displayed to the user with the command '/svs add <displayOptions> <ID>' where ID is the desired 'option menu' ID.
When a ServerSign is executed by a player, it will scan for any accessible 'option menu' displayOptions commands (see above) and display them to the player to select an answer BEFORE execution of the commands.
Please be sure to refer to the "add" command section of this Wiki page for details on how to check the player's chosen options using conditional IF statements.
ID: The identifying name for the desired 'option menu' - when used with the 'question' parameter, this will create a new 'option menu' with the defined ID.
Question|Add|Remove: These parameters can be abbreviated to q|a|r respectively.
The 'question' parameter should be followed by a question to ask the player, and will created a new 'option menu' with the given ID, ready for answers to be added.
The 'add' parameter should be followed by 1) an answer label (no spaces), and 2) the answer description (can contain spaces) - the player will be shown all of the answers defined using this command when, and will need to choose 1 using it's label.
The 'remove' parameter should be followed by an existing answer label, and will remove the corresponding answer & description from the 'option menu'.
Examples: /svs option example1 question Is this question an example?
/svs option example1 add Yes You think this answer is an example
/svs option example1 add No You think this answer is not an example
/svs add <displayOption> example1

/svs opt example2 q Who is your favourite ServerSigns developer?
/svs option example2 add Caliber You think Caliber is your favourite
/svs opt example2 a Exloki You think Exloki is your favourite
/svs option example2 add Neither You don't like either of them!
/svs add <displayOption> example2
+ priceitem pi, item, priceitem /svs priceitem <item> Set item requirements for an existing ServerSign - can be repeated for multiple items
Item: If set to "hand" then the item currently held by the admin will be used.
If set to "0" then all the price item requirement(s) for the ServerSign will be removed.
Otherwise the item data should be specified individually. An item type MUST be given, all other parameters are optional.
The following parameters are available: id.<type> am.<amount> du.<durability> na.<display_name> lo.<lore>... en.<enchantment>.<level>...
Examples: /svs priceitem hand
/svs item 0
/svs pi id.STONE_PICKAXE du.75
/svs pi id.GOLD_HOE na.&dEllie
+ pic priceitemcriteria, priceitemcrit, picrit, picriteria /svs pic <enchants> <lores> <name> <durability> Set whether the listed item attributes should be ignored in price item checks on an exisiting ServerSign
Enchants: If set to true, all price item checks will ignore item enchantments. If set to false, compared items must have the same enchantments.
Lores: If set to true, all price item checks will ignore item lores. If set to false, compared items must have the same lores.
Name: If set to true, all price item checks will ignore the item name. If set to false, compared items must have the same name.
Durability: If set to true, all price item checks will ignore the item durability. If set to false, compared items must have the same durability.
Examples: /svs pic true true true true
/svs picrit true true false false
/svs picriteria false false false true
+ reload rl /svs reload Reload config.yml, translation files, and all ServerSigns from disk
Purpose: A convenience command that performs the actions of /svs reloadSigns and /svs reloadConfig.
Examples: /svs reload
/svs rl
+ reloadconfig reloadconf, reloadc, rlc, rlconf /svs reloadconfig Reload the config.yml & translations files from disk
Purpose: Allows admins to reload configurations which will update the plugin with any values altered on the disk.
Examples: /svs reloadconfig
/svs reloadconf
+ reloadsigns reloadsign, reloads, rls, rlsigns /svs reloadsigns Reload all ServerSigns from disk
Purpose: Allows admins to load all ServerSigns from disk, meaning any ServerSigns with deleted files will be dropped, and unloaded files will be loaded.
Examples: /svs reloadsigns
/svs rlsigns
+ remove rem, delete, del /svs remove [line number] Remove a ServerSign, or just a specific command
Line Number: An integer greater than 0 and less than the number of commands on the sign.
Examples: /svs remove
/svs rem 1
/svs del 5
+ resetallcd cdra, cooldownresetall, cdresetall, rcda, resetcdall, resetallcooldown /svs resetallcd Reset all ServerSign cooldowns across all ServerSigns
Purpose: Allows admins to reset all cooldowns (global & per-player) on all ServerSigns server-wide.
Examples: /svs resetallcd
/svs rcda
/svs resetcdall
+ resetcd cdr, cooldownreset, cdreset, resetcooldown, rcd /svs resetcd Reset the cooldown data for a specific ServerSign
Purpose: Allows admins to reset all cooldowns (global & per-player) for a specific ServerSign.
Examples: /svs resetcd
/svs cdreset
/svs rcd
+ resetcooldowns resetcds, rcds /svs resetcooldowns <player> Reset all ServerSigns cooldowns for a specific player
Player: The name of the player whose cooldowns you want to reset.
Examples: /svs resetcooldowns Exloki
/svs resetcds CalibeR50
+ select sel /svs select Select a ServerSign for future commands to be automatically applied to
Examples: /svs select
*Click a ServerSign*
/svs add <server> say This command is automatically applied!
+ setcooldown scd /svs setcooldown <cooldown> Set the per-player cooldown time for an existing ServerSign
Cooldown: An integer value representing the cooldown time in seconds (append optional time values: s|m|h|d|w|mo to change the time unit)
Examples: /svs setcooldown 60
/svs scd 3600
/svs setcooldown 28d
/svs scd 12h
+ setglobalcooldown sgcd /svs setglobalcooldown <cooldown> Set the global cooldown time that affects all players for an existing ServerSign
Cooldown: An integer value representing the cooldown time in seconds (append optional time values: s|m|h|d|w|mo to change the time unit)
Examples: /svs setglobalcooldown 45
/svs sgcd 3w
/svs setglobalcooldown 5s
/svs sgcd 10
+ setloops setloop, setl /svs setloops <loop count> [loop delay] Convert an existing ServerSign to a looped ServerSign (60s delay by default)
Commands Executed: A looped ServerSign will execute all commands on the ServerSign once during each iteration - if the command requires a player that is not online, the command will be dropped.
Loop Activation: A looped ServerSign will begin iterating through executions after it has been triggered once. It will then block any more executions until the current loop is completed.
Loop Count: If set to '-1' then the ServerSign will have any existing loop data removed.
If set to '0' then the ServerSign's loop will continue infinitely until destroyed or the server restarts.
If set to any other values >0 then the ServerSign's loop will iterate this many times.
Loop Delay: Defines the time in seconds between each loop of the ServerSign (defaults to 60 seconds if undefined).
Examples: /svs setloops 5
/svs setl 10 120
/svs setloop -1
/svs setl 0 3600
+ setpermissions sp, setperms, setpermission /svs setpermissions <permissions...> [m:<message>] For each permission, the user must have 'serversigns.use.<permission>' to use this sign
Permissions: A set of permissions (1 or more) separated by a single space which the user must have to use the ServerSign. (The user must have the permission node: serversigns.use.<permission>).
Setting the first parameter to - (a single subtraction symbol) allows you to remove any assigned permissions from the ServerSign.
Message: This message is shown to the player if they don't have the required permissions to use the ServerSign.
The message parameter should be given after all permissions have been defined, although it can be defined without any permissions to change the default message. The start of the message should be prefixed with 'm:' to indiciate that the message is now starting. The message can then be typed as normal with spaces, etc.
Examples: /svs setperms example - requires the player to have serversigns.use.example
/svs sp user mod admin - requires the player to have serversigns.use.user, serversigns.use.mod, and serversigns.use.admin
/svs setpermissions example1 example2 m:This message is shown to the &3player
+ setprice spr, priceset, price /svs setprice <cost> Add a monetary cost to an existing ServerSign
Cost: A floating point (or integer) value representing the monetary cost that should be charged to the player.
If set to '0', the cost will be removed.
Examples: /svs setprice 150
/svs spr 12.50
/svs priceset 999999.99
+ setuses setuse, uses /svs setuses <number of uses> Limit this ServerSign to the defined number of uses
Number of Uses: The ServerSign will remove itself (as a ServerSign, the actual block remains unchanged) after this defined number of uses has been reached.
If set to '0', the use limit of the ServerSign will be removed.
Examples: /svs setuses 10
/svs uses 150
/svs setuse 0
+ silent sil, quiet, mute /svs silent <boolean> Set whether a ServerSign should display internal messages to the user
Boolean: If set to true, the ServerSign will not send the player internal (non-command-defined) messages.
If set to false, the ServerSign will send messages as normal.
Examples: /svs silent false
/svs quiet true
/svs mute false
+ timelimit timel, tl /svs timelimit <minimum|@|-> [maximum] Set the minimum & maximum date/time between which a ServerSign can be used
Minimum|@|-: If set to @, the minimum timelimit will remain unchanged and only the maximum value will be changed.
If set to -, both the minimum timelimit and the maximum timelimit will be removed from the ServerSign.
Otherwise this parameter should be a date & time value in this format: DDMMYY,HHMMSS (details below)
Maximum: This parameter should be a date & time value in this format: DDMMYY,HHMMSS (details below)
Date & Time Format: The date & time parameter should be a single 13 character string/word (no spaces) containing 6 numbers, a comma, then another 6 numbers.
The first 6 numbers represent the date in the format DDMMYY where D = Day, M = Month, Y = Year.
The last 6 numbers represent the time in the format HHMMSS where H = Hour, M = Minute, S = Second.
All times should be provided in the 24-hour clock format.
7:32pm on 31st December 2015 would be represented as 311215,193200 (visualise it with separators like: 31/12/15,19:32:00 - but don't actually include them)
Examples: /svs timelimit 251115,120000 Sets the minimum limit to 12pm on 25th November 2015
/svs timelimit 010116,000000 Sets the minimum limit to Midnight on 1st January 2016
/svs timelimit @ 251216,235959 Sets the maximum limit to 23:59:59 on 25th December 2016
/svs timelimit 010416,000000 060416,235959 Sets the minimum limit to midnight on 1st April 2016, and maximum limit to 23:59:59 on 6th April 2016
+ void none /svs void Invalidates any pending actions you may have
Purpose: ServerSigns will maintain tracking of any pending actions an admin may have (such as a pending command to add, or a sign to paste, etc.) until the plugin is restarted, or this command is used.
Examples: Accidentally up-arrowed an /svs add command
/svs void
Can continue as normal
+ xp xpprice, exp /svs xp <levels> Set an experience levels cost on an existing ServerSign
Levels: An integer value representing the experience level requirement that will be removed from the player upon use.
If set to '0', the experience level requirement will be removed.
Examples: /svs exp 150
/svs xp 30
/svs xpprice 0

Sub-Command Reference Table (Refer to above table)

These commands may not function as described - this is for the development branch!

See Also