- Handle/notify the client of errors during character load by returning to character select with the error, clean up client and server states
- Add player_uuid check when loading character data.
big combined updates.
- Add a timer to the stats persistence system and change the frequency
that it runs to 10s
- Seperate the loading of character data for the character list during
selection, and the full data we will grab during state creation. Ideally
additional persisted bits can get returned at the same point and added
to the ecs within the same block.
- Make the character screen load with an empty character list from the server, send event to the server for character creation with data, but not yet saving them to the DB.
- Working but messy character saving to DB
- Add the character_data to the client, rather than keep it in the GLobalState.
Adds removing extra components and deleting entities clientside when
going back to the character screen. Also, simplifies ClientState by
removing the Dead variant and removing ClientMsg::StateRequest in favor
of more specific ClientMsg variants.
fix(overflow): Stops including block updates that fail (since chunks
don't exist on the client) in `TerrainUpdates` (which would trigger
meshing of those nonexistent chunks). Furthermore, removes
remeshing of chunks with block updates if those chunks don't have all their
neighbours (since those wouldn't be meshed in the first place).
Currently we only do this when no players are in range of the chunk. We
also send the first client who posted the chunk a message indicating
that it's canceled, the hope being that this will be a performance win
in single player mode since you don't have to wait three seconds to
realize that the server won't generate the chunk for you.
We now check an atomic flag for every column sample in a chunk. We
could probably do this less frequently, but since it's a relaxed load it
has essentially no performance impact on Intel architectures.
Currently we only do this when no players are in range of the chunk. We
also send the first client who posted the chunk a message indicating
that it's canceled, the hope being that this will be a performance win
in single player mode since you don't have to wait three seconds to
realize that the server won't generate the chunk for you.
We now check an atomic flag for every column sample in a chunk. We
could probably do this less frequently, but since it's a relaxed load it
has essentially no performance impact on Intel architectures.
