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.
This improves the defragment operation for chonks by letting them remove
chunks at the top that match above, and bottom that match below. This
reduces the chunks / chonk from around 5.9 to around 3.4 at origin. From
my investigations, adding something for water would probably get us a
full 50% reduction, if we could collapse intermediate chunks; block
types other than rock / air / water never appear to have full chunks of
the same block, so any additional optimization will require changes to
the subchunk compression format or changes to the actual chunks we
generate.
After generating a chonk, we now find the highest frequency block (in
terms of the number of groups that uniformly consist of that block) and
replace the chunk's default with that one. We also resort the data in
the process to be in the same order as the original array index. This
improves our memory savings from 3x to almost 7x, and brings us within a
factor of 3 or so of what I hope a true average will be.
The defragmentation is not totally optimal and can probably be improved
from a performance perspective, but given how much of a hard bottleneck
RAM is this seems worthwhile. Also, this doesn't suffer from the issues
the previous solution did.
3x - 5x depending on terrain. We can do a lot better but this is a good
start.
Also, added chunk group count to metrics. This correlates with memory
usage specifically by chunk voxel data in a much more direct way than
chonk or chunk count do, so this should provide extra useful information
(especially for our average overhead per chonk / chunk).
In the process, also try to address a few edge cases related to block
detection, such as adding back previously solid sprites and removing
filters that may be vestiges of earlier logic.
`stable-0.7.0 (<hash>-<datetime>)` for release versions.
And
`nightly-<date> (<hash>)` for nightly and master versions
Reason is, many players only give information that they are running `0.x.0` but are not giving us the information which day, or commit they are running. So we should make master builds less confusing.
