Skip to main content

Player observability

This page explains how admins can observe player behavior from the player detail page.

Data source note: sessions, routes, contacts, and embedded logs depend on imported server logs. For freshness and delay behavior, see Logs import concept.

Navigation path:

  • Server Admin -> Players -> Player details

Access requirements​

Minimum requirement to open the player detail page:

  • players.view

Additional rights used by observability tools:

  • players.edit (for device disconnect actions; backend-enforced)
  • players.create (for creating a new player profile on a device)
  • players.see_position (routes tab visibility)
  • logs.view (embedded logs visibility and route data population)

Additional data caveat:

  • embedded logs and route data require at least one non-empty in-game username in the current player/device context

If a section is empty or missing, check access rights.

In the Devices tab, admins see:

  • all device IDs linked to this player
  • all player profiles attached to each device (including alt accounts)
  • quick navigation into related player profiles

Cross-server alt accounts: For each device, the tab also shows player profiles from other servers that share the same device. This gives admins full visibility into a player's platform-wide alt account network even when alts have never joined the current server.

What this helps with:

  • identifying account clusters sharing one device
  • spotting likely alt accounts, including those only active on other servers
  • checking whether suspicious activity appears across multiple profiles

Operational actions:

  • disconnect player-device relation (players.edit)
  • create a new player profile on an existing device (players.create)

In the Sessions tab, admins get a calendar built from player sessions on devices associated with the current player context.

What it shows:

  • timeline blocks of online sessions
  • the current player as the primary focus
  • related accounts in the same context as secondary entries
  • counts for distinct devices and related players

How to read it:

  • primary player sessions are highlighted as the main context
  • related account sessions are shown as linked context
  • clicking a related account session opens that account's player detail page

This is useful for overlap analysis (who was online at the same time and on which device context).

Implementation behavior to know:

  • session context is assembled from both device links and recorded session history
  • sessions without a valid end timestamp are rendered as a short placeholder block

Route map (movement and path reconstruction)​

When players.see_position is granted, the Routes tab is visible.

Route data is populated only when embedded logs are available (logs.view) and the current player/device context contains at least one usable username.

What it provides:

  • a detailed map rendering route segments from position pings
  • route time window filters (start / end)
  • multiple route toggles to isolate individual paths
  • route start/end markers and progression coloring

Default behavior:

  • if no route window is provided, end defaults to the latest known online ping (or current server time) and start defaults to end - 3 hours

Use cases:

  • tracing where a player moved across the map
  • checking repeated path patterns
  • correlating route windows with reports or incidents

Contact analysis (regular proximity to other players)​

In the Contacts tab, admins see players who were repeatedly near the target player.

The contact model is fixed and intentionally strict:

  • compares PLAYER_ONLINE_PING events at the same timestamp
  • analyzes a fixed rolling window of 14 days
  • uses a fixed 10 meter radius
  • requires at least 5 encounters before listing a contact
  • shows at most 15 contacts
  • excludes same-device player identities from contact output

What you get per contact:

  • contact player name
  • estimated shared playtime (minutes/hours, based on 5-minute ping steps)
  • first seen / last seen timestamps

This helps identify regular co-play partners and repeated association patterns.

Practical investigation flow​

  1. Start with Devices to map account relationships.
  2. Use Sessions to validate overlap windows.
  3. Use Routes to inspect movement in the same windows.
  4. Use Contacts to confirm repeated close-proximity relationships.

Combining these views gives stronger evidence than using any single tab alone.

Player impersonation​

Admins with players.impersonate_player can open the player view as that user. Use impersonation to validate what the player can see in the shop (missing buttons, opt-out warnings, feature access).

While impersonation is active, a one-line info bar is shown at the top in both the shop and the admin panel. The bar shows the currently impersonated player context and provides an Exit impersonation link in the top-right corner. The bar also uses small icons for quick visual recognition (impersonation context + exit action).

Exit behavior:

  • when impersonation is started from the player list, the exit link returns to the admin page where impersonation started
  • if no valid admin return page is available, exit falls back to the shop start page