SourceMod: scripting and administration for Source engine servers

A scripting layer bolted onto a running server

SourceMod is not a game and not a server implementation. It is the layer that gives a Source engine server a plugin system and an administration interface. The project describes itself as Source Engine scripting and server administration, and the repository is written in C++. The audience is two-sided. Server operators want menus for kicking, banning and changing map and game settings without console commands typed by hand. Plugin authors want a stable API and a scripting language they can pick up quickly. Both are served by the same artifact, which explains the shape of the repository: a core runtime, a set of extensions that add capability, and a sourcepawn directory that carries the language and its compiler. The project is hosted under the AlliedModders organisation, alongside the AMBuild tool it depends on.

The repository is a build graph, not a single program

The top level of the repository reads like a list of subsystems rather than a conventional C++ tree. Present are `core/`, `extensions/`, `bridge/`, `loader/`, `plugins/`, `sourcepawn/`, `public/`, `gamedata/`, `configs/`, `editor/`, `tools/`, `translations/` and `versionlib/`. Build configuration comes from `AMBuildScript` at the root, alongside `configure.py` and `product.version`, and the presence of `hl2sdk-manifests/` and a `.gitmodules` file shows the build pulls in engine SDK bits and other repositories as submodules. The README points to the wiki page Building SourceMod for instructions, and names AMBuild as the tool that does the work. That detail matters for adoption: compiling SourceMod is not a `./configure && make` exercise but a multi-repository, multi-toolchain operation, and the wiki page is where the real procedure lives rather than the README.

Extensions are the extension mechanism, and the bridge is the seam

Two directories in that layout carry most of the design. `extensions/` is where capability is added, and the README links to a SourceMod extension development category with C++ examples and an introduction to various extension interfaces. The `bridge/` directory sits next to it, and its name points at the difficult part of the whole system: SourceMod has to run inside a proprietary engine that ships as a closed binary, so the boundary between the engine and the runtime is a layer that has to be maintained against engine updates. `gamedata/` sits alongside it, holding the game-specific data the runtime reads to describe things like weapons and entities. Extensions are also the mechanism through which new languages would be added, which is why a scripting runtime and its extension interface are documented as separate topics in the wiki.

SourcePawn is the language plugin authors actually write

The `sourcepawn/` directory and the topics list, which includes sourcepawn, point at the language that plugin authors use day to day. The README links to a SourcePawn scripting category with examples and an introduction to the language, and to an online plugin API reference generated from the include files. That last link is the important operational detail. The API reference is not written by hand and is not a stale page, it is generated from the include files in the tree, which means the documented surface and the compiled surface are the same thing. Plugin authors work against that reference, and the `plugins/` directory at the repository root holds the plugins that ship with the runtime. The `editor/` directory suggests editor integration is part of the delivered product rather than a third-party add-on, which matters for people writing plugins in an IDE.

Translations and per-server configuration ship with the runtime

Two directories cover everything that is specific to a deployment rather than to the code. `translations/` and the `configs/` directory hold language files and server configuration, and the README links to a translation project under the AlliedModders organisation, asking for help translating SourceMod into your language. The wiki has a dedicated page for SourceMod scripting translations, which confirms that localisation is handled at the level of the scripting layer rather than left to server owners. In practice this means an operator running a non-English community server has a supported path to a translated interface, and the cost of a missing translation falls on the community rather than on the core runtime. The `tools/` directory sits next to these, and `changelog.txt` at the root gives a plain-text history of changes.

Where SourceMod is the wrong tool

The scope boundary is clear and easy to trip over. SourceMod extends a Source engine server that already exists; it does not provide a server, a game, or a networking stack of its own. If your project needs a game from scratch, a dedicated backend, or a service that runs without a game client connecting to it, none of this applies. There is also a version coupling worth naming. Because the runtime has to speak to the engine binary, engine updates are a forcing function for the whole stack, and the release numbering shows how tightly the project tracks its host. The README's split between stable builds and dev builds at the downloads page is the practical boundary: a stable build is what a running community server wants, and a dev build is for people who intend to compile plugins against an API that may still change.

The alternative: extending the engine through a native plugin instead

The real alternative is writing against the engine directly. A native C++ plugin for the Source engine can hook the same engine events, but it has to be compiled for the target platform, it loads into the server process as a machine-code module, and it inherits the server's crashes and memory behaviour. SourceMod takes the opposite route. Plugins are written in SourcePawn, a compiled scripting language, loaded by the runtime rather than injected as native code. The trade-off is capability and stability. A native plugin can do things a SourcePawn plugin cannot, and it can break in ways a managed plugin will not. A SourcePawn plugin runs on any platform where the runtime runs, which is why a server can move between operating systems without recompiling its plugin set.

Release cadence, licence and the cost of staying current

The project is not archived, and the last push was on 2026-10-18. The most recent release is 1.13.0.7478 on 2026-10-15, 1.13.0.7477 on 2026-10-08 and 1.13.0.7476 on 2026-10-07. The 1.13 series number staying constant while the trailing build number climbs tells you the versioning model: a stable minor line with frequent build increments inside it, so operators track a build number rather than a feature release. On the licensing side the README states that SourceMod is licensed under the GNU General Public License version 3, and that special exceptions are outlined in the LICENSE.txt file inside the licenses folder. Those exceptions are part of the terms, and the repository ships a `licenses/` directory, so anyone redistributing a build should read that file rather than relying on the one-line licence summary.

Editorial conclusion

Adopt SourceMod when you run a Source engine server and need server administration plus a plugin ecosystem, and you are prepared to depend on a C++ core that moves with Valve's engine updates. Skip it if you need a web backend or a game built from scratch, because SourceMod extends an existing server rather than providing one. Before committing, download a stable build from the sourcemod.net downloads page rather than a dev build, and read the special exceptions in the licenses folder LICENSE.txt, because SourceMod ships under GPL version 3 with stated exceptions that are not visible from the licence line alone.

Frequently asked questions

Official sources

1. alliedmodders/sourcemod on GitHub
2. Issues
3. Project website
4. README
5. Releases