lazy-pregen is rather simple to use.

Within this documentation, the terms "radius" and "chunks" refer to an area
generated by the server wrapper **within all dimensions**. Running
lazy-pregen will cause the overworld, nether, and end to be generated up to
the given radius. The `save-all flush` command is invoked every 512 chunks
generated per dimension, so in truth it is every 1536 chunks generated
across the whole save file.

This command comes with support for configuration in LazyPregen.toml with
the following default settings:

```toml
# The radius in blocks to generate out to.
radius = 5000

# The amount of memory in megabytes to allocate to the server.
memory = 2048

[resources]

# The command used to invoke Java.
java = "java"

# The Minecraft Server JAR file.
server = "./server.jar"
```

On initial start up of lazy-pregen, if there is no LazyPregen.toml file, it
will be automatically generated and these default settings will be used. If
this is undesirable, please manually create the LazyPregen.toml file.

Also, lazy-pregen reads and writes to the LazyPregen.lock file with a
a serialized chunk radius and index within an imaginary ring at that radius,
every 512 chunks generated (if the server accepts a `save-all flush` command
and runs it successfully). In other words, if you stop the server wrapper to,
for example, to adjust the configuration, it will not attempt to regenerate the
whole world.

Finally, note that lazy-pregen does not really think about the
server.properties or the state of the world. It is recommended to change
`max-tick-time` to `-1` (to disable crashes based on a tick taking too
long), `server-port` to `0` (to randomize the port and make the server
practically inaccessible), disable the ingame gamerules `doDaylightCycle`
and `doWeatherCycle`, and set the ingame gamerule `randomTickSpeed` to 0.
These changes can all be reverted once you are ready to use the world in
either singleplayer or multiplayer.

In the case of a bug with either lazy-pregen or Minecraft Server wherein one
of the processes crash, lazy-pregen is unable to ensure that chunks it
generated since the last write to LazyPregen.lock were saved. Fortunately,
the overhead caused by attempting to generate chunks that are already
generated is very low, especially since the lock file is updated every 512
chunks.

One bug with Minecraft Server 1.13 was discovered during the testing of this
program:

- There is a memory leak of some sort likely involving the world generator.
After about an hour of pregeneration, no matter the memory setting, the
server process and with it the wrapper will crash due to a Java out of
memory exception. To counter this bug, write a simple shell script that
restarts lazy-pregen if it exits with a non-zero exit code.

The author also knows of two bugs with lazy-pregen that might be noticeable
but should not cause any major issues:

- lazy-pregen does not properly handle the interrupt signal (sent via
Ctrl+C). It will exit with an error and will backtrack next time it runs.
There is not really a way to counter this unless the bug is fixed, however
as far as the author is aware hitting Ctrl+C is essentially the same as
running the `stop` command, which should save the progress. As stated
above, attempting to regenerate existing chunks has very low overhead.
- lazy-pregen, on full completion of pregeneration, may exit with an error
for an unknown reason. If this occurs, do not worry, the world is complete
and ready to go. To verify this, invoke lazy-pregen again and see that it
says there is nothing to do.