ed9fdcda79
User report: Phase 13's 15s force-claim default reopened a rare duplication scenario. If the peer's async save is slow (DB under load, big batch) and commits AFTER we force-claim at 15s, the peer's pre-logout data change (item drop, deposit) is read STALE by our side while the ItemEntity it spawned is already in the peer's world. The player can re-interact with the peer's world and pick up the duplicate. Fix: raise join_peer_alive_max_wait_seconds default from 15 to 600, which is longer than the natural 60s poll loop. Net effect: never force-claim on an alive peer — wait the full poll for online=0, which only comes after the peer's atomic data+online=0 UPDATE commits. Zero duplication window. Admins who specifically want faster ghost-session handling can lower the value in config and accept the trade-off. Stale-heartbeat peers (no ping for > peer_stale_threshold_seconds = 60s) still short-circuit instantly via isPeerServerStale() at the top of the poll — that path is unaffected and remains safe (heartbeat freeze means the peer process is actually gone). The RS2 batching from Phase 13 remains (unrelated pure perf). Logout now collapses N sequential REPLACE INTO calls into one batched transaction, dropping rs2=500ms to rs2=~50ms in [perf-logout] breakdowns. |
||
|---|---|---|
| .github | ||
| compat-mods | ||
| gradle/wrapper | ||
| src/main | ||
| .gitattributes | ||
| .gitignore | ||
| build.gradle | ||
| CHANGELOG.md | ||
| docker-compose.yml | ||
| ERROR_LOG.md | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| LICENSE | ||
| README.md | ||
| settings.gradle | ||
| TEST_PROCEDURE_v2.1.5.html | ||
PlayerSync
PlayerSync is a Minecraft Forge mod that synchronizes player data across multiple servers using a MySQL backend. It allows players to maintain their inventory, equipment, experience, advancements, and more when moving between servers in a network.
Mod Support
Any other mods support is also possible.
Development Setup
Database Setup (Docker)
A docker-compose.yml file is provided for easily setting up a MariaDB database instance for development testing.
- Make sure Docker is installed.
- Inside your work directory run:
This will download the MariaDB image (if not already present) and start a database container in the background.docker compose up -d - Stoppinng the Database
docker compose down
Data Persistence: The database uses a Docker volume, ensuring your data persists even if you stop and restart the containers.
Database Management Tool
The docker-compose.yml also includes an Adminer service, a lightweight database management tool.
- Access Adminer in your web browser at http://localhost:8080.
- Log in using the server with
- username:
playersync - database:
playersync - password: see docker-compose.yml
- username:
For debugging purposes, you can enable use_legacy_serialization to have readable database fields. This can cause crashes and unintended side-effects. Do not enable this on a production server if not absolutely necessary!
Running the Mod
The project uses Gradle for building and running. Use the provided Gradle wrapper (gradlew for Linux/macOS, gradlew.bat for Windows).
- Make sure that the MySQL database you configured is running.
- Run the Server
or on Windows:./gradlew runServer
This task compiles the mod and starts a dedicated Minecraft server instance with the mod loaded in the.\gradlew.bat runServerrundirectory. - Run the Client
or on Windows:./gradlew runClient.\gradlew.bat runClient