# Staff++ ## Introduction This plugin was originally developed By ShortNinja. After ShortNinja's passing Qball took over the support and further development. I created this version as an attempt to add new features to StaffPlus and revitalize it. The first difference from StaffPlus is that I dropped support for all MC versions before **1.12**, this will hopefully allow me to add new features to the newer version easily and help in bug fixing more targeted. If you are using older version of Minecraft please refer to QBall's [repository](https://github.com/Qballl/StaffPlus) I changed some of the core features: * Support for MySQL/SQLITE Database integration * BungeeCord integration for Staff Chat * New and improved reporting system * New and improved warning and punishment system * Discord integration for reports/warnings/mutes/kicks... * Investigation functionality * Muting/kicking/banning * Added a [Web platform](/web-platform/setup) Overall I am trying to fix a lot of the existing bugs and am cleaning up the code. Hopefully this plugin can be a good successor to ShortNinja's original plugin. # Quick start ## Installation Download the latest version from the Spigot page. You should download the version corresponding to your MC version. Place the jar file inside the plugins folder of your server and start your server. This will create the necessary files in the `plugins/StaffPlusPlus` folder. ## Basic configuration Open the `config.yml` file located in the `plugins/StaffPlusPlus` folder. If you mess up the config file you can always take a look at the [default file](https://github.com/garagepoort/StaffPlusPlus/blob/master/StaffPlusCore/src/main/resources/config.yml). #### main-world Search for the property: `main-world` inside the configuration file. This should be the name of the main world. Meaning the world folder name which contains the player data files. By default in Minecraft this is just the "world" folder. So if you have a regular setup just leave the default setting. If for some reason your world location folder has a different name, you can change it here. #### server-name Search for the property: `server-name` inside the configuration file.\ The server name should be unique for this server. If you have a multi-server setup every server running Staff++ must configure this with a different name. **If you are running a minecraft server network make sure to give this property the same name as the server name used by the network.** {% hint style="warning" %} I recommend keeping the server-name property alphanumeric. Underscore, dashes and spaces can be used. {% endhint %} #### modules The config file contains the command and permission configuration. It also contains the different modules configuration. Different functionalities of Staff++ are configured as separate modules which can be enabled or disabled. ## Database configuration We support 2 types of database `sqlite` and `mysql`. By default `sqlite` is configured. If you want to use a mysql database, change this part of the configuration file: ```yaml storage: type: 'mysql' migrations-table-name: 'migrations' mysql: host: 'localhost' user: 'root' database: 'root' password: 'mypass' port: 3306 ``` ## Adding players as Staff Members There is not one command to add players as Staff members. Everything in Staff++ is permission based, if you have the correct permissions you can access the Staff++ commands. If you are OP you can access all commands by default. All permissions are listed [here](https://github.com/garagepoort/StaffPlusPlus/wiki/Permissions). This means you need some permission plugin to enable staff mode for your staff members. A commonly used permissions plugins is [Luckperms](https://www.spigotmc.org/resources/luckperms.28140/). Once you have installed the permission plugin you can assign your player the correct permissions. All permissions in Staff++ start with a `staff.` prefix. Luckperms supports wildcards so you could give your player the permission `staff.*` and it will enable all Staff++ permissions for that player. # Reload Configuration Staff++ re-enabled to "reload" command. The reload command allows reloading the configuration file. However the reload command is still in an experimental phase. So keep below warnings in mind when executing it. ## Warnings When executing the reload, player sessions won't be reverted. This means that for example if we disable the freeze command and reload the configuration the freeze command will no longer work. **But players that were frozen before reloading, will remain frozen.** When we are changing configuration impacting "Staff Mode", it's preferable that staff members exit staff mode before reloading. Staff members that are in staff mode won't see all the config changes made until they exit and re-enter. Changing the database connection parameters and reloading does not reset the database connection. To do so a restart is still required. ## Known issues * Autocompletion of the commands does not change when reloading. The commands do no longer work but it's possible players will still see the commands being autocompleted. # Multi Server Setup {% hint style="warning" %} You need a shared **MySQL** database to use this feature. {% endhint %} Staff++ added the ability to synchronize multiple features over a multiple servers.\ This guide will explain you how to easily set this up. ### Step 1: installation Install Staff++ on every server that you want to be synced. **No** plugin is needed for the bungee server. ### Step 2: Database Configure the database connection inside the configuration file. ```yaml storage: type: 'mysql' migrations-table-name: 'migrations' mysql: host: 'localhost' user: 'root' database: 'root' password: 'mypass' port: 3306 ``` You **must** configure **mysql** to synchronize the servers.\ Every Staff++ instance must be configured to use the same database ### Step 3: Server name #### server-name Search for the property: `server-name` inside the configuration file.\ The server name should be unique for every server. Every server running Staff++ must configure this with a different name. **If you are running a minecraft server network make sure to give this property the same name as the server name used by the network.** {% hint style="info" %} I recommend keeping the server-name property alphanumeric. Underscore, dashes and spaces can be used. {% endhint %} ### Step 4: Server synchronization config #### server-sync-module Look for the following section in the configuration file. ```yaml server-sync-module: vanish-sync: false staffmode-sync: false ban-sync: '' report-sync: '' warning-sync: '' mute-sync: '' kick-sync: '' notes-sync: '' ``` #### All these properties can be disabled and enabled at any time without impacting previous data. #### vanish-sync Allows a player to remain vanished when switching between servers. No join and leave message will be displayed. #### staffmode-sync Allows a staff member to keep his staff mode when switching between servers. {% hint style="warning" %} To use this you must set the properties `enable-on-login` and `disable-on-logout` underneath the **staff-mode** section, to **false** {% endhint %} ### Data sync Below properties are all configured in the same way. Inside this property we can configure all other servers we want to be able to read data from. Let's say we have 4 servers all linked to the same Staff++ mysql db. The servers are named `MC1` `MC2` `MC3` and `MC4` . MC1, MC2 and MC4 should share reports, while MC3 has it's own reports. Bans should be shared across all servers. MC2 and MC4 share the same mutes. MC1 and MC3 also share the same mutes. You can leave the property empty if you only want to read data from your own server. The `[ALL]` value can be used to tell staff++ to read data from all servers. #### MC1 config: ```yaml server-sync-module: ban-sync: '[ALL]' report-sync: 'MC1;MC2;MC4' mute-sync: 'MC1;MC3' ``` #### MC2 config ```yaml server-sync-module: ban-sync: '[ALL]' report-sync: 'MC1;MC2;MC4' mute-sync: 'MC2;MC4' ``` #### MC3 config ```yaml server-sync-module: ban-sync: '[ALL]' report-sync: '' mute-sync: 'MC1;MC3' ``` #### MC4 config ```yaml server-sync-module: ban-sync: '[ALL]' report-sync: 'MC1;MC2;MC4' mute-sync: 'MC2;MC4' ``` #### ban-sync When configured players will get banned on every server listed. If nothing filled in, the player is only banned on the server where the ban was initiated.\ This also impacts the Staff GUI. When enabled the staff GUI shows all banned players from all configured servers. If disabled you only see the banned players on the current server. #### report-sync When enabled, the GUI reports shows all reports a player has made on whatever server the report was created. The infractions GUI will also include players who got reported on other servers #### warning-sync When enabled warning thresholds will be calculated based on player warnings from across all configured servers.\ If disabled only warnings from the current server are taken into account.\ \ The list of warnings retrieved shows either all warnings from a player or only the warnings issued from the current server. #### mute-sync When enabled players will get muted on every configured server having staff++ installed. If disabled the player is only muted on the server where the mute was initiated.\ This also impacts the Staff GUI. When enabled the staff GUI shows all muted players from all configured servers. If disabled you only see the muted players on the current server. #### kick-sync This impacts the infractions Staff GUI. When enabled the staff GUI shows all kicks a player has received from all configured servers. If disabled you only see the kicks the player has received from the current server. #### notes-sync When enabled, the notes displayed linked to a player are shared across all configured servers. If disabled you will only see notes that were created on the current server. # General Configuration ```yaml # The name of the server. This can be anything you want but it must be unique and once chosen it shouldn't change anymore. server-name: "MyUniqueServerName" # The name of the main world. Meaning the world folder name which contains the player data files. main-world: "world" # The format in which all dates will be displayed inside the GUIs. # All Java date time formats can be used timestamp-format: 'dd/MM/yyyy-HH:mm:ss' # The language file that will be referred to for messages. # Current available languages are: lang_en, lang_sv, lang_de, lang_nl, lang_es, lang_hr, lang_no, and lang_fr. # If you would like to translate Staff++, please message me on Spigot! lang: "lang_en" # Chooses the authentication provider. Default "noop", no authentication will be done. # AuthMe is supported. When the provider is authMe, Staff++ will enforce that the user is authenticated through AuthMe before being able to execute the commands. authentication: provider: noop # Commands that staff will not be allowed to use at all. # Must have "permissions.block" permission to take effect. # Leave blank to disable. blocked-commands: "/example1, /example2, /example3" # Commands that staff will not be allowed to use while in staff mode. # Must have "permissions.block" permission to take effect. # Leave blank to disable. blocked-mode-commands: "/example1, /example2, /example3" # The default color of glass for the side of GUIs. Just a cosmetic thing that staff members can change. glass-color: 0 # The title of the glass color chooser GUI. glass-title: "&bChoose GUI glass color" # Enable offline player mode # report-bypass & warn-bypass does not work for offline players offline-players-mode: true ``` #### server-name Search for the property: `server-name` inside the configuration file.\ The server name should be unique for this server. If you have a multi-server setup every server running Staff++ must configure this with a different name. {% hint style="warning" %} I recommend keeping the server-name property alphanumeric. Underscore, dashes and spaces can be used. {% endhint %} #### main-world Search for the property: `main-world` inside the configuration file. This should be the name of the main world. Meaning the world folder name which contains the player data files. By default in Minecraft this is just the "world" folder. So if you have a regular setup just leave the default setting. If for some reason your world location folder has a different name, you can change it here. #### timestamp-format Configure the way you want dates and times to be displayed inside the in-game GUI screen.\ You can use the java datetime format options.\ Examples: | **format** | Example | | --------------------- | ---------------------- | | dd/MM/yyyy HH:mm:ss | 31/12/2020 15:23:10 | | dd/MM/yyyy hh:mm:ss a | 31/12/2020 03:23:10 PM | | MM-dd-yyyy hh:mm a | 12-31-2020 03:23 PM | ### Another plugin is overriding a staff++ command It is possible that another plugin like 'essentialsx' might get priority over certain commands like the `ban`, `tempban` and `unban` command. To prevent this we suggest the same solution as is proposed by [EssentialsX](https://github.com/EssentialsX/Essentials/wiki/Common-Issues#essentialsx-overrides-a-command-from-spigot-or-another-plugin). Configure your server aliases in such a way that the commands from Staff++ will always be used. This can be done by editing the `commands.yml` file and specifying your aliases there. To enable Staff++ commands this would be done, for example, in this way: ```yaml aliases: ban: - "staffplusplus:ban $1-" tempban: - "staffplusplus:tempban $1-" unban: - "staffplusplus:unban $1-" ``` More info on the [bukkit wiki](https://bukkit.gamepedia.com/Commands.yml#aliases) # Other # Text parsing ### Introduction In staff++ there are messages file which contain most of the text used within staff++. ### New lines New lines can be achieved using 2 ways #### \n notation ``` ban-permabanned-kick: "[Banned] You have been permanently banned\nfrom this server" ``` #### YAML multiline notation ``` ban-permabanned-kick: | [Banned] You have been permanently banned from this server ``` ### Tooltips Tooltips are supported in the newest version of staff++.\ These can be configured by using the notation: #### \[tooltip|\|\] #### Example \[tooltip|&6%player%''s|&6%player%\n&7This guy] armor has been removed! ![](/files/5xe8Va14ZMXmTutz6fOj) ### Basic colors Basic colors are supported using **"&"** ![](/files/RBh7Ka9wrrxZAsV7eRLK) ### Hex Colors In versions >= 1.16 hex colors are supported using hex notation ```markup #FF0044This is in some color. #EE8833This is another color. ``` ### Gradients In versions >= 1.16 gradient colors are supported using: ```markup <#00d8e6>This is gradient ``` # Styling the GUIs In Staff++ it's possible to add configuration files to change the look of the in-game GUIs. {% hint style="info" %} Styling can only be used to change the appearance of the GUI. Color, Material, location of items, ... It cannot change the content of the GUI. It cannot change the title of the inventory to something else. It cannot change the action that is taking when clicking on an item. It cannot add random items to the GUI. {% endhint %} ### Getting started To begin styling in Staff++, follow these steps: 1. Grant yourself the `staff.show-style-info` permission. This permission enables you to use the `/show-style-info` command. 2. In your game, execute `/show-style-info`. In this example, we'll work with the report details screen. 3. You'll notice that the reports GUI now displays additional information in the inventory title and items. 4. To ensure that all lore (text descriptions) is displayed correctly, adjust the GUI scale in your video settings. 5. Keep in mind that some classes may not appear in the GUI, but you can find them in the important classes section of the Staff++ wiki. ![](/files/ch2PpLKfOidieoneboz6) Id's are shown in RED and classes are shown in GREEN. Note that all labels and values in this item lore have all the same classes. While the ids are always different. ### Styles folder Create a `styles` folder inside the Staff++ plugin folder. This folder will contain all style configuration files for Staff++. You can create as many files as needed and name them as you prefer. A good practice is to create at least one style config file for each GUI you want to modify. For our example, we'll use two style files. Create a `report-detail.yml` file for styling rules specific to the report details GUI. ![](/files/z0ND0gKaU9iyhBL4EACl) ## Example In the example below, we'll customize the view of the report details. Each part of the styling is explained separately, and the complete `report-details.yml` is provided at the end with all styling rules. ### Changing the title color To change the title color, reference the class associated with all titles in the `report-detail.yml` and reload the plugin using `/staffplus reload`: ```yaml # Id of the GUI report-detail: # This is a class that is always placed on the title of GUIs $gui-title: # Change the color of title component color: "&1" ``` ![](/files/hxRYt2vQuFMAUbGDJ08k) ### Changing an item. If you have enabled show-style-info you'll see that the item's id is `report-info`. But the item also has a **class report-info**. In our case we are going to use the class. We can use this class in our **report-detail.yml** to change the item. In this example I will change the material to be a book. I'll change the color of the item name to `&f`. I'll change the color of all labels to `&7` and change the colors of all values to `&6.` I'll remove the ID and location lines and I'll remove the status label but not the actual status. Reload the plugin using `/staffplus reload` ```yaml report-detail: # Class of the info item $report-info: material: BOOK # All item names in the GUIs have a class called item-name # We can use this to change the color of the item. $item-name: color: "&f" # Change all text part color inside the lore of this item # We use the class name so that we can match all text parts with one rule. $detail-label: color: "&7" $detail-value: color: "&6" # Hide the entire id line id-label: hidden: true id-value: hidden: true # Hide the entire culprit line culprit-label: hidden: true culprit-value: hidden: true # Hide the entire location line location-label: hidden: true location-world-value: hidden: true location-separator: hidden: true location-block-value: hidden: true # Hide only the status label status-label: hidden: true ``` #### BEFORE ![before](/files/HQvKxijt7W2PTG98r1xx) #### AFTER ![](/files/fKsP8Md6QVdH1ba8pG2X) ### Hiding Items We can also hide items from the GUI. {% hint style="warning" %} Just because an item is hidden doesn't mean the player can't access the functionality in some other way. If you want to disallow the player from using a functionality you need to setup the correct permissions. {% endhint %} Let's remove some of those large unassign/reject and resolve action items. Add the following to your **report-detail.yml** and reload the plugin using `/staffplus reload` ```yaml # Class of the GUI $report-detail: # Id of the item unassign-1: hidden: true unassign-2: hidden: true unassign-3: hidden: true reject-1: hidden: true reject-2: hidden: true reject-3: hidden: true reject-4: hidden: true reject-5: hidden: true resolve-1: hidden: true resolve-2: hidden: true resolve-3: hidden: true ``` ![](/files/hGLkrLYglGtbpKWgH05N) ### Moving items The above seems a bit weird. But we can move the items to make the GUI more compact. Also let's move the back button to another location. Add the following to your **report-detail.yml** and reload the plugin using `/staffplus reload` ```yaml report-detail: back-button: slot: 17 unassign-0: slot: 1 reject-0: slot: 2 resolve-0: slot: 3 ``` ![](/files/bYDcR45vbQqYWOjtk35l) ### Changing the size Now that everything is more compact we can change the actual size of the inventory {% hint style="warning" %} Careful when changing the size. If you change the size but some items are located in slote that are not valid for the inventory's size that GUI will break. So make sure to first locate all items in the correct position before resizing. {% endhint %} Add the following to your **report-detail.yml** and reload the plugin using `/staffplus reload` ```yaml report-detail: size: 18 ``` ![](/files/HNWn2LgQo4UzWoI9LBnu) ### Generalizing style rules {% hint style="warning" %} It's important to note that because all the styling rules are defined underneath the report-detail section, the rules are only applied to that specific GUI. If you would open the reports overview for example the report info item would have none of the below changes {% endhint %} If you would like that your report info item has the above rules applied to every GUI in which it is used we need to move the rules to be less specific to this gui. We can simply do this by creating another file called **reports-styling.yml (**this file will serve as common style rules for reports**)** and place that file inside the styles folder. Remove the entire **report-info** section from the report-details.yml file and add to the **reports-styling.yml** Conveniently in staff++ all report information items in the GUI all have the **report-info** class. So this rule will match all those components regardless of which GUI they are in. ```yaml # All rules for any component with the class report-info $report-info: material: BOOK # All item names in the GUIs have a class called item-name # We can use this to change the color of the item. $item-name: color: "&f" # Change all text part color inside the lore of this item # We use the class name so that we can match all lorelines with one rule. $detail-label: color: "&7" $detail-value: color: "&6" # Hide the entire id line id-label: hidden: true id-value: hidden: true # Hide the entire culprit line culprit-label: hidden: true culprit-value: hidden: true # Hide the entire location line location-label: hidden: true location-world-value: hidden: true location-separator: hidden: true location-block-value: hidden: true # Hide only the status label status-label: hidden: true ``` So now we can see our changes as well in all other GUIs containing report info items ![](/files/O3mHb7SSJCC9cZnMWZ38) ### Full example {% tabs %} {% tab title="styles/report-details.yml" %} ```yaml # The id of the GUI report-detail: # Change the size of the GUI size: 18 # Change the gui title color # All gui titles in staff++ have the $gui-title class $gui-title: color: "&1" # Move the back button to the correct location back-button: slot: 17 # Move the action buttons to the correct location unassign-0: slot: 1 reject-0: slot: 2 resolve-0: slot: 3 # Hide all action items we do not want # ==================================== unassign-1: hidden: true unassign-2: hidden: true unassign-3: hidden: true reject-1: hidden: true reject-2: hidden: true reject-3: hidden: true reject-4: hidden: true reject-5: hidden: true resolve-1: hidden: true resolve-2: hidden: true resolve-3: hidden: true ``` {% endtab %} {% tab title="styles/reports-styling.yml" %} ```yaml # All rules for any component with the class "report-info" $report-info: material: BOOK # All item names in the GUIs have a class called item-name # We can use this to change the color of the item. $item-name: color: "&f" # Change all text part color inside the lore of this item # We use the class name so that we can match all lorelines with one rule. $detail-label: color: "&7" $detail-value: color: "&6" # Hide the entire id line id-label: hidden: true id-value: hidden: true # Hide the entire culprit line culprit-label: hidden: true culprit-value: hidden: true # Hide the entire location line location-label: hidden: true location-world-value: hidden: true location-separator: hidden: true location-block-value: hidden: true # Hide only the status label status-label: hidden: true ``` {% endtab %} {% endtabs %} # Gui structure ### GUIs structure GUIs in staff++ have these main components: * Container -> The inventory as we see it. * Item -> One item in the container represented by an itemstack. * Text -> Text consists of one or more TextParts. * TextPart -> A TextPart holds certain written context. Using the configuration files we can [select components ](/general-information/other/styling-the-guis/selectors)and change their styling. #### Container The container is the inventory we are showing. Using styling we can change: * The color of the title * The size of the GUI #### Item An Item is a wrapper around an itemstack. Using styling we can change. * The location of the item * The color of the name #### Text & TextParts The Text component is used whenever we want to display some sort of text inside the component. The component contains one or more TextParts. Text is used for the title of the GUI and the name or Lore of an ItemStack. Every TextPart can be changed using styling: * TextPart can be hidden/shown * Color of TextPart can be changed. ### IDs and Classes The above components can all be assigned 1 id and multiple classes. #### ID An id is given to a component to identify it, we can use this id to reference the component inside our style configuration. **Class** A class, just like an id, is used to reference a component. The main difference is that a class can reference multiple components. While an id must only reference one. A class is also more lenient in how it can reference components. # Selectors Inside the style configuration files we need to use what we call "selectors" to try and select the correct [component](/general-information/other/styling-the-guis/gui-structure) for which we want to change the styling. We basically have 2 ways of selecting a component. * By ID * By Class Make sure to enable style information by executing `/show-style-info` ![](/files/ch2PpLKfOidieoneboz6) Ids are shown in red and classes are shown in green. ### Gui The ID of the GUI is shown before the title of the GUI ![](/files/xpqkqe8TlTC52LthW597) ### Items Item id and classes are shown before the name of the item ![](/files/x81DiCGAxBTIyjCQU5xG) ### Lore line Ids and classes of the lore lines are shown below the line. Do note that one line inside the lore can consist of multiple parts. Each part is a component and thus can have its own ID and classes. If you see multiple ids next to each other it means there are multiple text parts. ![](/files/LIfL3eiYdIivwpsdkkbg) In this example there are 2 text parts for this one loreline. One is the label "Reporter: " and the other one is the value "garagepoort". ## Selecting and applying styling We use the YAML file format for styling. Inside the `styles` directory we can create whatever yml config file we want and the rules configured in it will be picked up. #### ID selection ```yaml report-detail: report-info: reporter-label: color: "&C" ``` The selector in the above case is: **report-detail -> report-info -> report-label** Basically this means we are selecting a component with the id "report-label" which is part of another component with the id "report-info" which then again is part of a GUI with the ID "report-detail". We can see in the screenshot this will select part of the lore of the report information item. Then we set the styling rules for this component by, in this example, setting the color of that specific part of the lore. #### Class selection ```yaml report-detail: report-info: $detail-label: color: "&C" ``` The selector in the above case is: **report-detail -> report-info -> $detail-label** Basically this means we are selecting any component that has the class "detail-label" which is part of another component with the id "report-info" which then again is part of a GUI with the ID "report-detail". We can see in the screenshot this will select multiple parts of the lore of the report information item. The dollar prefix in `$detail-label` means we are selecting a class and not an ID. Then we set the styling rules for this component by, in this example, setting the color of that those specific parts of the lore. # Configuring command hooks You can configure commands to execute for different parts of the staff++ configuration.\ For example when entering/exiting staff mode or on report lifecycle change This part of the documentation explains how to configure commands. An example of the report commands configuration. ```yaml accept-commands: - command: "tell %culprit% You have been reported. %assigned% will handle the case." target: "culprit" target-run-strategy: ONLINE filters: "hasculprit=true" ``` A command consists of : | property | description | required | default value | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | ------------- | | command | The command to be executed | true | | | executor | Determines by who the command will be executed. If not filled in this will default to "console". Which values you can use for executor is determined by the context in which the command is used. | false | console | | executor-run-strategy | If the executor is not online when the command should be invoked, you can delay the execution by specifying DELAY as run strategy | false | ONLINE | | target | If this command is targeting a specific player you can define the player to be targeted here. If not filled on no target is defined. This should only be used in combination with the **target-run-strategy.** | false | | | target-run-strategy | If target is filled in you also need to provide a run strategy | Required if target is provided | | | filters | Depending on the context in which the command is executed one or more filters may be configured. If all filters are valid the command will be executed. | false | empty | ### Basics The most basic command configuration is as such: ```yaml - command: "mycommand here" ``` The command will be executed by console. ### Custom executor If you want the command to be executed by someone else other than the console you can specify the executor here. Valid values depend on the context of the command. \ \ For example for report commands you can use the "**reporter**" as executor. To know which executor can be used in which context check the documentation page of the corresponding functionality ```yaml - command: "mycommand here" executor: reporter ``` #### executor-run-strategy This property defaults to ONLINE, which means the executor must be online for the command to be run. If he is not online the command will be skipped.\ \ If you would like to wait for the executor to come online, it's possible to define DELAY as run strategy. If the executor is offline, the command will run the next time the executor comes online. If the executor is online the command will run immediately. ```yaml - command: "mycommand here" executor: reporter executor-run-strategy: DELAY ``` ### Target It's possible to define a **target** and **target-run-strategy**. These 2 properties must always be used together. Using these properties we can choose the either not run a command if the target player is offline or to delay the command until the target comes online. Valid values depend on the context of the command. \ \ For example for report commands you can use the "**culprit**" as target. To know which targets can be used in which context check the documentation page of the corresponding functionality If you would like to wait for the target to come online, it's possible to define DELAY as run strategy. If the target is offline, the command will run the next time the target comes online. If the target is online the command will run immediately. ```yaml - command: "freeze %culprit%" target: culprit target-run-strategy: DELAY ``` ### Filters You can specify filters to determine if a command must be executed.\ Valid filters depend on the context of the command. To know which filters can be used in which context check the documentation page of the corresponding functionality For example for commands executed by **warnings** you can use the **severity** filter. ```yaml - command: "freeze %culprit%" filters: 'severity=CRITICAL' ``` #### Permission filter However one filter is always available: | filter | possible values | Description | | ---------- | --------------- | ------------------------------------------------------------- | | permission | Any permission | Only run the command if the executor has the given permission | ### placeholders Different placeholders can be used inside the commands. The placeholders that you can use is depended in the context of the command. To know which placeholders can be used in which context check the documentation page of the corresponding functionality # Commands {% hint style="info" %} All commands can be custom configured inside the `configuration/commands.yml` file {% endhint %} {% hint style="info" %} To disable a command completely edit the commands.yml and provide an empty `''` value for that command. {% endhint %} ## Over**vi**ew ```yaml ############################################################ # +------------------------------------------------------+ # # | Commands | # # +------------------------------------------------------+ # ############################################################ # All commands and their according names. # Leave a command blank to disable it. staffplus: ["staffplusplus"] # The command for toggling staff mode. staff-mode: ["staff"] # The command for toggling fly while in staff mode. staff-mode-fly: ["sfly"] # The command opening the StaffHub GUI staff-hub: ["staffhub"] # The command for toggling freeze on players. freeze: ["freeze"] # The command sending messages on a freeze channel. freezechannel.chat: ["fc"] # The command for teleporting a player to predefined locations teleport-to-location: ["teleportToLocation"] # The command for teleporting a player back to a previous location teleport-back: ["teleportBack"] # The command for teleporting yourself to another player teleport-to-player: ["teleportToPlayer"] # The command for teleporting a player to your location teleport-here: ["teleportHere"] # The command for examining players' inventory examine: ["examine"] # The command for reading notes. notes: ["notes"] # The command for creating player notes note: ["note"] private-note: ["pnote"] # The command for running a clicks per second test on a player cps: ["cps"] # The command for opening the my reports gui my-reports: ["my-reports"] # The command for reporting and managing reports. report: ["report"] players: ["players"] # The command for reporting and managing reports specifically targeting a player. reportPlayer: ["reportPlayer"] reports: chat: ["rc"] manage: #Command to open the manage reports gui gui: ["manage-reports"] gui-find-reports: ["find-reports"] # The command for managing reports specifically targeting a player. cli: ["reports"] teleport-to-report: ["teleport-to-report"] investigations.manage: start: ["investigate"] pause: ["pause-investigation"] conclude: ["conclude-investigation"] gui: ["manage-investigations"] add-note: ["inote"] # The command for warning players warn: ["warn"] # The command for warning and managing warnings. warns: ["warns"] warnings.manage: #Command to open the manage warnings gui gui: ["manage-warnings"] #Command to open the manage warnings gui appealed-gui: ["manage-appealed-warnings"] # The command for opening the my warnings gui my-warnings: ["my-warnings"] # The command for toggling vanish modes. vanish: ["vanish"] # The command for chat management. chat: ["chat"] # The command for creating and managing tickets. ticket: ["ticket"] # The command for alerts management. alerts: ["alerts"] # The command for toggling player following. follow: ["follow"] # The command for reviving players. revive: ["revive"] # The command for listing staff members. staff-list: ["personnel"] # The command for logging in. login: ["login"] # The command for registering a password. register: ["register"] # The command for stripping a player's armor. strip: ["strip"] # The command for clearing a players inventory clearInv: ["clear"] # The command to start/stop tracing a player trace: ["trace"] # The command to view a players ender chest echest_view: ["eview"] # The command to broadcast a message over all servers broadcast: ["broadcast"] # The command to toggle protection of a player protect-player: ["protectPlayer"] # The command to create/delete a protected area protect-area: ["protectArea"] bans.manage: gui: ["manage-bans"] appealed-gui: ["manage-appealed-bans"] # The command to permanently ban a player ban: ["ban"] bans-migrate: ["bans-migrate"] # The command to temporarily ban a player tempban: ["tempban"] extendban: ["ban-extend"] reduceban: ["ban-reduce"] # The command to unban a player unban: ["unban"] # The command to kick a player kick: ["kick"] # The command to permanently mute a player mute: ["mute"] mutes.manage: gui: ["manage-mutes"] appealed-gui: ["manage-appealed-mutes"] # The command for opening the my mutes gui my-mutes: ["my-mutes"] # The command to temporarily mute a player tempmute: ["tempmute"] extendmute: ["mute-extend"] reducemute: ["mute-reduce"] # The command to unmute a player unmute: ["unmute"] # The command to unban a player alt-detect-whitelist: ["altWhitelist"] # The command to unban a player alt-detect-check: ["altCheck"] # The command to view the infractions of a player infractions-view: ["infractions"] # The command to view the players with the most infractions infractions-top-view: ["infractions-top"] webui: register: ["register"] ipban: ban: ["ipban"] tempban: ["iptempban"] unban: ["ipunban"] bancheck: ["ipban-check"] ipbans: ["ipbans"] migrate: ["ipbans-migrate"] ips: clear-ips: ["clear-ips"] choice-action: ["choice-action"] show-style-info: ["show-style-info"] chatchannels: join: ["join-channel"] leave: ["leave-channel"] close: ["close-channel"] staff-locations: create: ["create-stafflocation"] view: ["stafflocations"] teleport-to-stafflocation: [ "teleport-to-stafflocation" ] ``` ### Cooldowns Every command in staff++ can have a cooldown. This is purely permission based.\ If you want to enforce a cooldown, the player needs the cooldown permission.\ \ The permissions is the following:\ `staff..cooldown.