-
Notifications
You must be signed in to change notification settings - Fork 64
System Properties
Chunky has a handful of system properties that can be set when you start your server, allowing for more advanced configuration.
In particular, these are mostly used in places where a configuration option is not desirable, as it may unnecessarily confuse users, or expose behavior that can result in the server being more prone to crashing, or cause other issues.
As such, caution is advised when using these properties. If you do not understand what it does, do not use it.
System properties are set when the server is started. You will need to adjust the start command, which may be inside a .bat or .sh file, or listed somewhere in your server panel if you are using a host. It is worth noting that some hosts do not permit modifying the start command; many of these hosts allow you to set system properties elsewhere separately.
Your start command may look something like the following:
java -jar server.jarOftentimes there will be a lot more here, but that does not matter. Simply put your system properties before the -jar part of the command.
When you are done, it should look something like this:
java -Dchunky.example=true -jar server.jarNote that chunky.example is not a real system property used by chunky. A list of valid properties is provided below.
chunky.maxWorkingCount
Default: 50
Description: The maximum number of chunks that may be processed at any given time by chunky. Normally this does not need to be changed, as the default value has been selected for best efficiency and stability. Decreasing the value too much can potentially throttle generation, and increasing the value too much can potentially cause instability while generating or even crash the server.
chunky.sampleInterval
Default: 30
Description: This controls how long the sample interval is in seconds for rolling average rate and ETA calculations. A shorter interval means that changes to the rate and ETA will be reflected much faster, but will overall be less accurate, while a longer interval means changes are reflected more slowly, but more likely to be accurate. In general, a shorter interval is recommended for servers that experience a lot of flux in generation or are prone to crashing, and a longer interval is recommended for servers that run stable and may provide a more accurate ETA than the default. It may also be necessary to change this in combination with other properties if the default sample interval is not long enough.
chunky.tickingLoadDuration
Default: 0
Description: The number of seconds to tick chunks after generating, before unloading them. By default, chunks are generated and loaded at a level where they are never ticked, before immediately unloading. This is generally ideal as it leaves the world in an untouched state. However, it can be desirable to allow chunks to tick, for example to induce chunk post processing, which includes things such as settling fluids. Care should be taken when setting this as larger values may result in too many chunks being ticked, potentially causing the server to slow to a crawl or outright crash.
chunky.updateChunkNbt
Default: false
Description: Whether chunky should check chunk status in a way that induces chunk data upgrades (DFU). This can be useful for upgrading pre-generated worlds on version updates, but is generally not necessary as part of the pre-generation process and can usually be skipped which can be faster.
chunky.awaitTicketRemoval
Default: false
Description: Whether chunky should wait for its own chunk tickets to be removed before considering a chunk processed. This can be used along with the ticking load duration property in order to avoid a runaway number of chunks being ticked, at the cost of generation being much slower, especially when considering the default working count (e.g. a ticking load duration of 10 seconds for working on 50 chunks would be a maximum rate of 5 cps).