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.
remove outdated economic simulation code
remove old values, document
add natural resources to economy
Remove NaturalResources from Place (now in Economy)
find closest site to each chunk
implement natural resources (the distance scale is wrong)
cargo fmt
working distance calculation
this collection of natural resources seem to make sense, too much Wheat though
use natural resources and controlled area to replenish goods
increase the amount of chunks controlled by one guard to 50
add new professions and goods to the list
implement multiple products per worker
remove the old code and rename the new code to the previous name
correctly determine which goods guards will give you access to
correctly estimate the amount of natural resources controlled
adapt to new server API
instrument tooltips
Now I just need to figure out how to store a (reference to) a closure
closures for tooltip content generation
pass site/cave id to the client
Add economic information to the client structure
(not yet exchanged with the server)
Send SiteId to the client, prepare messages for economy request
Make client::sites a HashMap
Specialize the Crafter into Brewer,Bladesmith and Blacksmith
working server request for economic info from within tooltip
fully operational economic tooltips
I need to fix the id clash between caves and towns though
fix overlapping ids between caves and sites
display stock amount
correctly handle invalid (cave) ids in the request
some initial balancing, turn off most info logging
less intrusive way of implementing the dynamic tool tips in map
further tooltip cleanup
further cleanup, dynamic tooltip not fully working as intended
correctly working tooltip visibility logic
cleanup, display labor value
separate economy info request in a separate translation unit
display values as well
nicer display format for economy
add last_exports and coin to the new economy
do not allocate natural resources to Dungeons (making town so much larger)
balancing attempt
print town size statistics
cargo fmt (dead code)
resource tweaks, csv debugging
output a more interesting town (and then all sites)
fix the labor value logic (now we have meaningful prices)
load professions from ron (WIP)
use assets manager in economy
loading professions works
use professions from ron file
fix Labor debug logic
count chunks per type separately
(preparing for better resource control)
better structured resource data
traders, more professions (WIP)
fix exception when starting the simulation
fix replenish function
TODO:
- use area_ratio for resource usage (chunks should be added to stock, ratio on usage?)
- fix trading
documentation clean up
fix merge artifact
Revise trader mechanic
start Coin with a reasonable default
remove the outdated economy code
preserve documentation from removed old structure
output neighboring sites (preparation)
pass list of neighbors to economy
add trade structures
trading stub
Description of purpose by zesterer on Discord
remember prices (needed for planning)
avoid growing the order vector unboundedly
into_iter doesn't clear the Vec, so clear it manually
use drain to process Vecs, avoid clone
fix the test server
implement a test stub (I need to get it faster than 30 seconds to be more useful)
enable info output in test
debug missing and extra goods
use the same logging extension as water, activate feature
update dependencies
determine good prices, good exchange goods
a working set of revisions
a cozy world which economy tests in 2s
first order planning version
fun with package version
buy according to value/priority, not missing amount
introduce min price constant, fix order priority
in depth debugging
with a correct sign the trading plans start to make sense
move the trade planning to a separate function
rename new function
reorganize code into subroutines (much cleaner)
each trading step now has its own function
cut down the number of debugging output
introduce RoadSecurity and Transportation
transport capacity bookkeeping
only plan to pay with valuable goods, you can no longer stockpile unused options
(which interestingly shows a huge impact, to be investigated)
Coin is now listed as a payment (although not used)
proper transportation estimation (although 0)
remove more left overs uncovered by viewing the code in a merge request
use the old default values, handle non-pileable stocks directly before increasing it
(as economy is based on last year's products)
don't order the missing good multiple times
also it uses coin to buy things!
fix warnings and use the transportation from stock again
cargo fmt
prepare evaluation of trade
don't count transportation multiple times
fix merge artifact
operational trade planning
trade itself is still misleading
make clippy happy
clean up
correct labor ratio of merchants (no need to multiply with amount produced)
incomplete merchant labor_value computation
correct last commit
make economy of scale more explicit
make clippy happy (and code cleaner)
more merchant tweaks (more pop=better)
beginning of real trading code
revert the update of dependencies
remove stale comments/unused code
trading implementation complete (but untested)
something is still strange ...
fix sign in trading
another sign fix
some bugfixes and plenty of debugging code
another bug fixed, more to go
fix another invariant (rounding will lead to very small negative value)
introduce Terrain and Territory
fix merge mistakes
only `localhost` are allowed in a release build.
when debug assertions are on, others are also allowed.
This change undoes the changes to the settings, so compared to master, there is no effect
The auth server no longer allows the protocol to be specified. we enforce `https` for the auth server, so DO NOT provide a auth url with `https://` but without.
correct is now `auth.veloren.net`
incorrect is: `https://auth.veloren.net`
lagging a bit behind on terrain. Which is fine. Block Places and Block Pickup are not handled in this stream, as they go through the standart route of event handling.
Instead of keeping Runtime and manually spawn a task on `drop` this task is spawned at start and will wait to be triggered.
The `drop` methods then wait for completion, UNLESS they are in a async context, then they MUST NOT BLOCK (deadlock potential), so they defer it to the Runtime and HOPE for the runtime to exist long enough.
This get rid of the weird `block_in_place` which is only accessable with `rt-multi-threaded` and has some disadvantages.
We also wont requiere the runtime to be active all the time. Though its needed for a clean shutdown
- now last digit version is compatible 0.6.0 will connect to 0.6.1
- the TCP DATA Frames no longer contain START field, as it's not needed
- the TCP OPENSTREAM Frames will now contain the BANDWIDTH field
- MID is not Protocol internal
Update network
- update API with Bandwidth
Update veloren
- introduce better runtime and `async` things that are IO bound.
- Remove `uvth` and instead use `tokio::runtime::Runtime::spawn_blocking`
- remove futures_execute from client and server use tokio::runtime::Runtime instead
- give threads a Name
- completly switch to Bytes, even in api. speed up TCP by fak 2
- improve benchmarks
- speed up mpsc metrics
- gracefully handle shutdown by interpreting Ok(0) as tokio::tcpstream closed now.
- fix hotloop in participants by adding `Some(n)` to fix endless handing.
- fix closing bug by closing streams after `recv_mgr` is shutdown even if now shutdown is triggered locally.
- fix prometheus
- no longer throw when a `Stream` is dropped while participant still receives a msg for it.
- fix the bandwith handling, TCP network send speed is up to 1.5GiB/s while recv is 150MiB/s
- add documentation
- tmp require rt-multi-threaded in client for tokio, to not fail cargo check
this is prob stable, i tested over 1 hour.
after that some optimisations in priomgr.
and impl. propper bandwith.
Speed is up to 2GB/s write and 150MB/s recv on a single core
sync add documentation
switch to `tokio` and `async_channel` crate.
I wanted to do tokio first, but it doesnt feature Sender::close(), thus i included async_channel
Got rid of `futures` and only need `futures_core` and `futures_util`.
Tokio does not support `Stream` and `StreamExt` so for now i need to use `tokio-stream`, i think this will go in `std` in the future
Created `b2b_close_stream_opened_sender_r` as the shutdown procedure does not need a copy of a Sender, it just need to stop it.
Various adjustments, e.g. for `select!` which now requieres a `&mut` for oneshots.
Future things to do:
- Use some better signalling than oneshot<()> in some cases.
- Use a Watch for the Prio propergation (impl. it ofc)
- Use Bounded Channels in order to improve performance
- adjust tests coding
bring tests to work
- Separate `invite` machinery from `group_manip` into it's own thing (includes renaming `group_invite` to `invite` where applicable).
- Move some invite/trade machinery to `ControlEvent`.
- Make `TradePhase` a proper enum instead of a bunch of bools.
- Make `TradeId` a proper newtype.
- Remove trades from `Trades` on accept (previously was only on decline).
- Typo fixes/misc cleanup.
- Add bullet point for trading to the changelog.
- Fix item swapping edge case
- Document more assumptions/edge cases
- fmt and clippy
- s/ServerGeneral::GroupInvite/ServerGeneral::Invite/
- Use `Client::current` in `Client::is_dead`
- Accept/decline buttons that submit the proper messages
- A phase2 screen that renders the (item, quantity) pairs as text
- More checks in the trade state machine server-side.
this tests the broad api of veloren and FAILS in case the interface is changed. It contains a not that those functions are commonly used by 3rd parties
and thus they need to be notified
* Improved server error message for character load errors.
* Added server logging for item asset load errors during character load.
* Fixed character select error message dialog not supporting long messages.
player buffs animation
more testing debuffs
sorting and display limit fix
overhead buffs
fix
WIP buff removal function
fmt
Update buffs.rs
Now with compiling: WIP group UI buffs
positioning
Update group.rs
Update group.rs
Small optimizations.
Fixed positioning of buffs in group panel. Broke buff tooltips in group panel.
buff frame visuals
added setting for displaying buffs at minimap
His reason to reqeust that is, that there might not be a perfect disctinction in the future.
Now we need to send ServerGeneral over streams and do additional checking at various places to verify that not the wrong variant is send.
- Instread we have a dedicated thread that will async wait for new participants to connect and then notify the main thread
- registry no longer sends a view distance with it.
- remove ClientMsg::Command again as it's unused
```
//This is a helper structure, containing all possible data send over
pub enum ClientMsg {
Initial(ClientType),
General(ClientGeneralMsg),
InGame(ClientInGameMsg),
NotInGame(ClientNotInGameMsg),
Register(ClientRegisterMsg),
Ping(PingMsg)
}
```
Rather than having a single Stream to handle ALL data, seperate into multiple streams:
- Ping Stream, for seperate PINGS
- Register Stream, only used till the client is registered, then no longer used!
- General Stream, used for msg that can occur always
- NotInGame Stream, used for everything NOT ingame, e.g. Character Screen
- InGame Stream, used for all GAME data, players, terrain, entities, etc...
This version does compile, and gets the client registered (with auth too) but doesnt get to the char screen yet.
This fixes also the ignoring messages problem we had, as we are not sending data to the register stream!
This fixes also the problem that the server had to sleep for the Stream Creation, as the Server is now creating the streams and client has to sleep.
Add a basic random feature to char creation
loading screen bg (part 2)
loading screen changes, random button graphics
Random appearance also pick a random npc name
- Compression is no longer enabled always but can now be enabled per Stream.
If a Stream is Compression enabled it will compress and decompress all msg (except for `raw` access) before handling them internally.
You need to handle compression yourself for `raw` fn.
- added a new feature to the network crate to enable or disable the compression
- switched to `lz-fear` instead of `lz4-compression`
- use `bitflags` to represent the `Promises` struct
Till now, we just dropped the TCP connection and registered this as a clean shutdown.
The prodocol reader intereted this and send a Frame::Shutdown frame to it's local processor.
This is ofc wrong.
So now the protocol reader will detect a Frame::Shutdown frame and send it over. if the Tcp connection gets closed it will return an Error up.
The processor will then pick up this error and request a unclear shutdown and notifies the user.
Also when doing a clean shutdown we are sending a Frame::Shutdown now to the remote side to trigger this behavior.
Before we wrongly added the feature of only using a `select` in channel. This is WRONG,
as it could mean that the write maybe fails, but the read still had some Frames buffered which then get dropped.
Its fixed now by the clean shutdown mechanims defined before.
Also when a channel is closed now inside a participant we are closing the whole participant as a protection.
However, we must not close the recv channel as the `handle_frames_mgr` might still be working on them, so we only stop writing/sending.
Debugging this also let me introduce some smaller fixes:
- PID in tests are now 0 and 1+1*64+1*64*64+... this makes the traces appear as AAAAAA and BBBBBB instead of ABAAAA and ACAAAA
- veloren client now better seperates between clean shutdown and unclear shutdown.
- added a new type: C2pFrame for `(cid, Result<Frame, ()>)`
- wrong frames inside the handshare are not counted in metrics
-
