Nexori 2.4.0

Nexori 2.4.0 focuses on two big areas: a stronger public API for minigame integrations, and real runtime spectator support.

This release also includes internal architecture cleanup, a standalone developer API artifact, and updated example projects for minigame creators.

Minigame API Lifecycle Callbacks

Nexori now exposes public lifecycle callbacks for minigames and rule engines.

Minigames can register a listener with:

registerMatchLifecycleListener(...)

This lets a minigame react to Nexori match lifecycle events instead of constantly polling with API queries.

The new listener API includes:

• NexoriMatchLifecycleListener
• NexoriListenerRegistration
• onMatchCreated(...)
• onPlayerArrived(...)
• onPlayerPlacementConfirmed(...)
• onMatchPlacementCompleted(...)
• onMatchCompleted(...)
• onMatchRuntimeClosed(...)

This makes the recommended integration flow much cleaner:

• Nexori orchestrates queues, backend assignment, match creation, travel, placement, result reporting, return-to-lobby, and cleanup.
• The minigame owns gameplay rules, scoring, win/loss detection, HUD/gameplay state, and local session state.
• A small integration/adapter class translates between Nexori callbacks and the minigame's own runtime.

For developers building optional minigame integrations, the recommended pattern is to keep the minigame core independent from Nexori:

• Nexori sends lifecycle callbacks to your integration adapter.
• Your adapter creates or updates your minigame's local session.
• Your minigame core runs from that local session state.
• When your minigame finishes, it publishes its own private event.
• Your adapter receives that event and calls the appropriate Nexori API commands.

Spectator Runtime Upgrade

setPlayerSpectator(...) now applies real runtime spectator behavior.

Before this release, spectator state was mostly logical: Nexori could mark a player as a spectator in match state, but the player was not strongly affected at runtime.

In 2.4.0, Nexori spectator mode can now apply runtime behavior such as:

• hiding spectators from active players;
• keeping spectators visible to other spectators;
• switching the player to Adventure mode;
• enabling flight;
• making the player intangible and invulnerable;
• disabling collision, trigger, and damage block checks;
• blocking gameplay interactions, window actions, item movement, and item drops;
• preventing item pickup through spatial filtering;
• applying an optional temporary spectator model override.

This is useful for elimination-style minigames where a player should remain in the match as an observer without affecting active gameplay.

Standalone Nexori API Artifact

The public Nexori API has been split into its own developer artifact:

https://github.com/hyjn-nexori/nexori-api

Developers can now compile minigames against Nexori's public API through JitPack:

repositories {
    mavenCentral()
    maven { url = uri("https://jitpack.io") }
}

dependencies {
    compileOnly("com.github.hyjn-nexori:nexori-api:v2.4.0")
}

Important:

• nexori-api is for developers.
• Use it as compileOnly.
• Do not use implementation.
• Do not shade or bundle nexori-api inside your minigame jar.
• Do not install nexori-api.jar as a server mod.
• Server owners should install the full nexori-plugin.jar.
• nexori-plugin.jar provides the API classes at runtime.

Capture The Zone Example And Minigame Template

The Capture The Zone minigame project was updated to demonstrate the new integration model:

https://github.com/hyjn-nexori/nexori-capture-the-zone-minigame

Capture The Zone now shows how a minigame can:

• keep its core gameplay independent from Nexori;
• use private minigame events internally;
• integrate with Nexori through a dedicated adapter class;
• run with Nexori installed;
• start without Nexori installed;
• run a small local session without Nexori.

This means the minigame is not forced to be "only a Nexori minigame". It can own its gameplay runtime and integrate with Nexori when Nexori is present.

There is also a starter template for developers who want to build their own Nexori-compatible minigame:

https://github.com/hyjn-nexori/nexori-minigame-template

The template demonstrates:

• a minigame core with no direct Nexori imports;
• private minigame events;
• optional Nexori integration through reflection;
• Nexori listed as an optional dependency;
• a dedicated TemplateNexoriIntegration adapter.

More information is available in the documentation:

https://docs.hyjn-nexori.com/public-api/integrating-third-party-minigames

Deprecated Minigame APIs Removed

Deprecated legacy minigame result APIs were removed from the public API.

Removed legacy methods include:

• submitMatchResult(...)
• resolvePlayerOutcome(...)

The current result flow is explicit:

• setPlayerOutcome(...)
• setPlayerSpectator(...)
• submitFinalMatchResult(...)
• returnPlayerToLobby(...)

This keeps player outcomes, spectator state, final result submission, and return-to-lobby behavior clear and separate.

Internal Refactor And Testing Foundation

Nexori also received a significant internal refactor.

The codebase is now better separated between:

• business logic and decision-making;
• runtime services that execute Hytale API actions;
• API bridge/integration code;
• testable lifecycle and spectator behavior.

This matters because Nexori is source-available and growing as a platform. The cleaner separation makes it easier to test behavior with unit tests and keep future features safer.

These internal changes are not the main user-facing feature of 2.4.0, but they are an important foundation for future releases.

Summary

Nexori 2.4.0 adds:

• public lifecycle callbacks for minigame integrations;
• a cleaner optional integration pattern for third-party minigames;
• real spectator runtime behavior through setPlayerSpectator(...);
• a standalone nexori-api developer artifact through JitPack;
• updated Capture The Zone and minigame template projects;
• removal of deprecated legacy minigame APIs;
• internal refactoring and testing foundations for safer future development.