SMP Player Data Sync v1.0

HoneySync - Cross-Server Player Data Synchronization​

HoneySync is a state-of-the-art, high-performance player data synchronization engine for Minecraft networks. Powered by Redis for instantaneous live handoffs and MySQL/MariaDB for permanent persistence and automated backups, HoneySync ensures that player inventories, ender chests, health, and statistics transfer seamlessly across your network with zero risk of data loss or duplication.

Technical Specifications​

• Supported Servers: Paper, Folia, ShreddedPaper, and Leaf.
• Folia Support: Native (folia-supported: true). Every entity-related operation runs on Folia's region-aware schedulers rather than blocking main threads.
• Minecraft Versions: 1.21.1 and newer. Built strictly on stable Paper APIs—no NMS or fragile internal reflection. Version-sensitive lookups (attributes, effects) resolve through the modern registry API, and item serialization embeds the Minecraft data version so items automatically upgrade on newer backend versions.
• Java Requirement: Java 21+

What is Synchronized​

Every aspect of a player's profile can be synchronized, with individual toggle modules in your configuration file:

• Inventory: Exact item slots, armor, selected hotbar slot, and off-hand items.
• Ender Chest: Complete contents and custom slot arrangements.
• Attributes & Status: Health, hunger, saturation, exhaustion, XP (level + progress bar), air bubbles, and active fire ticks.
• Game State: Game mode, active potion effects (retaining exact remaining durations), statistics, and advancements.

Enterprise-Grade Anti-Loss & Anti-Dupe Design​

HoneySync is designed from the ground up to protect your economy and server integrity:

• Join Locking: Players are completely locked on join (blocking inventory clicks, drops, pickups, and damage) until their remote data is successfully applied.
• Sequential Handoffs: When switching servers, the target server halts loading and waits for the source server to complete its save, coordinated via Redis pub/sub signals and timestamp verification.
• Fail-Safe Disconnections: If player data fails to load, the player is kicked instantly and their local state is never saved, preventing empty or corrupted states from overwriting valid database entries.
• Timeout Protections: If a handoff times out, the player is kicked immediately instead of receiving stale data, closing item-duplication windows.
• Database Profile Integrity: Utilizes single-row SQL entries per UUID with atomic upserts. Stale usernames are automatically purged from profiles upon name changes, preventing name conflicts.
• Heartbeat Deadlock Prevention: Online-lock keys in Redis are governed by a Time-To-Live (TTL) refreshed via background heartbeats. If a backend server crashes, players are never permanently deadlocked out of the network.
• Periodic Autosaves: Staggered asynchronous autosaving provides crash safety without causing performance spikes.

Comprehensive Backup System​

HoneySync takes automated snapshots on key gameplay events: join, quit, and death (fully rotatable with per-type maximums), alongside manual snapshot commands.

Each backup records the exact backend server it was captured on. Using the /honeysync backups <player> admin menu, administrators can:

• Inspect any historic backup.
• Restore inventories or ender chests directly to online players.
• Preview ender chest contents in a secure virtual interface.
• Package a player's complete inventory backup into named shulker boxes (supports offline target delivery).
• Execute /honeysync backup all to trigger a staggered, network-wide backup of every online player across all servers.

Compatibility with Custom Items​

All items are serialized with their full NBT profiles and PersistentDataContainers (PDC). Custom items from advanced plugins like ExecutableItems, ExecutableBlocks, and Nexo survive transfers, backups, and shulker exports completely intact.

Live Viewers and Editors​

The /invsee and /endersee commands provide a real-time view of a player's inventory or ender chest, updating dynamically based on your configured refresh interval. Remote player profiles are fetched via the Redis command channel, and requests are de-duplicated so multiple administrators inspecting the same player share a single network payload.

With the .edit permission, administrators can open fully editable sessions:

Target Online on the Local Server​

The target player's inventory interactions are locked while the editing menu is open. Changes are applied directly upon closing the container, eliminating duplication loops.

Target Online on a Remote Server​

A distributed editing session is initiated over Redis. The target player is locked on their host server while the items are shipped to the administrator. Once the administrator closes the editor, the changes are committed back. Active sessions use keepalive heartbeats; if the editing administrator disconnects, the remote lock safely auto-releases and stale commits are discarded.

Target Offline​

The player's offline profile is loaded directly from MySQL/Redis. Closing the container saves the changes back to the database, ensuring the player receives the updated inventory the moment they connect to any server on the network. If the player logs in mid-edit, the session is safely discarded to protect live data.

Commands & Permissions​

Available Aliases: /honeysync, /hsync, /inventorysee, /enderchestsee.

Note: The honeysync.admin wild card grants access to all commands. Tab-completion dynamically displays players online across other network instances by utilizing a synchronized global Redis cache.

System Performance (Targeted for 1000+ Players)​

• Asynchronous Execution: Absolutely zero blocking on your main server threads. All SQL and Redis network operations are handled by a dedicated IO thread pool.
• Non-Blocking Handoffs: Server handoffs and login waiting tasks use non-blocking scheduled polling and pub/sub wake-ups, allowing thousands of concurrent player transfers to consume zero thread allocation.
• Staggered Autosaves: Autosaves are spread evenly across your configured save window instead of flushing all players to the database in a single tick.
• Pipelined Heartbeats: Core online-lock checks are pipelined, combining network updates into a single Redis round trip regardless of player count.
• High-Speed Deserialization: Redis snapshots utilize timestamp prefixes to execute freshness checks without decompressing data. Snapshots are stored as gzipped JSON, allowing server switches to bypass database queries entirely.