feat: Player Data Storage #205

KingTimer12 · 2025-08-23T21:10:00Z

Currently, my proposal is to leverage the same database used for world storage (LMDB) and persist player data there. This follows the general idea from Bukkit/Spigot/Paper, where player data is stored inside the world folder.

But I'm still considering whether storing all player data inside data.lmdb is the best approach, or if a dedicated playerdata folder inside the world directory—where each player's data would be stored separately by UUID—might provide better organization and flexibility.

For now, the implementation will move forward with LMDB, but I’m open to feedback on which design would be preferable long-term.

Todo (work in progress, will update as needed):

ReCore-sys · 2025-08-24T08:02:43Z

Hey thanks for getting started on this! My general plan for storing entities as a whole is to use sqlite (or turso depending on it's progress) to store them all in a normal sql database, as opposed to the kv format of lmdb. If you'd be comfortable starting on that that'd be great, otherwise just use lmdb for now and I can move it over later.

KingTimer12 · 2025-08-24T14:12:10Z

Ok, I'll switch to SQLite and use the idea of the playerdata folder but in a SQL database (playerdata.db) 👍

…player-state

… into feature/player-state

ReCore-sys

Mostly good changes, but a lot of OOP patterns that don't really fit the project, especially the PlayerData stuff since that can actively harm bevy's parallel processing capabilities.

src/bin/src/systems/shutdown_systems/send_shutdown_packet.rs

src/lib/core/src/data/player.rs

ReCore-sys · 2025-10-22T09:17:26Z

src/lib/storage/src/sqlite.rs

Implementing this as a trait doesn't make much sense since it has quite a different use-case as the KV store, especially since we'd like be storing entities in here as well.

I separated them because both are banks and have, in my view, common functions and, if they decided in the future to change the bank that stores the players, I think it would make things easier...

…player-state

Sweattypalms

I've reviewed what I could. Not that experienced with database, @ReCore-sys would be able to review that section properly. But is SQL Injection a thing we should be worried about? I reckon not, since we have control over the database. And also traits for database seems interesting, again, not an expert so recore will have to check that out.

src/bin/src/packet_handlers/play_packets/player_loaded.rs

Sweattypalms · 2025-10-26T17:37:04Z

src/bin/src/packet_handlers/player/player_disconnect.rs

+use bevy_ecs::{event::EventReader, prelude::Res, system::Commands};
+use ferrumc_core::conn::player_disconnect_event::PlayerDisconnectEvent;
+use ferrumc_state::GlobalStateResource;
+
+pub fn handle(
+    mut cmd: Commands,
+    mut events: EventReader<PlayerDisconnectEvent>,
+    state: Res<GlobalStateResource>,
+) {
+    for event in events.read() {
+        let uuid = event.identity.uuid.as_u128();
+        let username = &event.identity.username;
+        if let Err(e) = state.0.world.save_player_state(uuid, &event.data) {
+            tracing::error!("Failed to save player state for {}: {}", username, e);
+        } else {
+            tracing::info!("Player state saved for {}", username);
+        }
+        cmd.entity(event.entity).despawn();
+    }
+}


from what i see, this is an event handler, why is this in the packet handler dir? is confusing if its the disconnect event received from connection killer and server kill.

Honestly, I didn't know where to put it, after all, we didn't have a folder called events and I didn't know whether to put it inside systems or packets (the reason for putting packets is because of the "head_rot" event)

head rot event is most likely being called from a packet. on the other hand the event you made has nothing to do with packets. why not make a separate module specifically for events? i reckon it'd be best?

I agree, having it here makes little sense

src/lib/core/state/src/lib.rs

src/lib/core/state/src/player_state.rs

ReCore-sys · 2025-10-27T00:52:05Z

src/bin/src/packet_handlers/player/player_disconnect.rs

+use bevy_ecs::{event::EventReader, prelude::Res, system::Commands};
+use ferrumc_core::conn::player_disconnect_event::PlayerDisconnectEvent;
+use ferrumc_state::GlobalStateResource;
+
+pub fn handle(
+    mut cmd: Commands,
+    mut events: EventReader<PlayerDisconnectEvent>,
+    state: Res<GlobalStateResource>,
+) {
+    for event in events.read() {
+        let uuid = event.identity.uuid.as_u128();
+        let username = &event.identity.username;
+        if let Err(e) = state.0.world.save_player_state(uuid, &event.data) {
+            tracing::error!("Failed to save player state for {}: {}", username, e);
+        } else {
+            tracing::info!("Player state saved for {}", username);
+        }
+        cmd.entity(event.entity).despawn();
+    }
+}


I agree, having it here makes little sense

ReCore-sys · 2025-10-27T00:53:26Z

src/bin/src/systems/shutdown_systems/send_shutdown_packet.rs

+    for (entity, conn, identity, position, on_ground, rotation) in query.iter() {
        if state.0.players.is_connected(entity) {
+            let player_disconnect = PlayerDisconnectEvent {
+                data: PlayerData::new(position, on_ground.0, "overworld", rotation),


Why are we including this data here? The event handler can just fetch this data if you give it the entity

ReCore-sys · 2025-10-27T01:00:05Z

src/lib/storage/src/database.rs

@@ -0,0 +1,33 @@
+use crate::errors::StorageError;
+
+pub trait Database {


This trait is largely not going to work when we need to start doing more complicated SQL queries and we won't be doing any dynamic dispatch shenanigans with multiple DB backends, so I'm not sure if using a trait here is the right move

ReCore-sys · 2025-10-27T01:03:01Z

src/lib/storage/src/sqlite.rs

+
+    fn insert(&self, table: &str, key: Self::Key, value: Self::Value) -> Result<(), StorageError> {
+        let conn = self.open_conn()?;
+        let json_val: Value =


Why are we using json here? we know the fields, you can just store those as columns in the table, that kinda the whole point of SQL databases

ReCore-sys · 2025-10-27T01:05:01Z

src/lib/world/src/player_state.rs

+
+impl World {
+    pub fn save_player_state(&self, key: u128, state: &PlayerData) -> Result<(), PlayerDataError> {
+        self.player_state_backend.create_table(TABLE_NAME)?;


You don't need to create a table each time you call, just generate the tables in the setup/init stage and assume it's there, sqlite will error out if it's not

KingTimer12 added 8 commits September 13, 2025 13:48

feat: player data storage initialized

e823b3e

fix: cargo fmt and cargo audit

cae8c54

fix: cargo clippy

2eeab0e

feat: added sqlite support

4f8db95

fix: cargo clippy

ed2e353

fix: benches test of storage

67a9bf5

chore: changed to sqlite

4fff8d3

fix: cargo audit error

d9b0bfa

KingTimer12 force-pushed the feature/player-state branch from c6ba358 to d9b0bfa Compare September 13, 2025 17:00

KingTimer12 added 16 commits September 13, 2025 14:01

fix: cargo fmt

400d746

fix: cargo clippy

b7bea43

fix: cargo clippy

a2b92ff

Merge branch 'master' of github.com:KingTimer12/ferrumc into feature/…

234fb78

…player-state

feat: player data storage initialized

64491ab

fix: cargo fmt and cargo audit

8ac0648

fix: cargo clippy

cbfa307

feat: added sqlite support

7fc22ef

fix: cargo clippy

6d3c4c5

fix: benches test of storage

9f0d3aa

chore: changed to sqlite

e093a28

fix: cargo audit error

cc4d935

fix: cargo fmt

c383f0c

fix: cargo clippy

813e9a3

fix: cargo clippy

b35c2f5

Merge branch 'feature/player-state' of github.com:KingTimer12/ferrumc…

1ad2bca

… into feature/player-state

ReCore-sys moved this to In progress in FerrumC's beloved project Oct 19, 2025

ReCore-sys added this to FerrumC's beloved project Oct 19, 2025

chore: now is updating player data

b0e6aa7

fix: i forgot fmt :p

c408791

ReCore-sys requested changes Oct 22, 2025

View reviewed changes

KingTimer12 added 4 commits October 22, 2025 09:02

chore: updated the way playerdata is used

1a5ca03

chore: saving data through event

c31ee14

Merge branch 'master' of github.com:KingTimer12/ferrumc into feature/…

01f24fb

…player-state

fix: problem in my gitignore; fix: cargo.toml with old dep;

b70b7b2

KingTimer12 force-pushed the feature/player-state branch from 444bc64 to b70b7b2 Compare October 23, 2025 11:27

KingTimer12 requested a review from ReCore-sys October 23, 2025 11:29

chore: added player disconnect event in connection killer

dcd5148

KingTimer12 marked this pull request as ready for review October 26, 2025 15:13

Sweattypalms requested changes Oct 26, 2025

View reviewed changes

KingTimer12 added 2 commits October 26, 2025 14:54

chore: removed PlayerState

3d8d02c

chore: added Display to player data

d386bd8

ReCore-sys requested changes Oct 27, 2025

View reviewed changes

		@@ -0,0 +1,33 @@
		use crate::errors::StorageError;

		pub trait Database {

Uh oh!

feat: Player Data Storage #205

Are you sure you want to change the base?

feat: Player Data Storage #205

Uh oh!

Conversation

KingTimer12 commented Aug 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Todo (work in progress, will update as needed):

Uh oh!

ReCore-sys commented Aug 24, 2025

Uh oh!

KingTimer12 commented Aug 24, 2025

Uh oh!

ReCore-sys left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sweattypalms left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

KingTimer12 commented Aug 23, 2025 •

edited

Loading