OwlHub | THE Hub-core you need v1.5.0

This release focuses on making OwlHub more reliable in real-world environments, especially for multi-hub setups, while also reducing unnecessary overhead across the plugin.

We’ve spent this update hardening the shared storage and queue systems, improving runtime safety, and doing a broad optimization pass across scoreboards, tab, boss bars, action bars, menus, and other frequently-used systems.

What’s new in v1.2.2​

Sync and storage hardening​

The player profile storage system is now more robust and easier to troubleshoot.

This includes:

• storage backend introspection
• schema/version visibility
• safer startup validation for profile storage
• better compatibility handling for legacy embedded storage configs
• clearer backend information through admin diagnostics

We also improved queue persistence reliability with additional backend checks, safer failure handling, and improved recovery behavior.

Queue improvements​

The queue system received a large stability pass.

Changes include:

• backend availability tracking
• backend ping support
• queue record inspection/debugging
• safer Redis and memory backend behavior
• throttled outage/recovery logging
• improved queue consistency handling
• configurable heartbeat timeout support

We also added more queue command aliases for convenience:

• /joinqueue aliases: /join, /play, /joinq, /jq
• /leavequeue aliases: /leave, /leaveq, /lq

Performance improvements​

A large part of this release was dedicated to reducing repeated work and unnecessary task overhead.

Major optimizations include:

• shared timers instead of repeated per-player tasks for boss bars, queue action bars, and gadget effects
• reduced packet churn in the packet-based scoreboard and tab systems
• cached placeholder/text resolution for scoreboard, tab, menus, and join items
• fewer redundant config lookups in hot paths
• better handling of movement and teleport edge cases
• reduced unnecessary profile saves
• lower allocation overhead in several GUI and rendering paths

Overall, this makes OwlHub lighter, cleaner, and more scalable under regular use.

Fixes​

This update also includes several important fixes, including:

• fixed PacketEvents warning spam caused by scoreboard packet listener edge cases during login
• improved compatibility for older sqlite profile-storage configs by treating them as legacy h2
• improved deployment/testing reliability by avoiding multi-version plugin loading caused by leftover OwlHub jars

Notes for updating​

If you are upgrading, make sure you:

• remove old OwlHub jars from your /plugins/ folder before copying the new build
• delete the old /plugins/OwlHub/ folder if you want fresh bundled configs to regenerate
• keep only the latest OwlHub jar on the server to avoid multiple versions loading at once

If you were previously using an older sqlite player-data backend value, OwlHub will now treat it as legacy h2, but updating your config to backend: h2 is recommended.

Summary​

v1.2.2 is a cleanup and hardening release.

It improves stability, reduces overhead, adds queue QoL, and strengthens the foundation for future sync and multi-hub work without changing OwlHub’s default setup philosophy.

With this release, we’ve added the first version of cross-server sync for OwlHub.

Your players’ durable hub data can now be persisted outside the local server, which means preferences, selected cosmetics, armor state, gadgets, and similar profile data can now be shared across hubs instead of being tied to a single preferences.yml file or in-memory storage.

We’ve also added a new queue persistence system with support for reconnect and hub-switch grace periods. This means players can now switch between hub servers without instantly losing their queue position, and if they disconnect and come back within the configured grace period, they can resume their queue as well.

To make this flexible for all setups, we introduced optional storage backends:

• h2 is now the default embedded storage for single-server or simple setups
• mysql and mariadb are available for shared multi-hub profile storage
• memory remains the default queue backend for single-hub networks
• redis is available for multi-hub queue persistence

We originally introduced SQLite for embedded profile storage during the sync work, but with v1.2.1 we switched the default embedded backend to H2 to reduce the plugin jar size while keeping the same simple local-database workflow for smaller networks.

Queue persistence is now backend-driven and includes:

• hub transfer grace period
• disconnect grace period
• configurable heartbeat timing
• Redis-backed atomic queue handling for multi-hub environments

This gives OwlHub a much better foundation for large network environments while still keeping the default setup simple for servers that only use one hub.

Please note:

• If upgrading from older versions, back up and then delete the old plugins/OwlHub/ folder before testing so the new bundled configs generate correctly.
• If you are using a single hub, you can keep the defaults and use h2 + memory.
• If you want full cross-hub player profile sync, use mysql or mariadb.
• If you want cross-hub queue persistence, use redis.
• Existing legacy preferences.yml data is not migrated automatically in this release.
• If you were testing the earlier SQLite-based sync build, v1.2.1 now defaults to H2 instead.

Upcoming changes with the next release

We’ll continue expanding the shared profile system and queue system, with focus on:

• more synced cosmetic/player state
• more polish around multi-hub queue recovery
• further improvements to multi-platform compatibility
• additional quality-of-life options around storage and migrations

With this release, we've added support for Folia and Spigot, which means with this version, you'd be able to use our Hub core on any platform.

We've also switched from ProtocolLib to a more modern approach for modifying packets - PacketEvents. We think that would boost performance and have a better future to develop more complex features. With this, we've completely rewritten the tab and scoreboard to be completely packet-driven to achieve full cross-platform compatibility.

Your players now have the option to toggle their boss bars via the preferences menu.

We've expanded the PlaceholderAPI support across messages, scoreboard, tab, boss bar, menus, join items, gadgets, armor UI, and queue action bar.

We've added a current server display to the scoreboard (which you can customize) so your players know in which hub server they are.

There's also a new queue config option, queue.position-update-chat-improve-only, this option allows you to change when the player receives a queue update message. If set to true, the player will receive a message about their queue position if it gets lower.

Please note:

• If upgrading from older versions, back up and then delete the old plugins/OwlHub/ folder before testing so the new bundled configs generate correctly.
• Make sure PacketEvents is installed before starting the server.

Upcoming changes with the next release

We're adding cross-server sync, which allows your players' info like selected armor, preferences, etc., to be transferred to another hub if they switch. Right now, cross-server sync is not available since we're storing preferences in preferences.yml and it's a per-server DB store; other things like armor and gadgets are stored in memory. Another thing we're very proud of is queue sync; this would allow a player to switch hubs without losing their queue position. We'll be adding queue leave grace period as well; this means that if a player accidentally disconnects and connects back, they wouldn't lose their queue position; also, this is in the core functionality for the queue server sync. The grace period will be customizable.

Some requirements that will come with this:

• MySQL or MariaDB database
• Redis database

MySQL/MariaDB will be used for the hard data, aka preferences, armor, etc.; meanwhile, Redis will be used for the queue sync, since queues are live data and MySQL isn't really a good fit nor option for this sort of data. However, if you're a single hub network, you don't need any of those; the hard data will be stored in a SQLite file, and the queue will be stored in memory; the grace period would still be available.