Mounts

Available from update 0.1.6. The server, rider and observers require matching 0.1.6 / Protocol 38 packages.

Server-side Lua API

Function	Purpose
createPlayerMount(playerId)	Request one native rideable scavenger for the specified connected, eligible player.
destroyPlayerMount(playerId)	Request removal of the mount created by this resource for that player.

These names are case-sensitive Lua bindings. No uppercase aliases, mount getter, mount-ready event, ownership-transfer function or mounted-attack API are added.

Example

Call after your gamemode has authenticated and spawned the player and the server has received their movement state:

-- Server-side, after YOUR permission/readiness checks:
local requested = createPlayerMount(playerId)
if not requested then
    outputChatBox("Mount request was not accepted.", playerId)
end

-- Later, from the SAME resource, when removing the animal:
-- destroyPlayerMount(playerId)

Creation returning true means the request was accepted for delivery, not that the native actor has finished spawning. Do not assume success implies a mount handle, a completed animation, or immediate readiness. There is no completion callback in this API. Avoid retrying every frame. In the current implementation the animal is created near its owner; model, position and rotation are not arguments.

Use the game's ordinary interaction to mount/dismount. Natural dismounting is different from destroyPlayerMount, which ends the owned mount session and requests removal after safe native detachment. The native riding gate supplies the temporary riding-skill contribution needed by this session and removes only its own contribution during cleanup. Other native restrictions, including location restrictions observed in camps, remain in force.

Ownership and lifetime

• One active mount per player; independent players can own mounts concurrently. There is no separate global mount-count cap in this subsystem; normal server/player/resource limits still apply.
• The creating resource owns removal. Another resource cannot destroy its active mount. A removal request can succeed as a no-op if no active lease remains.
• The owner is the current connection's player ID. There is no automatic database persistence, reconnect restoration, lending or ownership transfer. A gamemode must decide when to request a new mount after reconnect/spawn.
• Healthy mounts have no fixed age-based lifetime and no automatic two-minute despawn. Manual removal, owner disconnect, resource stop, lost observation, world/life-state/eligibility changes still clean up the session.
• Creation requires a connected, authenticated, spawned player with a movement snapshot and negotiated mount support. Frozen players and players awaiting an authoritative position acknowledgement are not eligible. A second creation while a lease exists is rejected.
• Native cleanup waits for the admitted human to be safely detached/restored; it does not forcibly teleport or destroy the animal underneath an attached rider.

Synchronization and presentation

• The owner uses the native rideable actor and native input/animations. Other clients receive a passive visual animal and the synchronized rider; they cannot mount that observer-only visual or use it as an independently authoritative physics actor.
• Animal and rider use a shared presentation sample for position, rotation and animation time. Supported presentation includes standing/riding movement, walk/run/sprint, jumping/swimming, mounting and dismounting.
• Late join and entry into synchronization range receive current state. Leaving range hides the observer presentation, rather than transferring ownership or destroying the owner's animal merely because another viewer moved away.
• The server authenticates the reporting connection and checks ownership, sequence, finite transforms, proximity and movement against its existing collision registry. This does not import the entire native world's collision geometry into the server.
• Ordinary foot orientation is restored after dismounting. Nameplate refresh remains active during riding, using the presented human's position and the existing visibility/privacy rules.

Received hits and recovery

The mounted-pair guard preserves authoritative HP damage and impact effects while avoiding independent foot displacement/reaction animations that would separate rider and animal. Fatal/manual cleanup uses native dismount/handover. This is received-hit handling, not an API for attacking while mounted.

Initial boarding has a bounded transition grace and is not treated as a broken established seat just because possession changed before the capsule reached the saddle. Healthy riding does not periodically expire. See Scripting limits for readiness/observation/recovery timeouts; these are safety timeouts, not maximum ride duration.

Petting and verification status

Paired petting presentation is implemented for native standing/crouching human and standing/lying animal variants. It follows native interaction/animation playback; there is no force-pet Lua function. Ordinary instance interaction availability may be repaired for the exact owned animal, but native force-disable/other eligibility gates are not overridden.

The heart interaction's availability still needs final in-game confirmation. Do not assume it is universally unlocked. The latest mounted-hit, boarding-recovery and nameplate changes also need final two-client gameplay validation; automated regression tests have passed but cannot prove all retail visual transitions. Earlier riding and multiplayer presentation were exercised during development.

See Update 0.1.6 for the complete release change list.