Introduction

Build plugins for TitanClient using the native C++ SDK or the JavaScript scripting API.

What is TitanClient?

TitanClient is a native OSRS client built from the ground up in C++20. It injects into the official game process and provides a rich plugin system that lets developers extend the client with custom overlays, automation helpers, and game-state readers — without modifying game code.

The plugin system is the primary extension point. Every feature in TitanClient — from tile overlays to combat helpers — is built as a plugin using the same SDK available to third-party developers.

Two Plugin Types

TitanClient supports two kinds of plugins, both with access to the same game-state queries and rendering primitives:

Native C++ DLL JavaScript (QuickJS)
Language C++20 (MSVC) JavaScript / TypeScript
Runtime Native DLL loaded into the game process Executed in an embedded QuickJS engine
Hot-reload No — requires restart to reload Yes — file watcher reloads on save
Performance Full native speed, direct memory access Sandboxed with a 1M opcode budget per callback
Best for Performance-critical plugins, low-level hooks, complex state machines Rapid prototyping, overlay scripts, simple automation
Build toolchain Visual Studio 2022, CMake, vcpkg Any text editor (optional: tsc for TypeScript)

SDK Architecture

The SDK is organised into three orthogonal groups of entry points. Every public symbol lives under exactly one:

Shape C++ Namespace TS Namespace What it is
Queries titan::queries::* titan.queries.* Chainable, filterable list views over live game collections (NPCs, players, objects, inventory, etc.)
State titan::state::* titan.state.* Facades that read or manipulate a specific subsystem (client, camera, skills, prayers, vars, walk, widgets, etc.)
Utils titan::utils::* titan.utils.* Header-only helper namespaces for common tasks (inventory predicates, dialogue, combat, equipment, bank)

Free helpers that are not subsystem facades live at the top level: titan::log, titan::logf, titan::addChatMessage, titan::runOnClientTick, titan::runOnRender, plus the registration macros and titan::Plugin itself.

SDK Versioning

The SDK uses a numeric version tracked via two constants in the ABI header:

Constant Current Value Meaning
kSdkVersion 46 The latest SDK version. Plugins built against this version get access to all current features.
kMinSupportedSdkVersion 41 The oldest SDK version the client will still load. Plugins built against older versions are rejected.

Compatibility window: Plugins must advertise an sdkVersion between kMinSupportedSdkVersion and kSdkVersion (inclusive) as defined in the ABI header at build time. Additive SDK bumps (new fields, new HostApi tail calls) do not break existing plugins — only a major reshape (like the v41 restructure) or a raised minimum version narrows the window.

When the client updates with a new SDK version, your plugin continues to work as long as its version falls within the supported range. You only need to rebuild when kMinSupportedSdkVersion moves past the version your plugin was compiled against.

Plugin Loading

During development, place your compiled DLL or .js file in %USERPROFILE%\.titanclient\plugins. The plugin host picks it up automatically on the next client launch. If two plugins share the same ID, the first one found wins.

Published plugins are delivered to end-users automatically through the controller — no manual file placement required.

Next Steps