The configuration file is located in plugins/ViaVersion/config.yml. It uses the YAML Syntax. The config is split into sections, you can see these by looking at the comments prefixed with #.
A quick reminder on YAML:
- Boolean means it can either be
false, (true being on and false being off).
- String means that it is a sentence or words surrounded by
"", for example
message: "Hello world!"
- Integer means that it is a number, for example:
- Integer List means that it can be empty,
 orhave as many values as desired,
[10, 20, 30]
A common mistake when using .yml (YAML) is using the tab key, ensure that you use spaces instead.
A recommended editor for Windows is Notepad++.
These options effect all versions, even when it isn't being handled by ViaVersion.
checkforupdates - default: true (Boolean)
This option indicates whether we should check for updates when the server boots and when an operator logs in, this can be a huge benefit to ensure that bugs are fixed as soon as new versions are available. We use spiget.org to handle checking for updates, so ensure that it is allowed through your firewall if you wish to use this feature.
send-supported-versions - default: false (Boolean)
When a client sends a ping request to your server, for example viewing the Minecraft server list should we send extra information telling them what versions are supported? We suggest only using this if you use some third party software to handle what servers a client can connect to.
block-protocols - default:  (Integer List)
This allows you to block certain versions from logging into your server, every Minecraft version has a special number assigned to it called a Protocol Version. You can view a list of them here. For example, if you wanted to block 1.10 Minecraft you can see from that list that the number is 210. You would then change your config to,
block-protocols: , you can then add as many protocols as required separated by a comma if you wish to block more.
block-disconnect-msg - default: "You are using an unsupported Minecraft version!" (String)
When the condition above for blocking a certain version is met, what should the client be kicked with? This message will appear on their disconnect screen when they are kicked for using a blocked version. You can use Minecraft Colour codes here.
Global Packet Limiter Options
When building ViaVersion we came across a lot of issues with exploits where people could send lots of packets and crash a server (Just as a general Minecraft fault). To combat this we included a simple packet limiting system, which should work out of the box.
If you don't want packet limiting, set
max-pps to -1 and
tracking-period to -1.
Maximum based limiting
A simple way to protect your server is to set a maximum packets per second, this way if a malicious client sends too many attempting to overload your server they are disconnected.
max-pps - default: 600 (Integer)
This is how many packets the client can send in 1 second, using the value of -1 will disable this. From research the most intensive task in Minecraft is fishing while being in a boat where we've observed averages of 90-100 pps. Though after lagging from something like a resource pack download this can exceed this to about 400.
max-pps-kick-msg - default: "You are sending too many packets!" (String)
When a player sends more than the limit above what should the kick message be. You can use Minecraft Colour codes here, as well as %pps which will be replaced with their current packets per second.
Monitoring packets over a period of time
Although maximum packets per second is nice, in cases where it's valid to send lots of packets (For example: Having latency after logging in and sending lots to catch up in a second). Monitoring them over a period allows you to punish players who go over a number of packets per second several times over the period.
tracking-period - default: 6 (Integer)
This is measured in seconds and represents how long one tracking period is, every x seconds it will check how many seconds the client has been over the
tracking-warning-pps. You can set this to -1 to disable limiting based on periods of time.
tracking-warning-pps - default: 120 (Integer)
How many packets per second should be counted as a warning, you should set this as a value you would not expect an average client to obtain.
tracking-max-warnings - default: 4 (Integer)
Over the tracking period how many warnings is the client allowed to have before being kicked, usually you want it so that on average they are sending more packets than normal. The maximum value for this is
For example if you have
tracking-period of 6,
tracking-warning-pps of 120 and
tracking-max-warnings of 4: If a client sends 120 packets or more for 4 seconds out of 6 seconds they will be kicked.
tracking-max-pps-kick-msg - default: "You are sending too many packets!" (String)
When the player gets more warnings over the time period than allowed and kicks them, what shall the message be. You can use Minecraft Colour codes here, as well as %pps which will be replaced with their current packets per second.
1.9 & 1.10 clients on 1.8 servers options
This options only apply to you if you use a 1.8 server, these help enable consistent visuals / gameplays across future versions where features have changed.
prevent-collision - default: true (Boolean)
In 1.9, players can now push each other. To prevent this when scoreboard teams are sent ViaVersion can set the collision to not happen so that the gameplay is balanced. (Plugins like ColoredTags use teams)
auto-team - default: true (Boolean)
Most servers don't use scoreboard plugins, in this case we send our own team to the player to prevent them colliding with other players. If you use a plugin like ColoredTags you should turn this off. Furthermore if you are having issues with Bungee and teams, consider turning it off too.
suppress-metadata-errors - default: false (Boolean)
Due to changes in 1.9 and above to how entity data is sent some plugins send data that we can't find the 1.9 equivalent for (Usually means they're doing something wrong!). When this happens we'll tell you all the info in your config and you will need to debug and work out which plugin is causing this and contact the author, (these are related to the NMS class called Datawatcher).
Alternatively you can just suppress metadata errors but this means mobs may look different on 1.9 to 1.8, but most of the time this is fine.
shield-blocking - default: true (Boolean)
In 1.9, the blocking animation when you right click a sword was removed. It's not possible to simulate meaning 1.9 would not be able to see 1.8 blocking, as an alternative you can visually see these as shields. These do not change any game play and just allow 1.9 to see clients blocking and perform the blocking action with a sword themselves.
Disabling this will mean that 1.9 clients will not be able to see players blocking and will not be able to block properly.
hologram-patch - default: false (Boolean)
In 1.9, certain height values for holograms were modified. If you used Armour Stands manually on your server this may not concern you but if you use a plugin such as Holographic Displays then your armour stands may appear higher than they should be to 1.9 and above clients. To fix this you can enable this option.
hologram-y - default: -0.96 (Integer)
hologram-patch above is true, how much should be offset the hologram to 1.9 and above clients by. Our experiments shows -0.96 works the best.
simulate-pt - default: true (Boolean)
In 1.9, the player ticking is no longer triggered by the client sending packets. Therefor if we don't simulate sending them packets they won't be able to eat, use bows properly, drink potions. If you have a really simple server you can disable this but it's suggested that you do not.
nms-player-ticking - default: true (Boolean)
To simulate player ticking we use NMS as an alternative to sending packets as sending packets can cause issues with anti-cheats. If you are experiencing TPS issues with ViaVersion it's suggested you try with this to false as it may reduce CPU workload.
bossbar-patch - default: true (Boolean)
In 1.9 bossbars are handled differently and sent via packets rather than using a mob. Should we automatically send the right packets to enable bossbars to work? You can disable this if you're having issues with too many boss bars appearing.
bossbar-anti-flicker - default: false (Boolean)
Due to the change in bossbars some plugins constantly update the health on the boss bar which may cause flickering, enabling this option will fix the health. However this will prevent the health from moving down and is not recommended unless you're having flickering issues.
use-new-effect-indicator - default: true (Boolean)
In 1.9, a new effect indicator was introduced in the top left of the screen. Enabling this option will allow players to see their active potion effects in the top left, this may be an advantage to 1.9+ players and you may wish to disable if you find this so.
use-new-deathmessages - default: false (Boolean)
In 1.9, death messages were added to the respawn screen. Enabling this option will allow players who died to see their death message on the respawn screen.
item-cache - default: true (Boolean)
In 1.9, packet changes to how items are used means that they aren't sent to the server. Item cache allows ViaVersion to save what items players are holding, this allows an efficient way of telling the server what items the player is using where it has been removed. Disabling this is not suggested as the alternative is looking up the item as the packet arrives which can cause latency and possibly lead to crashing a server.
anti-xray-patch - default: true (Boolean)
Due to the way ViaVersion works to convert chunks to the new chunks for 1.9, anti-xray may not function properly. This option only works with Spigot anti-xray, and will be forcefully disabled if you do not use Spigot (So don't worry). If you don't use anti-xray with spigot you can disable this function for a slight performance boost.
replace-pistons - default: false (Boolean)
This option also effects 1.9/1.9.1 servers. In 1.10.1, Mojang introduced a way to ensure special blocks had data sent. This also introduced a crashing issue which meant when block 36 (extending piston special block) was sent it would crash the client. As a fail safe you can enable this option and we'll send the replacement id specified below instead. (This issue would only effect you if you use the special block 36)
replacement-piston-id - default: 0 (Integer)
When the previous option is enabled what block id should be sent instead, by default it is air 0 as block 36 is very similar to air.
force-json-transform - default: false (Boolean)
When an issue happens when sending json, should we forcefully still send it instead of throwing an error? This may cause incorrect json to be sent on rare occasions and disabling it will show the responsible errors.