-
-
Notifications
You must be signed in to change notification settings - Fork 183
Config
Don't touch this.
Delays chunk unloads by the specified time (in seconds).
Option to determine whether block breaking is impacted by TPS. In vanilla, block breaking is determined by server TPS - if the TPS is lower, then block breaking takes longer. However, the client thinks block breaking proceeds at 20tps, so this can cause disagreements with the server on whether a block was broken or not. Lag compensation fixes this by moving the server's checks to use time rather than ticks.
packet-limiter:
kick-message: '&cSent too many packets'
limits:
all:
interval: 7.0
max-packet-rate: 500.0
PacketPlayInAutoRecipe:
interval: 4.0
max-packet-rate: 5.0
action: DROP
The all section refers to all incoming packets. This section cannot have
an action defined, it is always set to kick the player when the limit is violated.
If interval or max-packet-rate is less-than 0, the limit is disabled.
Specific packet limits have the section name as the packet's name. These can be obtained from timings.
Each specific limit can be set with an action to DROP packets above the limit or to KICK the player.
If the action setting is missing, then it defaults to KICK.
If interval or max-packet-rate is less-than 0, the limit is disabled.
PacketPlayInAutoRecipe is in the default config due to how expensive the packet handling is for this packet - this config option effectively patches the auto recipe server crash exploit.
Option to use the Starlight light engine. Disabling it can be useful for debugging purposes or for compatibility with some plugins that might expect the Vanilla light engine.
Some collisions, namely those with Boats and Minecarts, are subject to client/server desync. For example, sometimes while standing on a boat the player will be constantly teleported around. A lot of these problems can be solved by sending the precise entity location to clients, which is what this option does when enabled. There can be some rare cases where the bandwidth tradeoff is not worth it, so only then should you set this to false.
The radius of chunks to try and load around a player un-throttled. Basically, this radius is not affected by the max-concurrent-loads setting.
The maximum number of chunks the server can have queued in the packet I/O threads. A higher value is going to ensure chunks are being sent at very low tps, however a lower value will reduce ping impact from chunks (it will not eliminate it). If this value is negative, then it is scaled with players. i.e -15 at 20 players = 15*20
The maximum number of chunks the server can have queued to load or generate. A higher value will keep chunks loading, and a lower value will improve chunk loading response when flying around. If this value is negative, then it is scaled with players. i.e -6 at 20 players = 6*20
Whether to automatically configure the sending view distance for players based on their client view distance. For example, if the server has a view distance of 10 and a client has a view distance of 5, the server will only send enough chunks to fill up the 5 view distance.
Enables the workaround for https://bugs.mojang.com/browse/MC-162253. The workaround sends a lot more lighting data with each packet, so in some cases it might cause problems for people. However you should carefully look at server bandwidth to determine whether this is a problem, and look at reducing things like target-chunk-send-rate first - most players do not appear to have client side mods like phosphor or starlight that fix mc162253.
The target chunk send rate. The server wont exceed this rate when sending chunks to players. This option is mainly going to affect peak bandwidth. If this value is negative, then it is scaled with players. i.e -100 at 20 players = 100*20
Whether to try and load chunks first in the player's viewing frustum (where they're looking) before other chunks in their view distance radius. This option is disabled by default because the client does not like this happening at all, and can cause weird problems where chunks don't appear to load in client side.
Config keys are generated only for the default world settings (world-settings.default). World specific sections are generated, but are left empty - if you want to override the setting for a specific world, copy the setting from the default settings to the specific world section.
Default: These are no longer generated in the tuinity.yml, as paper has per-world limits now in its paper.yml. However to accommodate legacy configs, they are still read from config. The values, if present, will take precedence over paper.yml.
Identical to bukkit.yml except these are per world. All values default to -1, indicating that bukkit.yml's values should be used.