Ready Up SDK
Write your own Ready Up plugins against a versioned C API that survives CS2 updates.
In development
The SDK is at API version 1.6 and Ready Up is not released yet. New minor versions only add functions, so a plugin built today keeps working on later 1.x cores.
The Ready Up SDK is how you add your own features to a Ready Up server. Everything Ready Up does beyond loading into CS2 is already a plugin built on it: the match flow, skins and the platform link.
What the SDK is
- A versioned C API. One header,
core/include/readyup/plugin_api.h. The core hands every plugin a table of function pointers (ru_api): chat and console commands, game events, log lines, center-screen HTML, players, entities and schema fields, server commands, config, admins. - Interfaces between plugins. A plugin can publish a struct of functions under a name, and other plugins can look it up. The match plugin publishes
readyup.match.v1(match_iface.h). The fleet plugin publishesreadyup.fleet.v1(fleet_iface.h), which other plugins use to talk to the Auto Tournament platform. The practice, whitelist and skins plugins publishreadyup.practice.v1,readyup.whitelist.v1andreadyup.skins.v1. Midas uses the skins interface to paint weapons gold. Any plugin can add its own lines toru selftest. - Hot reload.
ru plugin reload <name>swaps in a new build without a server restart. A plugin can keep its state across the reload. - A build setup.
readyup_add_plugin(<name> <sources>)in CMake sets every flag a plugin needs.
What plugins can and cannot do
Plugins never touch the engine directly. They cannot hook functions, scan for signatures, patch vtables or hard-code offsets. Every engine call goes through the core, and the core only uses functions it has found and verified with signatures and identity anchors.
That is the point. When a CS2 update moves something, the core gets a fix, often only a new engine-surface.json. Your plugin keeps working without a rebuild. If a function the core needs is not found, the matching API calls return 0 or NULL, and your plugin can check feature_state and carry on.
| Plugins can | Plugins cannot (yet) |
|---|---|
Register chat commands (.x, !x), console commands and ru <x> subcommands. Hide a command from chat, or watch a console command without taking it. | Hook engine functions, or block or change engine events before they happen. |
| Receive lifecycle events (map, round, player) and any engine game event by name. | Fire game events, or create entities. |
| Read every server log line. | Force a round to end. |
| Chat to everyone or one player, and show center-screen HTML to one player. | Show menus, or run commands on a client. |
| Look up players, entities, and schema fields by name. Set item attributes, knife subclass, models and bodygroups. | Read a cvar's value directly (set cvars with server_command). |
| Run console commands, stop rounds from ending during warmup, set a chat name prefix. | |
| Read settings, keep data files, decide who is an admin. | |
| Run their own threads, and hand results back to the game thread. |
If you need something from the right-hand column, see Asking for core support.
Start here
- Build your first plugin: build
hello, load it, hot reload it. - API reference: every function and interface.
- Threading and ABI: the rules that keep a plugin safe to load, run and reload.
- Examples: the four plugins in the repo, and what each one shows.
- Porting from CounterStrikeSharp or Metamod: how common concepts map to the SDK.
Engine surface is for people who work on the core itself.