Included in the initial implementation is an entity browser which lists all entities in the client ECS, an entity component viewer which shows select components belonging to the selected entity including character state information, and a simple frame time graph.
This MR also includes an extraction of the animation hot reloading code which has been reused for egui to allow for hot-reloading of the egui interface to allow rapid development of the UI with realtime feedback upon save as is the case with aninmations. This is feature-gated behind the `hot-egui` feature which is not enabled by default due to the extra startup time that it adds.
This makes the delay afetr selecting a character before logging into the
game much shorter, in the common case. It still doesn't handle things
perfectly (it blocks creating Terrain::new if it's not finished, and it
could be faster due to working in the background), but it's still a lot
better than it was before.
To improve sprite meshing performance, we also apply the terrain
flat_get optimizations to sprites. Though I didn't initially know how
much of an impact it would have, it feels significantly faster to me,
though being able to parallelize it would be ideal.
- 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
* 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.
- before we had a Clock that tried to average multiple ticks and predict the next sleep.
This system is massivly bugged.
a) We know exactly how long the busy time took, so we dont need to predict anything in the first place
b) Preduction was totally unrealistic after a single lag spike
c) When a very slow tick happens, we dont benefit from 10 fast ticks.
- Instead we just try to keep the tick time exact what we expect.
If we can't manage a constant tick time because we are to slow, the systems have to "catch" this via the `dt` anyway.
