These commands are completely handled by the proxy, so if you try to have a Bukkit plugin on your server execute one of the following Bungee commands, it will not work! There are several plugins that enable running Bungee commands from a Bukkit server, take a look at the Bukkit - Bungee resource category to find some.

If the Typical user: is listed as a Server Administrator, this indicates that the command is for administrating a server and is usually run by administrators of the proxy. If the Typical user: is listed as a Player, this indicates that the command is used by both players and server administrators.

Guide:

<required argument> - this argument is required for executing the command.

[optional argument] - this argument is not required for executing the command.

Commands:

/alert <message>Permission node: bungeecord.command.alertIssues an alert to all users connected to BungeeCord. This is useful for announcements that need to be shown across every server. Colour codes may be used with &. The special code &h will hide all default formatting, allowing for completely custom messages.

Default group: adminTypical user: Server Administrator

/alertraw <json>Permission node: bungeecord.command.alertIssues an alert to all users connected to BungeeCord, but allows the use of Minecraft JSON formatting.

Default group: adminTypical user: Server Administrator

/bungeePermission node: noneShows what version of BungeeCord is currently being run.

/find <player>Permission node: bungeecord.command.findConfirms whether a player with the username provided is online and determines which server the player is connected to.

Default group: noneTypical user: Server Administrator

/glistPermission node: bungeecord.command.listShows a list of all players connected to BungeeCord. This list is separated by each individual server on the BungeeCord proxy and provides a total player count on the proxy.

Default group: defaultTypical user: Player

/greloadPermission node: bungeecord.command.reloadReloads the BungeeCord configuration. Similar to the Bukkit reload command, this is not intended to be used on a regular basis, and can lead to unexpected behaviour. The command will reload all servers, listeners and a few options from the configuration. It will not reload permissions or plugins.Note: This is highly unreliable, and it is strongly recommended that you restart your BungeeCord instance instead of reloading it.

Default group: adminTypical user: Server Administrator

/ip <player>Permission node: bungeecord.command.ipShows the real IP address of a player connected to BungeeCord. This command exists since using an IP command with a Bukkit plugin, such as Essentials, could possibly return as localhost due to the way BungeeCord works.

Default group: adminTypical user: Server Administrator

/permsPermission node: noneShows all permissions you have, and all groups which you are in.

Default group: adminTypical user: Player and Server Administrator

/send <player/current/all> <target>Permission node: bungeecord.command.sendSends the specified player(s) to the specified server. Passing "all" will send all players who are on the proxy but not on the target server. Passing a player name will send the specified player, and "current" will send all players on your server.

Default group: noneTypical user: Server Administrator

/server [server]Permission node: bungeecord.command.serverWhen used with an argument, transfers you to the specified server. When used with no arguments, lists all servers you can connect to.

1. As a prerequisite, install Java 7 or above if you don't have it already (from Java.com).2. Download the latest BungeeCord build from here.3. Place the file inside a new directory dedicated to BungeeCord.4. Create a new startup script to launch the the JAR:

1. As a prerequisite, install Java 7 or above if you don't have it already [Ubuntu, CentOS].2. Download the latest BungeeCord build from here.3. Place the file inside a new directory dedicated to BungeeCord.4. Create a new startup script to launch the the JAR:

1. As a prerequisite, install Java 7 or above if you don't have it already [OS X].2. Download the latest BungeeCord build from here.3. Place the file inside a new directory dedicated to BungeeCord.4. Create a new startup script to launch the the JAR:

Depending on your Minecraft host's configuration, you will have two ways to enable the use of BungeeCord through Multicraft.

If there's already an option for BungeeCord in the JAR file selection menu, you can simply select it and restart your server upon save. However, this may not be recommended if your host does not keep up to date with the latest bungee builds.

If you have access to upload custom server JARs (FTP), download the BungeeCord JAR and enter in the name of the file via the JAR file input box located on the index of the panel. Some hosts may require you to rename your JAR to a specific name (like custom.jar) and then select it from the dropdown menu.

If your personal server you have root to, place the bungecord.jar.conf in your daemon jar directory, then update the jar using the admin panel. The jar should now be the client's jar selection.

It is generally recommended to allocated 512MB RAM for every 500 players. Please keep in mind that additional plugins may impact the amount needed in your case. To allocate more RAM change the -Xms and -Xmx values in the start-up script. To allocate 1GB of RAM, simply enter both values as 1G.

The recommended platform to run BungeeCord on is Linux. While you are able to start and use BungeeCord on Windows and Mac OS X, this is not recommended and support may be limited in this case.

Once you have successfully installed BungeeCord, it is time to get it working properly. One of the most essential steps is to set your connected server instances (e.g. Spigot, Bukkit) to run in offline-mode, which can be achieved by modifying server.properties. In addition, you will need to set connection-throttle to -1 in bukkit.yml.

DATA CONSISTENCY WITH UUIDS & IP FORWARDING:To support online-mode UUIDs, name changes, and IP bans, enable ip_forward: true in BungeeCord's config.yml. If you don't, serious data inconsistencies will occur. Note: you still need to set online-mode to false in the server.properties files of your servers.

Set bungeecord: true in spigot.yml throughout all of your Spigot backends.

If any backends are using Spigot-CraftBukkit, switch to Spigot and follow the applicable instructions.

IMPORTANT SECURITY NOTICE:
As your servers will now be running without authentication, this poses a new security risk. Users may connect to your servers directly, under any username they wish to use. Unfortunately for them, this issue can be easily combated by restricting access to these servers.

↳ BungeeCord and servers on the same machine

Just edit the server.properties of each server, so that the server-ip value is set to 127.0.0.1. Keep in mind during testing that the player whitelist will be ignored for connections coming from the same host as your proxy!​

↳ BungeeCord on a GSP (Minecraft host)

You will need to secure your setup by using an IP whitelisting plugin to accept connections only from certain IPs (BungeeCord and all regular servers). One such plugin is IPWhitelist.​

↳ BungeeCord and servers on different machines

In this case, a server firewall is needed to ensure no one can access your backend servers. Please see the firewall guide for more information.​

Adding Servers: You must add new entries for each Minecraft server you wish to link under servers in BungeeCord's config.yml, consisting of the address (IP/host), MOTD, and whether or not it is restricted.

Server Icon: Place your 64x64 png file named server-icon.png into the same folder that BungeeCord is in and restart the server.

]]>35A Reminder About Using the WikiWed, 24 Jan 2018 19:03:05 +0000https://www.spigotmc.org/threads/a-reminder-about-using-the-wiki.148364/
https://www.spigotmc.org/threads/a-reminder-about-using-the-wiki.148364/invalid@example.com (jtaylor69)jtaylor69
First of all, thank you to those of you, who have contributed a tremendous amount of useful edits to the wiki, your help has provided valuable in ensuring that both new and existing users get the help they deserve.

Secondly, I'd like to express some concerns that I have with some of the recent posts that have been occurring.

Using the Wiki as the Forum

Unfortunately, I've had to remove quite a number of articles in the past few weeks.
These articles are typically...

Originally, plugin messaging was implemented so server-side plugins could send any kind of data to client-side mods. Before, they would have needed to implement custom packets, but the problem with this is that it meant the Minecraft client would get disconnected from the servers using those custom packets with an incomprehensible error message, because it would be unable to read that packet. To fix this issue, Mojang introduced the "Custom Plugin Message Packets".

The anatomy of a Plugin Message Packet is as such:

The name of the "channel" (also named "tag" in BungeeCord) the plugin message transits through (in a string)

BungeeCord exposes a plugin channel to the backend/Bukkit servers called "BungeeCord". The byte array you will send (and receive) will use output generated by the DataInputStream and DataOutputStream classes. For convenience, we will use the ByteArrayDataInput and ByteArrayDataOutput classes from Google Guava, which silences IOException for us.

Before using the BungeeCord plugin channel, you'll need to register it with the Bukkit messenger. That is, you need to tell Bukkit "Hey, I want to use this channel". We'll also need to tell Bukkit what method to call whenever they receive a new message on channel "BungeeCord". Here is a example of a simple plugin message-enabled plugin:

Send a custom plugin message to said server. This is one of the most useful channels ever.Remember, the sending and receiving server(s) need to have a player online.

Arguments
String server to send to, ALL to send to every server (except the one sending the plugin message), or ONLINE to send to every server that's online (except the one sending the plugin message)
String Subchannel for plugin usage.
Short The size of the plugin message array.
Byte[] message to send.

Receiver
Any player

Example

Code (Java):

out.writeUTF("Forward");// So BungeeCord knows to forward it
out.writeUTF("ALL");
out.writeUTF("MyChannel");// The channel name to check if this your data

As you develop, you will come across many instances where you will have to store data. A lot of the time, you can store this data in an object such as a HashMap or an ArrayList. So why use configuration files? The reason for this is that when the server is closed or restarts, it recreates everything and all the data you stored would have been lost. This is because objects such as those are stored in the virtual memory. In other words, just as easily as they were created, they are also destroyed.

Now this is where files come in handy. Files are a way of saving data in a form that won't get deleted after your program is terminated. This is because files are no longer stored in virtual memory, but rather, on your actual storage disk. You can use this for storing information such as player balances, nicknames, and all sorts of data that you want to keep even after the server restarts.

This is a check to see if your plugin folder doesn't exists. The way Spigot/Bukkit manages plugin information is that each plugin has its own "data folder". These are the folders you see in your server's plugin folder named after the plugins containing important information such as their own individual configuration files. To get the path of this folder, you call the method getDataFolder() to return the File which is a path to what the server has designated as your plugin's Data Folder. The 'if' statement is checking whether or not the folder exists, and if it doesn't, it then calls the mkdirs() method (which basically creates the directory).

This is where you declare your config file itself. To do this, you create a File object and construct it with the parameters 'getDataFolder()' and "config.yml". Like it was mentioned earlier, the getDataFolder() method returns a file which is the directory of your data folder. Now by putting it as the first parameter, it is telling your constructor that it will create a file named "config.yml" in the directory which is named by getDataFolder(). Now, that file isn't actually stored yet in your storage. It is still in virtual memory. The next 'if' statement checks whether or not the file exists and if it doesn't, it creates it and tells your plugin that this file is going to be 'my' config file. You should call saveDefaultConfig() to tell that this is how my default config file will be like.

This is essentially all you need to create a quick configuration file, but remember to call it in your onEnable() method to make sure that you have a configuration ready before anything else happens.

To read and write to the config using the above method, we call the getConfig() method. However, if you will be calling getConfig() outside of your main class, you should use the main class's instance. If you do not know how to get instances from other classes, I suggest you check some of the other short guides on how to use constructors (the most commonly used). Once you have an instance, simply use that instance and call getConfig() from it.

Now that you have the config, you can read and write to it using its different getter and setter methods. An example would be:

Code (Java):

// Reading from the configString name = plugin.getConfig().getString("player-name");

// Writing to the config
plugin.getConfig().set("player-name", name);

What is it exactly? The "player-name" is your path in the config. If you've seen other YAML configuration files, you'll notice that they take the format of "label: value". To access the value of a particular path, you can use its name. However, you'll also notice that there are sometimes "sub-paths" wherein there are labels that belong under another label.

Code (YAML):

player-name: Steve
player:
time:
join: 6:00pm

To access the value of something that's a sub-path, you can simply use '.' to indicate a lower level like so:

Code (Java):

// Reading from the configString time = plugin.getConfig().getString("player.time.join");

The plugin will read the '.' as an indicator that "Oh! I should check the sub-path."

Note that although I used a String in the getting and setting examples, you can use all sorts of different types as well. For the getters, there exists getInt(), getBoolean(), getList(), and many more. For the setters, it simply takes in the path as the first parameter and an Object as the second. This means that you can set basically any Object.

An important thing to note, however, is that after you read and/or write to a configuration file, you should always remember to save the data if you want it to be saved to the file. To do this, you should do :

Code (Java):

plugin.saveConfig();

Configuration has all sorts of fun tricks and tools that you can use to make the best plugin you can make. Use it properly and it can be one of your most powerful assets.

First of all, you'll want to be able to make your File and FileConfiguration objects available to other classes in your plugin so that you can readily read and write to your different configuration files. How do you do this?

In your main class, create field variables. These are variables that are not contained within a method so that they can be accessed externally.

What does this do? It's a snapshot of how a basic main class would look like. What else it does is that it creates two configuration files, namely, "config.yml" and "special.yml". When the plugin is enabled, it calls the createFiles() method. What this does is that for each File object, it checks if it exists. If it doesn't, it creates it. This part can be better explained in Using Single Configuration Files.

What about the saveResource(String, boolean) part? You can actually store files inside your jar aside from just classes. To do this, depending on your IDE, you should create a new file in your 'src' folder (names may vary depending on editor). Now in your main class, you can call saveResource("name of file in jar here", replaceIfAlreadyExists). This will save the file stored in your jar to the file <data folder>/<name of file in jar> if it doesn't already exist (or if the boolean was true). Now, you've created the multiple configuration files!

Basically, you can access the configuration the same way as you would do getConfig() from Using Single Configuration Files. If you want to see more on how to manipulate and access configurations, read that section. As for saving, for custom configurations you need to call FileConfiguration#save(File) (which saveConfig() does under the hood for config.yml) to write the data to the disk.

What is it?
Articles under this wiki category contain user-contributed pieces by developers who wish to provide small snippets of code to help you get started writing your own plugin. While they are simple in nature, they are intended to help you get started programming with the Spigot API and should serve as stepping stones for bigger and greater projects! By referencing code snippets or guides in this category, beginning users can read well-composed guides and articles that will teach good habits and provide a useful reference as they begin to dip their feet into the Spigot API.

How can I contribute?
Want to contribute your own code? First, before creating a wiki article for your example code, please have it peer reviewed in the Spigot Plugin Development forum first. We wish to only publish code that demonstrates good habits and methods that will help developers get started on the right foot.

Once you have had your code peer-reviewed, please create a new wiki article and set the Parent Node as "Plugin Snippets". If you have any questions, please leave them in the discussion thread.

Type:
Description: Here, you can assign players to a permission group that you created earlier in the configuration.
The format is groups, followed by each player, followed by each group he/she is in. By default "md_5" is given "admin" group, which gives permissions as defined by permissions section. Every player has default. Only add players who need more than the default permissions.

disabled_commandsDefault: disabledcommandhereType: ListDescription: Use this to disable commands on your BungeeCord instance.

player_limitDefault: -1Type: IntegerDescription: Global player limit for your BungeeCord instance. If set to -1, this will allow an unlimited amount of users to join.

statsDefault: (randomly generated string)Type: StringDescription: Used for stats purposes, please do not remove or alter the code. This is a randomly generated number in the purpose of providing stats. Stats are anonymous packets of usage collected on MCStats. This is something you should never edit, so please leave it be!

Description: These are the permissions of what commands or actions you can use within the proxy. Please note, that these are different to Bukkit/Spigot permissions. The permissions are group based and are used to attach players later on in the configuration. All players will have ability to use the commands under "default", those players given the "admin" group in the "groups" section are allowed to use the extra commands for BungeeCord as stated below that group. Note each group only inherits "default" so you may need to put the same node in different groups if you add more.

listenersDescription: The following items are configurable options that can be found under the listeners section of the BungeeCord configuration. Multiple listeners can be added to listen on several IP's and ports.

max_playersDefault: 1Type: IntegerDescription: The max player limit shown in the minecraft client's multiplayer menu. Note that this limit is fake, you can set it to 0, players will still be able to join. Look at player_limit above for a "real" player limit.

hostDefault: 0.0.0.0:25577Type: StringDescription: The IP and Port in which the BungeeCord instance will be hosted on. Use 0.0.0.0 to listen to all IPs (recommended).

bind_local_addressDefault: trueType: BooleanDescription: Whether the address Bungee uses to connect to your servers will be explicitly set to the address Bungee is listening on. This serves no purpose unless your system has multiple IP addresses.

ping_passthroughDefault: falseType: BooleanDescription: Whether to pass the ping through when we can reliably get the target server (force default server).

tab_listDefault: GLOBAL_PINGType: StringDescription: The tab list has a choice of 3 options.
GLOBAL_PING: This shows all players connected to the proxy, complete with ping.
GLOBAL: As above, but without updating their ping.
SERVER: This shows the local players on the server you are connected to.

Note - BungeeCord 1.8+ versions currently do not have working GLOBAL or GLOBAL_PING options due to 1.8+ having a new tab list. You may use the plugin GlobalTablist or BungeeTabListPlus to have this feature in 1.8+

prioritiesDefault: lobbyType: ListDescription: On connection of first time players, or if forcing default server, all connecting players, BungeeCord goes through this list of servers from top to bottom and tries to forward the connection to each of them. So if you would like to support multiple client versions, simply specify at least one server per version and BungeeCord will do the matching for you.

forced_hostsDefault: pvp.md-5.net: pvpType: MapDescription: Allows for redirection. If the pvp.md-5.net sub-domain of the domain md-5.net is joined, it will bypass the default server and go to the server that is stated in the config, in this case directly to the pvp server. Note: this requires you to make sub-domains forwarded to your BungeeCord address via the main Dynamic DNS as for your main domain.

tab_sizeDefault: 60Type: IntegerDescription: The amount of players that will show up in the tab list (Pressing tab on keyboard)

force_default_serverDefault: falseType: BooleanDescription: If true, the player will always connect to the default server when the join the server. If false, the player will join the server they were last connected to. Note: "forced_hosts" does NOT override this. To make the "forced_hosts" setting work, set this to false.

motdDefault: "Another Bungee Server"Type: StringDescription: The message to be displayed in the multiplayer menu when players ping the server.

Note: restricted prevents players from joining the server unless they have the bungeecord.server.[servername] permission
Type: MapDescription: Within this section, you will list all the servers that will be connected to via the BungeeCord instance. It is recommended to use lowercase for the names of the servers.

network_compression_thresholdDefault: 256

ip_forwardDefault: trueType: BooleanDescription: Whether to enable IP (which forwards the players true IP to Bukkit, rather than the proxy IP) and UUID forwarding (which forwards the players true online-mode UUID to Bukkit, rather than an offline-mode username hash!)
If you're running an online-mode: true server, It is highly recommended you use this option!
If using this option, please follow this guide to ensure that you have enabled it correctly.

online_modeDefault: trueType: BooleanDescription: Whether the BungeeCord instance will authenticate with the Mojang servers. If set to false, cracked players will also be able to join your server.

prevent_proxy_connectionsDefault: falseType: BooleanDescription: This makes the server send the IP of connecting players to Mojang.

proxy_protocolDefault: falseType: BooleanDescription: This allows the server to support the HAProxy PROXY protocol. Most users shouldn't need to enable this

The spigot.yml file serves to provide greater customization and configuration of the many different features of Spigot. This file is used in conjunction with the bukkit.yml file, so it is normal to see both files in your server's root directory. There are several different options to customize Spigot in a way that best suits your server, and each setting is documented below.​

Contents

tab-completeAbove #1368:Default: 0Type: Integer
Description: You can now specify how many letters of the command must be typed before it will be tab completed this will help deter people from just spamming round all the commands to see if there is one incorrectly set up.
0 will tab complete all commands
-1 will disable tab completely
1 will mean you have to type the first letter
2 will mean you have to type the second letter... etc...Below #1368:Default: trueType: BooleanDescription: Controls whether or not a player should be allowed to press the TAB key to auto-complete commands. If enabled, this may pose somewhat of a security risk, as a player will be able to view all registered commands when typing in / and then pressing TAB.

silent-commandblock-consoleDefault: falseType: BooleanDescription: Controls whether or not to allow commandblock output to console.

logDefault: trueType: BooleanDescription: Controls whether or not to print player commands to console/log which will be saved in your logs folder in your servers directory.

whitelistDefault: "You are not whitelisted on this server!"Type: StringDescription: When whitelist mode is enabled, this is the message that will be displayed to all un-whitelisted users upon connection. You can add people to your whitelist by /whitelist add {username}

unknown-commandDefault: "Unknown command. Type "help" for help."Type: StringDescription: this is the message that will be displayed in the chat if a player types in a command that is not registered/non-existent.

server-fullDefault: "The server is full!"Type: StringDescription: When the server is "full" (player count matches your maximum slots), this is the message that will be displayed to players that are kicked/denied to join until more slots open up.

outdated-clientDefault: "Outdated client! Please use {}"Type: StringDescription: Message that will be displayed to joining players with an older version of Minecraft than your server. {} will be replaced with the server's current version.

outdated-serverDefault: "Outdated server! I'm still on {0}"Type: StringDescription: This is the message that will be displayed to joining players with a newer version of Minecraft than your server. {0} will replaced with the server's current version.

restartDefault: "Server is restarting"Type: StringDescription: This is the message that will be displayed to all connected players after a server restart is triggered through the /restart command.

disable-savingDefault: falseType: BooleanDescription: If enabled, then the server will not save player statistics or achievements. It is recommended to force 'achievement.openInventory'(by setting it to 1) to prevent the achievement from freezing on the player's screen.

forced-statsDefault: {}Type: MapDescription: A map of statistics and the values they should be forced to.
For instance, this snippet will automatically grant everyone the openInventory achievement, but will not notify players through chat or achievement box:

disable-savingDefault: falseType: BooleanDescription: If enabled, the server will not save player advancements that were introduced in 1.12.

disabledDefault: []Type: ListDescription: A list of disabled advancements. Advancements on this list are unobtainable in the game and will not be shown in the advancement GUI, accessible through the 'advancement' button when pressing escape or when pressing the key bound to open this menu (default = L). Disabling an advancement will lead to errors in the console if all advancements that are children of this advancement are not also disabled. To disable all of the advancements, paste the following list into this option.

netty-threadsDefault: 4Type: IntegerDescription: Controls the amount of threads Netty will use to perform networking.

bungeecordDefault: falseType: BooleanDescription: Toggles the various BungeeCord-only features. This includes IP whitelisting (this should not be treated as a complete solution, rather, an extra layer of security, you still need to setup IPTables!) and pass-through IPs (so that servers will be able to see a player's true IP).

timeout-timeDefault: 60Type: IntegerDescription: How long - in seconds - the server should go unresponsive before performing a thread dump in the console and, if configured, attempt to shut down and restart.

restart-on-crashDefault: trueType: BooleanDescription: Controls whether or not the server will automatically attempt to restart your server when a crash occurs.

restart-scriptDefault: ./start.shType: String(File path)Description: The location for your server's startup script. This path will be used for the /restart command and for the restart-on-crash option.

late-bindDefault: falseType: BooleanDescription: This delays players from entering the server until all plugins are loaded. Please note, it is advised to test this before putting it into practice as there may be problems with some plugins.

sample-countDefault: 12Type: IntegerDescription: Controls the amount of (randomly chosen) sample players shown when hovering over the player count in the client's server list.

player-shuffleDefault: 0Type: IntegerDescription: This prevents players from 'gaming' the server, and strategically relogging to increase their position in the tick order. Basically, players' packets are processed in order depending on when they joined, relogging changes your position in queue meaning your actions happen before others. Enabling this prevents the relogger from having the advantage. Useful for PVP servers.
The value is in ticks, so 20 = shuffle every second. Setting this option lower than 100 may cause performance issues (0 is fine though).

save-user-cache-on-stop-onlyDefault: falseType: BooleanDescription: Toggles whether or not to constantly save new usercache data to disk or only to do so when the server stops.

int-cache-limitDefault: 1024Type: IntegerDescription: This prevents unbounded growth of the integer cache and instead caps it to a value specified in the configuration (1024 by default). Should prevent thrashing, especially around world generation.

moved-wrongly-thresholdDefault: 0.0625Type: DecimalDescription: Controls the threshold for the "moved wrongly" check. Increasing this number may reduce the amount of rubber-banding on the server but could potentially be abused by players as well.

moved-too-quickly-multiplierDefault: 10Type: DecimalDescription: Controls the multiplier for the "moved too quickly" check. This is effectively the maximum speed the server will allow a player to move. This can cause problems in certain cases, for example large TNT cannons.

global-api-cacheDefault: falseType: BooleanDescription: Causes all requests made on Mojang's username -> uuid API to be cached by Spigot as much as possible

item-dirty-ticksDefault: 20Type: IntegerDescription: Controls the interval for the item-dirty check. Minecraft checks an item every tick to see if it was changed. This can be expensive because it also needs to check all nbt data. Spigot only checks for basic count/data/type data and does a deep check every 20 ticks by default.

To apply these per-world, add a new section under world-settings with the world directory's folder name.

verbose​

Default: trueType: BooleanDescription: Whether or not to show the detailed report and configuration for each world in console/log on server startup. Can be disabled/enabled globally or per-world.

view-distanceDefault: 10Type: IntegerDescription: Controls the amount of chunks that will be loaded around every player. This value cannot be higher than 15 or lower than 1. Lowering this can lower the load on servers if you have a large amount of players online.

merge-radius:

↳ expDefault: 3.0Type: IntegerDescription: Controls the range - in blocks - which experience orbs will "group" together when on the ground.

↳ itemDefault: 2.5Type: IntegerDescription: Controls the range - in blocks - which items will "group" together when on the ground.​

chunks-per-tickDefault: 650Type: IntegerDescription: Controls the amount of chunks that will be updated for growth per tick. Lowering this will potentially make growth slower while saving resources, and vice versa.Versions: Before Spigot 1.9

item-despawn-rateDefault: 6000Type: IntegerDescription: Controls the amount of ticks required before an item entity on the ground will despawn. Lowering this will make items de-spawn faster (potentially saving resources as there are less entities to tick), while increasing this will take them longer to de-spawn and use up more resources (as the item entities will have to be ticked for longer until they de-spawn).

mob-spawn-rangeDefault: 4Type: IntegerDescription: Radius in chunks around the player in which mobs will spawn. Increasing it will make mobs seem more rare and dispersed, although lowering it may prevent certain spawns as there is not enough spots in which they are allowed to spawn in. See the Minecraft spawn mechanics for more information.

growth:

↳x-modifier​

where x = cactus, melon, pumpkin, sapling, cane, mushroom, wheat

Default: 100Type: IntegerDescription: Controls the speed of growth for each crop/resource as listed above. When at the default value (100), they will grow at 'vanilla' speed, but may appear slower due to other settings (chunks-per-tick).Does not improve performance to change these values. You should only change these away from 100 if you want to change the gameplay behavior of crop growth, and never change this for performance.​

entity-activation-rangeDefault:(animals: 32, monsters: 32, misc: 16)Type: IntegerDescription: Controls the range in blocks that entities will become "activated" - entities outside of this range will tick at a reduced rate to prevent server lag. When changed, these numbers can adversely affect gameplay, so edit with caution.Lowering these values can give a major boost to performance, but at the cost of affecting gameplay behavior. Lowering these might impact item and monster farms, but should have little impact to normal behavior.

entity-tracking-rangeDefault:(players: 48, animals: 48, monsters: 48, misc: 32, other: 64)Type: IntegerDescription: Controls the range in blocks that entities will become "visible" or otherwise known as "tracked" to the client. Entities outside of this range will be invisible as they are not being rendered to preserve CPU usage and bandwidth. This is particularly useful for PVP servers, as turning down the player range will 'nerf' wallhacks and radar to some extent. Miscellaneous controls the range for item frames, paintings, dropped items, experience orbs, and sign text. Other is a general maximum limit for all entities on your server.Does not improve server performance to change these values. These will only help client side lag when lowering these.

save-structure-infoDefault: trueType: Boolean
Description: Toggles whether or not Spigot will save the structure info with the newly introduced saving method in 1.6.3. If disabled, this can cause issues with Eyes of Ender not pointing to strongholds, wither skeletons not spawning in Nether Fortresses, witches not spawning in huts in 1.7.

​

random-light-updatesDefault: falseType: BooleanDescription: Controls whether or not the server will randomly sample chunks in order to verify and fix lighting. As of 1.7, also controls whether or not the server will relight a chunk on its first tick.

nerf-spawner-mobsDefault: falseType: BooleanDescription: When enabled, mobs which originate from a mob spawner will not have any AI. They will generally only be affected by water movement, with the exception of blazes which will still emit fireballs and float up and down.

zombie-aggressive-towards-villagerDefault: trueType: BooleanDescription: When disabled, zombies will no longer attempt to kill villagers, changing game play. But in return zombies use less time in order to process their AI, creating less lag as a result.

enable-zombie-pigmen-portal-spawnsDefault: trueType: BooleanDescription: When disabled, nether portals will no longer randomly spawn zombie pigmen in them. This can be used to combat large nether portal gold farms and does not effect the movement of entities, including zombie pigmen, through nether portals between dimensions.

max-entity-collisionsDefault: 8Type: IntegerDescription: Limit a single entity to colliding x number of configurable times per tick. This setting lowers the performance impact of entities trapped in a 1x1 pen.

dragon-death-sound-radiusDefault: 0Type: IntegerDescription: Limit the sound of the dragon's death.

max-bulk-chunksDefault: 10Type: IntegerDescription: Set how many chunks are sent per packet.Versions: Before Spigot 1.9

max-tick-timeDefault:(tile: 50, entity: 50)Type: IntegerDescription: The time - in ms - that (tile) entity operations can consume to calculate before the server skips on to the next task. Values between 10 - 20 for tiles and 20 - 25 for entities have been reported to provide a good performance increase.Lowering these values can give a major boost to performance, but at the cost of affecting gameplay behavior. Lowering these for entities could lead to them to appear to lag/stutter but should have no other impact on normal behavior.

clear-tick-listDefault: falseType: BooleanDescription: Can potentially prevent the possibility of the tick list increasing over time but introduces several issues, namely, growth slow-downs and modifications to the values many of you have fine-tuned. This option is here only for those who absolutely need it and are completely understanding of the consequences. It is not recommended for the majority of server owners and should be left at the default.

hopper-alt-tickingDefault: falseType: BooleanDescription: Dynamically ticks hoppers so as to mirror vanilla behavior and provide a potential ticks per second boost. Best set to true for lots of idle hoppers. Enabling this option disables hopper-check.Versions: Before Spigot 1.8.3

hopper-amountDefault: 1Type: IntegerDescription: Controls the maximum amount of items a hopper will take in/give out in a hopper tick cycle. Best used in conjunction with higher ticks per hopper transfer and check to combine actions into one.

seed-villageDefault: 10387312Type: IntegerDescription: Controls the seed used for the placement of villages in your world, allowing for further customisation of their spawning. Default value represents vanilla.

seed-featureDefault: 14357617Type: IntegerDescription: Controls the seed used for the placement of features such as nether strongholds in your world, allowing for further customisation of their spawning. Default value represents vanilla.

seed-monumentDefault: 10387313 [??]Type: IntegerDescription: Controls the seed used for the placement of sea monuments in your world, allowing for further customisation of their spawning. Default value represents vanilla. [??] = Uncertainty of whether value is random (unique) or if the same value is applied to every fresh config. (Value was taken from a config.)

seed-slimeDefault: 987234911 [??]Type: IntegerDescription: Controls the seed used for the spawn locations of, presumably, the Slime mobs in your world, allowing for further customisation of their spawning. Default value represents vanilla. [??] = Uncertainty of whether value is random (unique) or if the same value is applied to every fresh config. (Value was taken from a config; unknown if this should match World Seed)

↳ hopper-transferDefault: 8Type: IntegerDescription: The time - in server ticks - between when a hopper pushes/pulls/receives items and when the hopper pushes/pulls more items. A value of 8 mirrors vanilla behavior.↳ hopper-check (Removed in this 1.8.3 commit from March, 8th 2015, readded in this 1.11.2 commit from February, 10th 2017)Default: 1Type: IntegerDescription: The time - in server ticks - hoppers attempt to push/pull items since the last attempt. For example, a value of 8 means an empty hopper looks for item entities above, inventories above, etc. every 8 ticks. A value of 0 or 1 mirrors vanilla behavior. This option is disabled when hopper-alt-ticking is set to true. Changing this value will break most hopper contraptions due to desyncs.​

Contents

This is an example of what to put in your pom.xml to get the API's from the repository.
You should only use one of them.
If you want to use Spigot API's, in addition to Bukkit, you should use just the Spigot API. If you want to use NMS, you can just add “spigot”. This contains the Bukkit API, the Spigot API, NMS, and the Spigot patches for NMS. Take note that to use NMS you need to have run BuildTools for the appropriate version locally, in such a way it is found located under ~/.m2.
Just add the following code in your pom file.

For a long time, Minecraft server owners have had a dream that encompasses a free, easy, and reliable way to connect multiple Minecraft servers together. BungeeCord is the answer to said dream. Whether you are a small server wishing to string multiple game-modes together, or the owner of the ShotBow Network, BungeeCord is the ideal solution for you. With the help of BungeeCord, you will be able to unlock your community's full potential.

What is it?
BungeeCord is a useful software written in-house by the team at SpigotMC. It acts as a proxy between the player's client and the connected Minecraft servers. End-users of BungeeCord see no difference between it and a normal Minecraft server.

How does it work?
When the player connects to BungeeCord, it bridges the connection seamlessly to the Minecraft server and allows the player to connect. From there, the player can use integrated commands and/or plugin-operated portals to move themselves to different servers. This system allows for a single server to become a network of seamlessly integrating servers. The possibilities are endless!

Features
Written from the ground up using all new development practices and principles, this project aims to be the most efficient, reliable and feature-packed system around. It's already dominating similar systems that are costing end-users hundreds of dollars per month.

BungeeCord comes with the ability to load plugins that are written against its expansive API. The BungeeCord system can not only seamlessly integrate with existing set-ups, but can also be limitlessly expanded to create anything. From global ban integration to your very own M.M.O. multi-verse, BungeeCord can surely handle it.

BungeeCord can spread out the load of a population spanning multiple servers, taking full advantage of multi-core CPUs.

The best way to fool-proof and secure your BungeeCord server is using a firewall in order to prevent access to them at all from the outside world. By default, most Linux distros come preinstalled with the easy to use iptables. Once you have everything set up you can activate this firewall with the comand below. Replace $BUNGEE_IP with the IP of the server running BungeeCord, if your Minecraft server(s) and Bungeecord are on the same physical server, this IP will be 127.0.0.1. Replace $SERVER_PORT with the port of your Minecraft server.

Alternatively if you have multiple Minecraft servers running instead of writing a rule for each server and its port you can use the following command to add a port range which will be blocked with the firewall. Replace $START_PORT and $END_PORT with your desired port range, don't forget the colon in between.

The code below is an iptables script for multiple dedicated machines with multiple servers by PhanaticD. Make a file called firewall.sh and paste the script below into it. Make necessary modifications to match your IPs and ports.

If you cannot configure a firewall, there are multiple plugins which will allow you to achieve a similar result. Keep in mind third party plugins will never be as secure as a firewall, and should only be used as a last resort.

However, these plugin solutions may not fully protect you, given the following example.

You have three Minecraft services on a shared host:

BungeeCord running on 22.256.113.64:30000

Spigot Server #1 running on 22.256.113.64:30001

Spigot Server #2 running on 22.256.113.64:30002

IPWhitelist setup, on Spigot Server #1 and #2.

If a malicious user purchases hosting from the same company, and are assigned to the same node as you*, all they have to do is setup their own BungeeCord, and they will be able to bypass plugins that restrict logins per-IP.

*If not, the malicious user may be able to port-scan the server and reveal other Minecraft servers and target their owners (whom have their server on the same node) to let them use their hosting account.

BookMeta is the Bukkit interface for the CraftMetaBook object in CraftBukkit. As of when this guide was written, the BookMeta interface does not have a method to obtain the pages as a list of IChatBaseComponent objects (which is what is stored in CraftMetaBook). This means we will have to get the pages using reflection. Here is an example of how you can do that.

Using the BungeeCord chat component API (which is included in the spigot server jar) you can produce an IChatBaseComponent which contains click and hover events.
Alternatively you could generate your own jsonString which will enable you to use book specific events.

Code (Java):

BaseComponent text;//this is the base component we will be turning into a page

Contents

A vector is represented by a length and a direction and always describes a movement from one point to another. Most of you will already have heard about vectors or seen some strange arrows representing them. Let's have a look at the vector in Spigot.

The vector in Spigot can be found in org.bukkit.util (JavaDoc) package and can be created the following ways:

Code (Java):

Vector v =newVector();//Creates a vector with length 0 and NO directionVector v =newVector(x, y, z);//Creates a vector with defined direction and length

Each vector has three values that represent the vector, called X, Y, and Z (the 3 directions). Also important to know is that you can get the length of a vector by calling .length() and subsequently get / set the value of every axis by calling .getX(), .getY(), .getZ(), and .setX(x), .setY(y), .setZ(z).

This calculation returns a vector that is orthogonal to both of the previous vectors. Its length is the area of the light blue parallelogram. This can be used to compare if two vectors are nearly the same (for example, when targeting a player).

publicboolean doesPlayerTarget(Player p, Location target){//p is your player//target is the location the player might target

//Check if they are in the same worldif(!target.getWorld().equals(p.getWorld()))returnfalse;

//Let's begin!//Get the players head location
Location head = p.getLocation().add(0, p.getEyeHeight(), 0);//Get the players looking direction as vector and// shorten it to a length of 1 by using normalize()Vector look = p.getLocation().getDirection().normalize();

//Get the direction of the target from the player by substracting his location with the target//Again use normalize() of course, to shorten the valueVector direction = head.subtract(target).toVector().normalize();

//Lets build our crossProduct. When the crossProduct's length is 0, the player//is exactly targeting our target location//why? because then the parallelogram shown above has an area of 0 :)

The leading community for Minecraft server owners and content creators.

What is SpigotMC?
Founded in 2012, SpigotMC.org is is home to the community behind the biggest Minecraft server software projects and provides a place for everyone involved with Minecraft servers to connect with each other whether they seeking help and support or sharing and showcasing their work. We provide a web forum, chat room and wiki for providing support as well as project hosting for content creators and hope that you too will become involved in this extensive and growing community of more than 300,000 members.

What Software Do We Provide?
The SpigotMC team works hard to support and maintain several major pieces of software for use when running or developing a Minecraft server. All of our software is completely free and open source, available on either our Stash or GitHub. We are supported by voluntary donations which we hope you will also contribute to one day.

Spigot - Install
As suggested by the name, Spigot is the original and most widely used of our software. It is a modified Minecraft server based on CraftBukkit which provides additional performance optimizations, configuration options and features, whilst still remaining compatible with all existing plugins and consistent with Vanilla Minecraft game mechanics.

There are over 150 improvements present in only in Spigot, including BungeeCord support; configuration of many internal server values such as crop growth rates, hunger, entity tracking, map seeds; enhanced watchdog and timings profiling to catch plugin issues; further configuration to heavy elements such as entity activation and hoppers; rewritten chunk loading, unloading and saving; and some useful API additions for developers.

If you are really keen you can check out the complete list of patches here, but really the best way to find out all that Spigot has to offer is to simply try it!

BungeeCord - Install
BungeeCord is a completely original SpigotMC creation which acts as a proxy allowing you to link many different Minecraft servers together and teleport between them in any way you choose, whether that be commands, portals, inventory menus or something unique of your own creation. With BungeeCord there is no need to limit yourself to one server, instead you can combine tens or even hundreds of servers of different gamemodes right around the globe. BungeeCord powers all of the top Minecraft networks with proven scalability of more than 40,000 players and enables you to make the most of your server resources. It also has a complete plugin API which developers can use to write plugins such as chat or parties that function across your entire network.

CraftBukkit
When the Bukkit.org project ceased operation in Q3 2014, the SpigotMC team took over providing continued support and updates to this important software with a rich legacy. CraftBukkit is a modified version of the Vanilla Minecraft Server which allows it to run Bukkit plugins. The main goal of this project is to produce a server as close to Vanilla as possible, barring the addition of plugin support. That being said CraftBukkit still retains some useful configurability and optimizations such as asynchronous chunk loading, and also fixes for some critical Vanilla bugs or exploits. All installs of Spigot via BuildTools will also generate a CraftBukkit jar file in case you wish to use this over Spigot (although we hope you will find no reason to).

Bukkit
In addition to CraftBukkit, we also now maintain Bukkit which is the API that developers can use to make server plugins. Over the years we have added many new features and changes to support newer Minecraft versions, but much of the older Bukkit documentation such as the Plugin Tutorial is still extremely relevant for developers just getting started. More information about using the API can also be found under the Spigot wiki section.

Conclusion
Now that you know a bit more about SpigotMC.org and our software we hope that you will decide to use it and become involved in our forums and chat communities. If you are ever in need of assistance, just ask in the appropriate section and one of our many members will be more than happy to assist.

Brochures / Infographics
The following brochures were produced for our booth at MINECON 2015. The numerical figures are a bit outdated (all the numbers are bigger now!), but they still provide an excellent reference for Spigot and BungeeCord.

Use the page given by /timings paste to display the output in a graphical format

Understanding timings

Minecraft's game loop runs on ticks. There are 20 ticks in 1 second, meaning that one tick should happen every 50 milliseconds. During one of these ticks, various events are processed (from game ticks such as chunks loading and players interacting with blocks), and each plugin installed on a server will handle these events a different way (for example, a plugin like WorldGuard uses a PlayerMoveEvent to make sure a player isn't where he shouldn't be).

This is where timings data becomes useful. They allow you to monitor how long it takes the plugins installed on your server to process an event. This allows you to see where lag issues arise, as a misbehaving plugin which takes a long amount to handle an event can lead to delays in the tick loop, and thus a server tick rate below 20.

Aikar's timings parser makes it easier to read timings data collected on your server. The timings report is separated into sections for each plugin. The first two sections are Minecraft's own tick events (dealing with loading/unloading entities, chunks, etc.), and the rest are divided by plugin (sorted by total time spent by plugin).

At the top of the report, there are a few general data points:

Total: The total time spent handling events.

Sample Time: The total time the server has been collecting timings data for the report.

Average Entities: The average number of activated entities, followed by the average number of total entities.

Average Players: The average amount of players logged in during the sample time.

Average TPS: The average server tick rate during the sample time.

In the headers of sections for plugins, there are two data points following the name and version:

Total: The total time spent by the plugin processing events during the sample time.

Pct: The percentage of the sample time this represents.

Each section has several columns of data per event a plugin handles:

Pct Total: The percentage of the total sample time spent processing the event.

Calculation: Total / Sample Time

Pct Tick: The percentage of a single tick (50 ms) spent processing the event.

Calculation: Avg / 50

Total: The total time spent during the sample time.

Avg: The average amount of time spent per tick.

Count: The amount of times the event was fired and handled by the plugin.

Vio: The percentage of the total violation count this plugin was responsible for.

The violation count is the number of times a timer has caused TPS loss.

Event: The name of the event.

Identifying lag

The Pct Total column is a good indicator of overall server tick rate (TPS). If a certain event takes up a large amount of time to process, it could mean that it is responsible for a sluggish server because a good amount of the game loop is spent on that one event.

The Pct Tick column is useful for identifying server lag spikes. For example, if your players complain about experiencing a large lag spike only during logon, it would be wise to examine PlayerJoinEvent timings. Seeing a large number in the Pct Tick column and a low number in the Count column could indicate that the plugin is spending a lot of a single tick processing the event, and thus causing a lag spike. Coupled with a high violations count, this would mean that the plugin is an almost definitive cause of steady, repeated lag spikes.

Examining a timings report is therefore useful to find the root cause of lag on your server. If you see a specific plugin is taking up a lot of time processing a certain event, it is a good indication that the plugin is causing your server lag. Of course, it would not be wise to immediately hassle the developer, as many other factors come into play when dealing with lag issues, such as server hardware, latency when using an external database, etc.

Contents

Firstly, you should have a name in mind already for this command. In this snippet, we will be using the example command of "/kit". However, this can be substituted with whatever command you choose to use in your own plugin.

It is recommended and more organized to create a new class for every command. Your class must implement the interface CommandExecutor. The class file may look similar to this:

Rename the parameters and fill the method body with some code. Here is the meaning of each parameter:

CommandSender represents whatever is sending the command. This could be a Player, ConsoleCommandSender, or BlockCommandSender (a command block)

Command represents what the command being called is. This will almost always be known ahead of time.

Label represents the exact first word of the command (excluding arguments) that was entered by the sender

Args is the remainder of the command statement (excluding the label) split up by spaces and put into an array.

Before giving our item(s) to a player for our example command, we need a player-object. If the command sender is a player, we can cast it. In this case, the cast will give us access to the player-object.Note: The CommandSender object passed to us in the onCommand method can sometimes be used without casting to a player first. If all you're wanting to do is send a message, checking if it's a player or not is just needlessly adding clutter to your code and making your command slightly less usable.

// If the player (or console) uses our command correct, we can return truereturntrue;}

Next, we give items to our player. In this example, we will use a diamond and twenty bricks. An item is represented by an ItemStack. So let's create a new ItemStack and the set the amount of them. Finally, we will give it to our player.

This section is dedicated to Spigot plugin developers. This guide assumes that the reader has no prior modding experience in Minecraft. Hence, the guides can/should be read in a progressive order. Experienced modders, feel free to skip ahead. Where applicable, Eclipse and IntelliJ version of each guide is shown.