Offline Players ​

An OfflinePlayer is a player the server has seen before — online or not. It carries identity (name, UUID), seen-store timestamps, and a bridge back to a live Player when one is connected. Every online player is an offline player: Player is a subtype of OfflinePlayer, so every row and function below accepts a live Player directly.

set found to offline_player("Notch")
if found exists {
    send "<gold>${found.name}</gold> — last seen ${found.last_seen}" to sender
    if found.player exists {
        send "<green>Someone looked you up!" to found.player
    }
}

The OfflinePlayer value ​

The player bridge is the crossing point between the offline and online worlds. It is an optional<Player>, so narrowing with exists is what turns an offline record into a live player you can message, teleport, or give items to — no null, no guessing.

Player is an OfflinePlayer ​

Because Player <: OfflinePlayer, a function that takes an OfflinePlayer accepts an online player, and is a Player narrows an offline value to the live type where it applies:

function describe(subject: OfflinePlayer) {
    if subject is a Player {
        send "you are online right now" to subject
    }
}

Builtins ​

offline_player answers instantly from the local seen-store and is safe on the tick thread. fetch_offline_player reaches out to Mojang over the network, so it is async-only — call it inside an async command or block:

command "lookup" {
    arguments {
        who: String
    }
    execute async {
        set fetched to fetch_offline_player(args.who)
        if fetched exists {
            send "${fetched.name} = ${fetched.uuid}" to sender
        } else {
            send "no Mojang account named ${args.who}" to sender
        }
    }
}

Persistent data for anyone ​

Persistent variables can be keyed by Player or by OfflinePlayer — and because both key by the same UUID string, the two spellings are interchangeable at the storage level. A value written through a Player subject reads back through an OfflinePlayer subject with the same UUID, and vice versa. In practice there is one rule: player-keyed persistents accept either subject.

persistent balance for Player: Integer = 100
persistent visits for OfflinePlayer: Integer = 0

command "reward" {
    arguments {
        who: String
        amount: Integer
    }
    execute {
        set target to offline_player(args.who)
        if target exists {
            // 'balance' is declared 'for Player' but takes the OfflinePlayer subject
            set balance for target to balance for target + args.amount
            send "paid ${args.amount} to ${target.name}" to sender
            if target.player exists {
                send "<green>+${args.amount} coins!" to target.player
            }
        }
    }
}

This is the whole point: you can pay, ban, or credit a player who is offline right now, and the moment they log in the same store is live for them.

Coming from Skript ​

Skript leans on %offline player% and uuid of scattered through your code, with a live-player fetch that may quietly fail. SwoftLang makes the offline record a real typed value and the live crossing a checked exists:

# {balance::%uuid%} works offline; getting a live
# player to message them might return <none>
command /reward <offline player> <integer>:
    trigger:
        add arg-2 to {balance::%uuid of arg-1%}
        send "&7Paid %arg-2% to %arg-1%" to player
        arg-1 is online
        send "&a+%arg-2% coins!" to arg-1

persistent balance for Player: Integer = 100

command "reward" {
    arguments {
        who: String
        amount: Integer
    }
    execute {
        set target to offline_player(args.who)
        if target exists {
            set balance for target to balance for target + args.amount
            send "<gray>Paid ${args.amount} to ${target.name}" to sender
            if target.player exists {
                send "<green>+${args.amount} coins!" to target.player
            }
        }
    }
}

# Skript has no first-class "everyone seen" list;
# you maintain {seen::*} yourself on join
on join:
    add player to {seen::*}

command "census" {
    execute {
        loop all_seen_players() as p {
            send "${p.name} <gray>last seen ${p.last_seen}</gray>" to sender
        }
    }
}

How the seen-store works ​

The seen-store rides whatever storage backend you configured — the same write-behind cache as your persistent variables. It records name, first_seen, and last_seen per UUID, updated when a player joins and when they disconnect, and it survives a backend switch like any other persistent data. Every offline_player(...) and all_seen_players() call reads it in memory, so lookups never touch disk on the tick thread.