Code addons
Build host and client systems against the public LitheraRP addon SDK without forking the gamemode.
Capability matrix
Every row below has a supported path in the current SDK. The last column names the API that owns lifecycle and authority for that path.
| Area | Status | Supported path |
|---|---|---|
| Host and client code | Supported | Targeted Addons, explicit realms and a matching protocol version. |
| Dependency ordering and conflicts | Supported | Required and optional SemVer dependencies, deterministic ordering and conflict rejection. |
| Pawn creation and spawn rules | Supported | PlayerSpawnRequested, pawn composition, loadout pre-hook and loadout post-event. |
| Inventory and hotbar policy | Supported | Universal mutation transaction with explicit authority. Core backpack, reserve-ammo and weapon-clip mutations are host-owned. |
| Jobs, items, shops and clothing | Supported | Register, replace or suppress with reversible priority layers. |
| NPCs and world content | Supported | Runtime NPCs, custom kinds, decorators, replacements, Toolgun modes and owned objects. |
| Doors, vehicles and seats | Supported | Cancelable door, lock and seat policy, including host-authorized voluntary exit, plus committed events. |
| Combat and destructibles | Supported | Local weapon prediction hooks, host-authoritative fire and reload policy, correlated retraced hits, player damage and core world damage or destruction. |
| Voice, chat and phone | Supported | Voice routing, chat policy, commands, calls, messages and phone apps. |
| UI and admin tools | Supported | Tracked screen panels, permission-aware admin pages and core panel control. |
| Custom networking | Supported | Namespaced JSON messages before or after pawn creation, with byte caps, rate limits and optional host permission checks. |
| Persistent data | Supported | Player, server and world documents with schema migration and atomic writes. |
| Inter-addon APIs | Supported | Typed versioned services, local JSON events and declared dependencies. |
| Hot apply and disable | Supported | Context-managed registrations unwind immediately and inactive managed resources are filtered. |
| Client readiness | Supported | Snapshot fingerprint acknowledgement before initial pawn creation, with failure and timeout handling. |
| Sensitive admission override | Supported | Requested plus operator-granted capability for the whitelist stage only. Bans and server authorization remain final. |
Choose a page
- Getting started builds the smallest valid code addon.
- Manifest and dependencies defines identity, realms, versions, conflicts and capabilities.
- Lifecycle and readiness explains activation order, async loading and teardown.
- Context API lists every public context member and where it can run.
- The three hook pages document all
LitherarpGameEventschannels and payloads. - Networking, persistence, services, registries, UI, security and troubleshooting each have a focused reference page.
Scope and engine boundaries
An addon compiles against public LitheraRP and s&box types. The stable addon SDK is ILitherarpAddon, LitherarpAddonContext, LitherarpGameEvents and the public payload or entry types used by those APIs. Other public game types can change with a game update.
The table describes supported LitheraRP paths, not unrestricted interception of engine calls. Core-required pawn components remain mandatory. Hooks on local input expose IsHostAuthoritative when the decision may run on a predicting client. An addon-owned container, component or RPC remains the addon's responsibility unless it uses an SDK funnel.
Disabling removes context-managed behavior and filters resources owned only by inactive managed packages. s&box does not provide a safe in-process package byte unload, so mounted bytes and addon assembly static fields can remain cached until restart. This does not keep a disabled context registration active.