Nexori 2.5.0

Nexori 2.5.0 is a reliability and minigame-infrastructure update. This version focuses on making minigame launches more stable, improving backend backfill support, adding built-in AFK detection, and making the public API/documentation easier to use.

Main Highlights

More reliable minigame launches

This update fixes an important minigame travel issue that could prevent players from joining minigame instances correctly.

In previous builds, Nexori could send a player through an extra default-world teleport during the minigame launch flow. For players with no saved player/world data, the server could already place them in the default world automatically, while Nexori was also trying to route them through the default world and then into the instance. That could create two very close teleports to different worlds and cause client/server desync or failed minigame entry.

This flow has been reworked and tested more carefully. Players should now transfer into minigame instances much more reliably.

Built-in AFK detection for matches

Nexori now includes lightweight AFK detection for active minigame matches.

This is optional and configurable. Server owners can enable/disable AFK detection per game from the UI, and minigames can also override AFK policy at runtime.

This makes it possible to support different rules per player or role. For example, a hide-and-seek minigame could use a longer AFK timer for hiders and a shorter timer for seekers, or disable AFK detection for specific players when the gameplay requires it.

AFK state is also exposed through the public API and can be included in final match result data.

Better match HUDs and player feedback

Several Nexori runtime HUDs were improved to make the player flow clearer:

• Queue waiting
• Match launching
• AFK warning
• AFK detected
• Not enough players / returning to lobby
• Match return and no-contest states

The goal is to make queueing, launching, waiting, and returning feel more readable and less confusing for players.

Start gate and placement window support

Nexori now has a cleaner match start flow for minigames.

Instead of rules mods guessing when gameplay should begin, the public API now exposes a start-gate signal. Minigames should use onMatchStartAllowed(...) as the safe point to begin gameplay.

This also supports partial-roster starts when enough players arrive before the initial placement window closes.

Important Notes for Backend Owners

If you already have a custom backend integrated with Nexori, review your endpoint contracts before updating.

Match admission state payload changed

/nexori/matches/state now includes:

"reportingServerConnectionAddress": "server.example.com:21918"

Backends should store this value with open match records. It allows the backend to create valid cross-server BACKFILL assignments without requiring the arena/minigame server to run /nexori/sync.

Sync arena snapshot changed

The backend sync arena snapshot no longer includes matchResolutionTriggerId.

If your backend expects or requires that field from /nexori/sync, update your contract. New integrations should use rulesEngineId and explicit public API result submission.

Results now support NO_CONTEST

/nexori/results now supports NO_CONTEST as a player outcome.

This is used for cases where a match should not count as a normal win/loss, such as pre-game cancellation when not enough players arrive.

AFK result data

When available, Nexori can include AFK summary data in final result custom data under:

customData.nexoriAfk

AFK state information is provided for reporting, analytics, and match result processing when available.

Important Notes for Minigame Developers

Use the start gate to begin gameplay

Minigames should treat:

onMatchStartAllowed(...)

as the recommended signal to begin gameplay.

onMatchPlacementCompleted(...) is still useful, but the start gate is the safer gameplay-unlock point because it also supports initial placement windows and partial-roster starts.

Use Nexori’s result requirement set

Before submitting final results, use:

NexoriApi.findMatchResultRequirements(matchId).requiredPlayerUuids()

to determine which players Nexori expects outcomes for when the match is resolved.

This is the authoritative player set maintained by Nexori and should be preferred over custom tracking lists maintained by individual minigames.

New public API support

Nexori API 2.5.0 adds or expands support for:

• onMatchStartAllowed(...)
• onMatchCancellationRequested(...)
• expanded NexoriMatchPlacementState
• NO_CONTEST
• AFK listeners, policies, and runtime state
• AFK player UUIDs in active match snapshots
• generated Javadoc reference for exact API classes and signatures

Developers should compile against:

compileOnly("com.github.hyjn-nexori:nexori-api:v2.5.0")

Server owners should install the full nexori-plugin.jar, not nexori-api.jar.

Legacy Minigame Resolution Changes

The old built-in Last Player Alive game-resolution system has been removed.

This system acted as a lightweight built-in game engine inside Nexori: it tracked player eliminations, marked eliminated players as losers, and automatically declared the last remaining player as the winner.

While the implementation was reasonably isolated, it did not align with Nexori's long-term goal. Nexori's primary responsibility is orchestration—matchmaking, server coordination, player placement, lifecycle management, and result delivery—not minigame-specific gameplay logic.

Removing this feature reduces the overall scope of the project, simplifies maintenance, and helps keep the codebase focused on the core platform. Even if Nexori gains official minigames in the future, the current direction is for those to exist as separate mods that consume the same public API as any other minigame rather than being embedded directly into Nexori itself.

New minigames should use:

• rulesEngineId
• lifecycle callbacks
• explicit player outcomes
• final result submission through the public API

At the moment, the old Last Player Alive behavior has not been moved into a separate replacement mod.

If your server depended on this built-in functionality, you will need to migrate that logic into your own rules/minigame mod that reports outcomes through the API. There are currently no plans to reintroduce it into Nexori itself. If enough server owners are interested in a standalone replacement, feel free to reach out through the Nexori Discord and let us know.

Fixes and Reliability

• Fixed minigame transfer flow issues that could cause failed instance entry or client/server desync.
• Improved transfer session handling and ready-event handling.
• Improved instance-world materialization so multiple players joining the same match do not duplicate instance spawning.
• Improved required result tracking so backfill/later-arriving players are included in Nexori’s official result requirement set.
• Improved return-to-lobby handling for match completion and no-contest returns.
• Improved backend backfill support through match admission state reporting.
• Improved command permission behavior for admin and player recovery commands.

Documentation

The Nexori docs were heavily updated for 2.5.0:

• Backend Integration guide
• Public API guide
• Generated Javadoc reference
• Multi-server backend/backfill explanation
• Catalog Sync vs backend /nexori/sync
• API examples using nexori-api:v2.5.0

Docs: https://docs.hyjn-nexori.com/

Capture The Zone demo note

The Capture The Zone example/minigame was also updated to work better with the current Nexori public API and backfill flow, but it is separate from the core Nexori plugin release.