Features

🕑    This wiki page is out of date,                  it may not reflect the most recent version

Below is a list of all features, organized by their respective configuration options. The configuration for Suki is the same as Paper, and can be found in:

• Global settings: config/suki-global.yml
• World settings: defaults in config/suki-world-defaults.yml, and overriding settings for a specific world can be defined in <world name>/suki-world.yml

Optimization

Suki provides many optimization options. If you would like to increase your TPS, it is recommended to start with the recommended setting values. The options that can increase your TPS the most are:

• view-distance:
  • track.max-total-chunks
  • track.per-player
  • see.max-total-chunks
  • see.per-player
  • load.per-player
• entity-ticking:
  • skipped-active-entity-ratio
• item-pickup:
  • hopper.tick-rate
• tps.oversleep

view-distance

Suki can automatically update players' view distances to get the most out of your hardware, and you can easily reach view distances of 32 using normal CPU and RAM!

The view distance in Suki is spread into 4 different view distances, from low to high:

• The simulation distance
  This is the distance at which blocks and entities (such as redstone and zombies) will receive ticks, which cause game updates. Outside of this radius, redstone will not be updated. Increasing this distance costs a lot of CPU.
  Setting this to 10 gives players a really great experience, but many servers set this to 4 or 5 to save CPU.
  The simulation distance is usually the smallest view distance (because of its high CPU cost) but is technically independent (so could be set higher) than the track and see view distance explained below.
  Suki does not change the simulation distance from Paper. You can set the simulation-distance in server.properties (for the whole server) or in spigot.yml (per world).
• The track view distance
  This is the distance at which players receive the up-to-date version of the world. Within this radius, they can see entities. If blocks change within this radius, the new blocks will instantly be sent to the player (so they can see the change happening in the distance). Outside of this radius, players do not see any entities (just blocks only), and do not receive block changes. Changes to blocks outside this distance will be sent to the player as soon as the player moves closer by and the block is closer than the track view distance.
  Increasing this distance costs a bit of CPU (because the server must process and send more updates) and some network bandwidth.
• The see view distance
  This is the distance at which players can see blocks. So if the simulation distance and track view distance are both very low, but the see view distance is very high, players can see blocks very far away. A high see view distance improves the experience for players a lot.
  A higher see view distance costs almost no CPU, but costs RAM and some network bandwidth.
  In Paper, the see view distance is equal to the track view distance. In Suki, the see view distance can be much higher (giving high view distance without high CPU usage).
  Note that the see view distance is not the same as the Paper "send view distance" concept for chunk sending, which is actually often less than the track view distance and is not relevant for Suki if the limit-by-client-view-distance options (explained below) are set to true, which is recommended.
• The load view distance
  This is the distance around players at which chunks are kept in memory.
  For technical reasons, the maximum load view distance is usually: max(simulation distance, see view distance) + 1

With Suki, you can take the following steps to have your players' view distances automatically set and continuously updated:

1. Set the simulation-distance (in server.properties (for the whole server) or in spigot.yml (per world)) to a value you want (4 is very optimized, 10 is extremely high).
2. Estimate the number of chunks your CPU can track. For example, if you currently have view-distance set at 10, and that works well with 100 players that are all spread apart, your server can track 100 * (10*2 + 1)² = 44100 chunks. I recommend staying a bit on the safe side because often players stay in the same area, so for example, then set the Suki global configuration view-distance.track.max-total-chunks to 15000 (~less than half).
   Also, set the Suki world configuration view-distance.track.max to 11 or less because higher track view distance is usually not needed: clients usually do not render entities far away anyway.
3. Estimate the number of chunks your RAM can store. For 8GB you can probably do 25000, with 16GB you can probably do 75000. Set the Suki global configuration view-distance.see.max-total-chunks to that value.
4. Set the Suki world configuration view-distance.*.per-player and view-distance.*.limit-by-*-view-distance options to true to enable Suki's automatic view distance adaptation, and prevent unnecessary loading and sending of chunks.

If in doubt, reference the details and recommended values below.

Global track.max-total-chunks

The maximum number of chunks that can be tracked by all players together. Tracking means: the player will receive entity and block updates from these chunks. A higher value costs more CPU and network bandwidth. -1 means no limit.

Default: -1
Recommended: for a server with 4 cores @ 2.0 GHz, with usually 15 players online max, 2500 works well. For 2500: if there are 15 players online, each player can track chunks at a distance of 6. If you would like 30 players to track chunks at a distance of 6, you should use 5000, etcetera.

World track.per-player

Whether track view distance is automatically optimally set for each player individually.

Default: false
Recommended: true

World track.limit-by-client-view-distance

(Only if track.per-player is true)

Whether chunks further than the client view distance will not be tracked by players. Setting this to true saves CPU and network bandwidth, without being noticeable by players.

Default: false
Recommended: true

World track.max

(Only if track.per-player is true)

The maximum chunk distance for each individual player to track. -1 means no limit.

Default: -1
Recommended: 11

Global see.max-total-chunks

The maximum number of chunks that can be seen by all players together. See distance should be much higher than tracking (which includes entities and block changes) distance. A higher value costs more RAM, and a little bit more CPU. -1 means no limit.

Default: -1
Recommended: for a server with 8GB RAM, with usually 15 players online max, 12500 works well. For 12500: if there are 15 players online, each player can see chunks at a distance of 14. If you would like 30 players to see chunks at a distance of 14, you should use 25000, etcetera.

World see.per-player

Whether see view distance is automatically optimally set for each player individually.

Default: false
Recommended: true

World see.limit-by-client-view-distance

(Only if see.per-player is true)

Whether chunks further than the client view distance will not be sent to players. Setting this to true saves network bandwidth, without being noticeable by players.

Default: false
Recommended: true

World see.max

(Only if see.per-player is true)

The maximum chunk distance for each individual player to see. -1 means no limit.

Normally, it is not necessary to change this setting, because with see.per-player, Suki will already set the view distance fairly without a limit being required.

Default: -1
Recommended: -1

World load.per-player

Whether the distance at which chunks are loaded into server memory is automatically optimally set for each player individually.

Default: false
Recommended: true

World load.limit-by-client-view-distance

(Only if load.per-player is true)

Whether chunks further than the client view distance will not be loaded into server memory. Setting this to true saves CPU and RAM. If the client sets a low view distance, this makes mob spawning higher up or lower down in their own chunks more likely, and mob spawning further away less likely.

Default: false
Recommended: true - but note that this may change mob spawning for players with very low client view distance (such as 4 or lower)

World load.limit-by-see-view-distance

(Only if load.per-player is true)

Whether chunks further than the player can receive will not be loaded into server memory. Setting this to true saves CPU and RAM.

Default: false
Recommended: true

World load.max

(Only if load.per-player is true)

The maximum chunk distance to load into server memory for each individual player. -1 means no limit.

Normally, it is not necessary to change this setting, because with load.per-player, Suki will already set the load distance fairly without a limit being required.

Default: -1
Recommended: -1

World if-can-see-but-not-tracking

Whether some chunk events will be sent to players that are too far away to see the entities in that chunk:

• send-chunk-refresh
  When plugins request to refresh the chunk for a player
  Default: true
  Recommended: false
• send-end-portal-fill-sound
  The sound when an End portal is completed
  Default: true
  Recommended: true
• send-ender-dragon-spawn-sound
  The sound when an Ender Dragon spawns
  Default: true
  Recommended: true
• send-wither-spawn-sound
  The sound when a Wither spawns
  Default: true
  Recommended: true

Global allow-invalid-client-view-distance

Whether to allow clients to send an invalid view distance. If true, clients can send a view distance above 127 (but it will have no effect). If false, clients will be kicked when they send a view distance above 127.

Default: false

entity-ticking

Entities are the most CPU-heavy for many servers.

In Paper, entities can be 'inactive'. Inactive entities are still updated every tick (to update things like how long they are on fire), but their normal behavior (such as pathfinding) is performed less frequently. Suki provides new options to prevent some entities from becoming 'inactive' (for example, a fox that just started chasing a rabbit, or a sheep that was just sheared). There are also options to skip 'active' entity ticks and wake up entities from inactivity in a smooth fashion.

World immune-from-inactive.non-sitting-pets

Whether all non-sitting pets (such as walking tamed dogs or flying parrots) are immune from being made 'inactive'. (So, if this setting is true, they will be always active.)

Default: false
Recommended: true (this prevents some cases of wolves or parrots not following players)

World immune-from-inactive.sheared-sheep

Whether sheep without wool are immune from being made 'inactive'.

Default: true
Recommended: true (this prevents sheep not regrowing wool fast enough because they are 'inactive' for a long time)

World immune-from-inactive.ticks.baby

How long (in ticks) babies should be 'active' after being born.

Default: 5
Recommended: 5

World immune-from-inactive.ticks.mob-targeting-mob

How long (in ticks) specific aggressive mobs should be when they target another specific mob (for example, a fox targeting a rabbit).

Default: 0
Recommended:

• 0 is best for performance but may make some hunting mobs appear a bit stupid
• 20 makes hunting mobs appear smarter but may cause lag if players built farms for that type of mob

World skipped-active-entity-ratio

Paper also skips some behavior for 'active' entities. By default, this is 25% of all active entities. Randomly skipping some active entities in a tick has very little impact on gameplay (since the same update will still be executed in the next tick which is only 50 milliseconds later), but it breaks some vanilla farms that require entities to be updated every tick (typically super compact farms that push armor stands with pistons, or use llamas in boats). Even if the skipped ratio is set to 0% instead of 25%, many of these specific machines will still not work, but you could try if your players complain about machines not working, and you notice they are using entities in their redstone system (typically armor stands or boats).

Increasing this value will improve TPS by a lot, but setting it too high can make mobs very nearby the player appear to be glitchy, or react a bit late to their environment.

Default: 0.25
Recommended:

• 0.0 if you want to attempt to fix some entity-ticking dependent mob farms that work in vanilla but not in Paper
• 0.25 for default Paper behavior
• A higher value if you wish to gain TPS, at the cost of entities appearing a bit glitchy or dumb: it is possible to set this value to anything strictly below 1, such as 0.75, if you want

World wake-up-duration-standard-deviation-ratio

Inactive entities are periodically waken up to an 'active' state temporarily. In Paper, many inactive entities of the same type or woken up at the same time. This can look really strange: a whole group of villagers stands still for a while and then all at the same time start walking somewhere. This option will add some variance to the time after which entities are woken up, which makes entities much more realistic and independent. A value of 0.0 means no change to Paper behavior. This value should never be set higher than 0.5.

Default: 0.0
Recommended: 0.2

Accurate async CPU usage

Suki adds environment variables that give you full control over the number of CPU cores/threads used for async tasks, such as chunk loading, entity tracking and async plugin tasks. They should be added to your current script to start the server, with the prefix -D.

For example, if your current script is java -Xms10G -Xmx10G -jar server.jar, and you wish to add the variable suki.threads.asyncexecutor with value 3, replace the script line with: java -Xms10G -Xmx10G -Dsuki.threads.asyncexecutor=3 -jar server.jar

Setting these environment variables to their recommended values is highly recommended.

Note that the recommended setting depends on the number of CPU cores and CPU threads you have. These numbers may be different. For example:

CPU	Number of CPU cores	Number of CPU threads
AMD Ryzen 7 5800X	6	12
Oracle Cloud free tier Ampere instance	4	4

The environment variables to set:

• suki.threads.asyncexecutor
  The number of threads used by the async task executor.
  Default: 2
  Recommended: <number of CPU cores> - 2
• suki.threads.tracker
  The number of threads used by the async entity tracker.
  Default: 4
  Recommended: <number of CPU cores>
• suki.threads.upgradeworld
  The number of threads used to upgrade chunks from older versions.
  Default: <number of CPU threads> * ⅜
  Recommended: at least 1, if you have 5 or less CPU cores: 2, if you have 6+ CPU cores: floor(<number of CPU cores> / 2)
• suki.threads.levelexecutor
  The number of threads to execute tasks on when a chunk is loaded for a world, or -1 to disable this feature.
  Default: -1
  Recommended: -1 (using this feature is risky: it can cause large TPS spikes when players join or teleport)

In addition to these environment variables, it is also strongly recommended to set chunk-system.worker-threads in paper-global.yml to floor(<number of CPU cores> / 2). For example, if you have 8 CPU cores and 8 CPU threads, set it to 4. If this value is -1 (which is the default), Paper will assume the value floor(<number of CPU threads> / 4) which is okay if you have 2 threads per core, but will seriously hurt performance if you have only 1 thread per core.

item-pickup

Hoppers picking up items is intensive for the server, so it is helpful to decrease the frequency at which the necessary checks are performed. This barely affects gameplay in any way, and doensn't break mob farms or redstone machines unless they rely on tick-precise floating item pickups of hoppers (I have never seen such a farm or machine because they would probably not work in vanilla either).

World hopper.tick-rate

How often (in ticks) to tick hoppers to pick up floating items. This does not affect hoppers pulling items from container such as chests or other hoppers: it only affects floating items lying on top of them. A higher value can increase TPS if there are a lot of open hoppers (hoppers without a block above them) on the server, because all hoppers that are open on the top will constantly check for floating items (even if there are no items nearby).

Default: 1
Recommended: 20 (once every second)

World hopper.minecart-immunity.duration

For how long (in ticks) hopper minecarts can ignore hopper.tick-rate and pick up items every tick, after items are detected nearby. -1 disables these extra pickups for hopper minecarts.

Default: 200
Recommended: 200

World hopper.minecart-immunity.detection

Settings for the detection of dropped items around hopper minecarts to give them temporary immunity from hopper.tick-rate (see hopper.minecart-immunity.duration).

• horizontal-distance
  Max horizontal distance to check for items
  Default: 32.0
  Recommended: 32.0
• vertical-distance
  Max vertical distance to check for items
  Default: 4.0
  Recommended: 4.0
• max-age
  Max age (in ticks) of a hopper minecart to gain temporary item pickup limit immunity (-1 means no age limit)
  Default: 1200
  Recommended: 1200
• tick-rate
  How often (in ticks) to check for items nearby
  Default: 20 (once every second)
  Recommended: 20

World villager.delay-after-drop

For how long (in ticks) items dropped by villagers cannot be picked up. When a villager's inventory is full, they will drop some of their items on the ground, particularly to pass them to other villagers (in the case of farmers). This can lead to multiple villagers constantly throwing food at each other in a villager breeding farm. If this value is -1, the vanilla value (which is currently 10) is used.

Default: -1
Recommended: 100 (5 seconds)

lootables

World only-refresh-for-players

Whether to only refresh lootables (such as naturally generated chests) when the contents are checked by a player.

Default: false
Recommended: true

tps.oversleep

After a tick has been executed, the server takes some time to perform scheduled tasks that must happen on the main thread, for example calling plugin events after a chunk has been loaded. This is called 'oversleep'. By default, this can take 50 milliseconds (exactly the length of 1 full tick) from the end of the last tick. If too many tasks are scheduled, and this time is used in full, and the regular tick is also fully used, then the TPS may be reduced to 10 (because half the time is spent on the ticks themselves, and half the time is spent in oversleep). Suki provides configuration to limit the length of the oversleep. Limiting the length of oversleep gives more stable TPS, but some (important) tasks may be delayed for a long time (leading to slow chunk loading, for example).

Global planned-after-last-tick-end

The minimum amount of time (in milliseconds) planned to be spent on such tasks. If this value is set to -1, the vanilla default (50 milliseconds) is used. If your timings report shows a large amount of "Server Oversleep", you can consider lowering this value. You should usually not increase this value above 50.

Default: -1
Recommended: -1 is okay, but if you have a large % of "Server Oversleep" in timings you can try a value between 0 and 50, where 30 is a reasonable value to start with

Global max-after-next-tick-start

The maximum amount of time (in milliseconds) the oversleep tasks can delay the start of the next tick. If this value is set to -1, the vanilla default (no limit) is used. If your timings report shows a large amount of "Server Oversleep", you can consider lowering this value. Note that if this value is larger than planned-after-last-tick-end, it has no effect.

Default: -1
Recommended: -1 is okay, but if you have a large % of "Server Oversleep" in timings you can try a value between 0 and 50, where 20 is a reasonable value to start with

network-constrained-chunk-sending

Chunk packets will be interweaved with non-chunk packets to provide a smooth game experience even if the network capacity (of either the server or client) is limited, or if the client's CPU, GPU or RAM loads/renders chunks slowly. This system fully replaces the vanilla packet sending (which is: send all packets in order regardless of type), and cannot be completely turned off.

World max-chunk-packets-in-transit.target-player-chunk-send-rate-margin-factor

The Paper configuration setting chunk-loading.target-player-chunk-send-rate will be multiplied by this value to get a target estimation for the network-constrained chunk sending. A higher value means chunks are sent sooner, meaning faster chunk loading, but a higher chance of overloading the network capacity.

Default: 1.15
Recommended: recommended to keep at 1.15, but can be changed to between 1.0 (mostly helps clients with bad computer specs or bad connections) and 1.5 (mostly helps clients with good computer specs and connections but high ping - such as on the other side of the world)

Global assume-packets-in-transit-arrived-after-time

Packets will be assumed to have arrived after this time in milliseconds, even if no response has been received.

Default: 600
Recommended: the highest ping that you expect your players to normally have - but 600 is a reasonably good guess for most servers

Global ignore-network-conditions-for-chunks-within-chessboard-distance

Chunk packets within this distance of the player will always be instantly sent like vanilla, without being placed in a queue behind non-chunk packets. A value of -1 means all chunk packets are potentially queued behind non-chunk packets.

Default: 1
Recommended: 1 is a good default setting, -1 if your players have very bad computer specs and get screen freeze when teleporting, 2 if your players have good computer specs

prevent-block-update-client-lag

World enabled

Too many block updates (which can be caused by big machines with many pistons, for example) can cause the client FPS to drop due to the CPU and GPU not being able to keep up with loading and rendering the new block states. If this setting is true, large amounts of block update packets will be spread over time, and some duplicate block update packets will not be sent. This helps players with bad clients who get FPS drops when near to piston redstone machines. This feature is not perfect, and ghost blocks can appear if too many pistons push and pull a piston that is pointed in a different direction.

Default: false
Recommended: false

Gameplay

signed-chat

Global enabled

Whether signed chat can be used. If false, everything related to message signing and message reporting is disabled (all messages are sent to the client using system chat).

Default: true
Recommended: true if you wish players to be able to report messages to Microsoft, false if you wish to disable reports to Microsoft

Global if-disabled.hide-insecure-popup

When signed chat is disabled, the client will show a popup message warning the player. Setting this option to true will remove this popup.

Default: true

Global if-disabled.use-chat-preview

When signed chat is disabled, chat preview will indicate to the player that their messages will not be signed. Setting this option to false will also disable chat preview when signed chat is disabled. This does not affect using the tab key for command completion.

Default: false

Place items directly into head slot

With Suki, players can place banners and other items/blocks can be directly into the head slot to wear them.

Permission	Description	Default
suki.moreitemsonhead.banner	Place banners directly into the head slot	false
suki.moreitemsonhead.all	Place any item/block directly into the head slot	false

difficulty-changes

World cave-spiders-have-poison-on-easy-difficulty

Normally cave spiders inflict poison on Normal and Hard difficulties. If this setting is true, they also inflict poison on Easy difficulty.

Default: false

World lightning-spawns-fire

Normally lightning can create fire when it strikes (on every difficulty). If this setting is false, lightning strikes will not create fire.

Default: true

World minimum-health-after-starving

If a player is starving (has an empty hunger bar), they will lose health until they reach a certain minimum. The minimum depends on the game difficulty. This setting will override the vanilla minimum health. For example, a value of 10.0 means that players will not lose health because of starving when they have 5 hearts or less (1 heart = 2.0 health). A value of -1.0 means the vanilla difficulty-based value is used.

Default: -1.0

World players-share-villager-gossips.positive.always

Players can gain a reputation from villagers in several ways. Curing a zombie villager gives the player a positive reputation, which gives the player discounts. If this setting is true, the discounts also apply to other players: so if player A cures a zombie villager, player B can also use the discounts afterwards. This is useful on survival servers where players team together.

Default: false Recommended: true for friendly survival servers, false otherwise

World raids-are-always-hard

If this setting is true, all raids will have waves as if the game difficulty was set to Hard. This means that even if the difficulty is Easy or Normal, raids will always have more enemies and include evokers. This is useful for enabling raid farms on a server that is on Easy difficulty.

Default: false

World spiders-with-effects-on-all-difficulties

Spiders can spawn with potion effects on Hard difficulty. If this setting is true, spiders can also spawn with potion effects on Easy and Normal difficulty.

Default: false

World villager-reputation-changes

Villager reputation changes when a player interacts with a villager or something around it. A positive reputation lowers prices, and a negative reputation increases prices. The following settings determine how much a player's positive, negative or 'trading' (a category for temporary discounts after trading) reputation changes from certain events.

• cured
  The reputation change when curing a zombie villager
  • major-positive
    Permanent positive reputation gain
    Default: 20
  • minor-positive
    Temporary positive reputation gain
    Default: 25
• trading.trading
  The very temporary positive reputation gain when trading with a villager
  Default: 2
• villager-hurt
  The reputation change when inflicting damage onto a villager
  • major-negative
    Permanent negative reputation gain
    Default: 0
  • minor-negative
    Temporary negative reputation gain
    Default: 25
• villager-killed
  The reputation change when killing a villager
  • major-negative
    Permanent negative reputation gain
    Default: 25
  • minor-negative
    Temporary negative reputation gain
    Default: 0

World wither-effect-from-wither-skulls-on-easy-difficulty

Wither skulls inflict the wither potion effect on Normal and Hard difficulties. If this setting is true, wither skulls also inflict the wither potion effect on Easy difficulty.

Default: false

World zombie-reinforcements-on-all-difficulties

Zombies can call for reinforcements on Normal and Hard difficulties. This means that a zombie being attacked causing multiple new zombies to spawn somewhere nearby. If this setting is true, zombies can also call for reinforcements on Easy difficulty.

Default: false

survival-debug-stick

Suki adds the ability for players to use a debug stick in survival mode. This only works for a limited number of block properties that are compatible with survival mode, such as changing the visual lit state of a furnace or the rotation of logs or stairs.

Permission	Description	Default
suki.debugstick.survival	Use a debug stick in survival mode	false

Global switch-property-timeout

Timeout (in milliseconds) between changing the block property being edited when left-clicking with the debug stick.

Default: 300
Recommended: 300

break-blocks-in-survival

World barrier-if-holding-barrier

Whether players in survival mode can break barrier blocks if they are already holding a barrier block in their hand.

Default: false

World light-if-holding-light

Whether players in survival mode can break light blocks if they are already holding a light block in their hand.

Default: false

enchantability

With these options, some extra enchantment combinations can be allowed. They can be found in the Global settings file.

Default: false

bone-meal-regrows-bark

World enabled

If this setting is true, stripped logs and wood can be unstripped by using bone meal on them.

Default: false

World bone-meal-is-used-up-chance

(Only if enabled is true)

The probability that the bone meal item is used up when a log is unstripped.

Default: 1.0
Recommended: I personally find 1.0 a bit too expensive, and to promote decoration, I use 0.125 (and if you want to make it free to unstrip logs, you can use 0.0)

mob-spawning

World all-nether-bricks-count-as-fortress

If true, mobs that normally only spawn in Nether fortresses can spawn on Nether bricks anywhere in the Nether.

Default: false

never-despawn-entities-due-to-distance

World wither

If true, a Wither will never despawn just because all players are far away.

Default: false

Other

console-logs

Global change-invalid-pool-element-level-to-info

Whether invalid structure pool element errors are logged using the INFO log level instead of the SEVERE log level. Since these errors cannot usually be solved anyway, it does not make sense to print them to the console in a red color every time.

Default: false
Recommended: true

Global chat-messages.empty

Whether clients sending empty chat messages is logged to the console. Empty chat messages may be caused by clients using different version (such as when using plugins like ViaVersion, ProtocolSupport or Geyser).

Default: true
Recommended: false

Global chat-messages.not-secure

Whether clients sending unsigned chat messages is logged to the console.

Default: true
Recommended: false

Global invalid-client-view-distance

Whether clients sending view distances higher than 127 is logged to the console.

Default: true

Global invalid-statistics

Whether invalid player statistics are logged to the console.

Default: true
Recommended: false

Global login-protocol

Whether steps of the login protocol are logged to the console. This is only for plugin development purposes.

• packets.handshake
  The serverbound Handshake packet
  Default: false
• packets.login-start
  The serverbound Login Start packet
  Default: false
• packets.set-compression
  The clientbound Set Compression packet
  Default: false

Global move-checks

Whether players failing move checks is logged to the console.

• too-quickly.self
  The <player> moved too quickly check
  Default: true
• too-quickly.vehicle
  The Vehicle of <player> moved too quickly check
  Default: true
• wrongly.self
  The <player> moved wrongly check
  Default: true
• wrongly.vehicle
  The Vehicle of <player> moved wrongly check
  Default: true

hide-game-modes

Global replacement

The server sends the game mode of every player to all players, including whether they are in creative or spectator mode. You may not want other players to know this if you use creative or spectator mode for moderation purposes. This setting can be used to send a fake game mode instead of the real one. If it is set to survival, for example, players will no longer see the italic gray color in the tab list for players who are in spectator mode. If this setting is set to survival, the player game mode packet for other players will always be marked "survival".

Default: none
Recommended: none to disable this feature, or survival if you wish to hide that you use creative or spectator mode for moderation purposes
Possible values:

• survival
• creative
• adventure
• spectator
• none (if the replacement value is none, this feature is disabled, and all players receive all real game modes)

Permission	Description	Default
suki.seerealgamemodes	Players with this permission can always see all real game modes of other players	op

interaction-distance

World max

The maximum distance that players can reach for interactions. Increasing this value may allow hackers to reach further-away objects, but helps players with bad connections. For example, in vanilla, if a player with lag tries to place a block while moving, the server may cancel the block placement because according to the server the player is already too far away.

Default: 6.0
Recommended: 6.0 (vanilla) or slightly higher (such as 7.5) if players fail to place/break blocks while moving due to lag

keepalive

Global send-interval

How often (in milliseconds) to send a Keep Alive packet.

Default: 15000
Recommended: 3000

Global kick-player-for

Whether to kick players for failing to respond to a Keep Alive packet correctly. Setting these to false will prevent players that have unstable or bad connections from getting suddenly Timed out for seemingly no reason.

• late-response
  Whether to kick players for responding to a Keep Alive packet too late
  Default: true
  Recommended: false
• unexpected-response
  Whether to kick players for sending a Keep Alive response when none was expected
  Default: true
  Recommended: false
• wrong-response-id
  Whether to kick players for sending a Keep Alive response with the wrong id
  Default: true
  Recommended: false

login-protocol

Global slow-login-timeout

How long (in milliseconds) the server will wait for clients to prove their authentication status. This is only used if online-mode = true in server.properties.

Default: 600
Recommended: 600 is good starting value, it can be increased if some of your players are getting a Took too long to log in error

move-checks

World too-quickly.self

Whether the vanilla <player> moved too quickly check is enabled.

Default: true

World too-quickly.vehicle

Whether the vanilla Vehicle of <player> moved too quickly check is enabled.

Default: true

World wrongly.self

Whether the vanilla <player> moved wrongly check is enabled.

Default: true

World wrongly.vehicle

Whether the vanilla Vehicle of <player> moved wrongly check is enabled.

Default: true

plugins

Global hide-if-no-permission

Whether to hide plugins from players (in /plugins, /version and /help) if they do not have permission.

Default: false

Permission	Description	Default
suki.seeplugin.<lowercase alphanumeric plugin name>	The permission to see a plugin (for example, the permission to see a plugin called Remove5%OfEntities would be suki.seeplugin.remove5ofentities)	op
suki.seeplugin.*	See all plugins	op

Global show-legacy-asterisk

Whether to show an asterisk (*) in the /plugins list after legacy (old) plugins.

Default: true

relocate-corrupted-chunks

World enabled

Whether chunks are relocated when data corruption is detected. This is true in Paper. Setting this to false prevents staggered terrain after data corruption.

Default: true
Recommended: false