Firstly, most importantly, improves the heuristic used for deciding
which chunks to mesh (which matters more even at low view distances
with meshing being so expensive now, but has an even more obvious
improvement at large view distances). Essentially, instead of always
prioritizing whatever chunk was fetched earliest from the server,
instead we prioritize chunks *closest* to the player first, then chunk
order.
This greatly improves the apparent latency for things like
picking up a sprite, as well as cases where the player moves out of the
loaded range but (due to slow loading from the server or a large VD
range) there are many remaining chunks left to be meshed still within
the VD but nowhere near the player. By properly priotizing chunks near
the player, we minimize the time / likelihood of a player being on or
very near an unmeshed chunk, and make high VDs and faster travel
speeds more viable.
We make a few other minor improvements as well:
Avoid duplicate meshing of neighbors when first inserting chunks, if
they are already in the todo list and the chunk being inserted was not
directly modified.
Also avoid remeshing neighbors if only a solid block's color changed,
which could sometimes be useful for non-sprite modifications (for
example flame-induced changes to non-destructible terrain color).
The previous fix accidentally caused meshing to not perform an update if
a chunk was already actively meshing; this change fixes this behavior to
go back to the old behavior. It also fixes a subtle bug where sprites
would be using old lighting if a chunk was being actively meshed on the
same tick that a sprite change happened (this should only affect things
in a handful of circumstances and could be avoided if, e.g., only color
was changing, but this can be addressed better at another time).
This results in an extremely visually noticeable improvement in latency
when adding or removing sprite data and makes the game feel more
responsive.
This happens, for instance, when picking up a sprite like an apple or
flower from the environment. We check to make sure that for items
with lighting (like Velorite) or changes that otherwise affect meshing
(like changing from fluid to nonfluid) this doesn't trigger.
Server:
provide a certificate file and key file via the settings. When provided it will then listen on TCP and QUIC, if not provided it will be TCP only.
The certificate must be known by the client, so you might get problems with self-signed certificates.
```ron
quic_files: Some((
cert: "/home/user/veloren_cert.pem",
key: "/home/user/veloren_key.key",
)),
```
Client:
activate the voxygen settin `use_quic: true` to try to connect to the quic backend of a server.
The security model has been updated to reflect this change (for example,
moderators cannot revert a ban by an administrator). Ban history is
also now recorded in the ban file, and much more information about the
ban is stored (whitelists and administrators also have extra
information).
To support the new information without losing important information,
this commit also introduces a new migration path for editable settings
(both from legacy to the new format, and between versions). Examples
of how to do this correctly, and migrate to new versions of a settings
file, are in the settings/ subdirectory.
As part of this effort, editable settings have been revamped to
guarantee atomic saves (due to the increased amount of information in
each file), some latent bugs in networking were fixed, and server-cli
has been updated to go through StructOpt for both calls through TUI
and argv, greatly simplifying parsing logic.
