plugin-sdk: a C dev-kit for GTA San Andreas, Vice City and GTA III plugins

Five games, one shared core, and a directory layout that shows the seams

Plugin-SDK describes itself in the README as a dev-kit for creating plugins for GTA2, GTA3, GTA: Vice City, GTA: San Andreas and GTA:IV. The repository layout is where the real design shows. At the top level sit plugin_II, plugin_III, plugin_IV, plugin_vc, plugin_sa and three sibling directories named plugin_iii_unreal, plugin_vc_unreal and plugin_sa_unreal, alongside shared, hooking, injector, modutils, safetyhook, stb, tools and examples.

The naming makes a reasonable inference. The per-game directories mirror the Roman numeral conventions of the series, so plugin_sa is the San Andreas layer, plugin_vc the Vice City layer and plugin_III the GTA III layer, while plugin_II and plugin_IV cover the oldest and newest titles the README lists. The shared directory is the piece that cuts across all of them, and the three underscore suffixed directories look like parallel implementations for an engine variant of the same titles.

That structure is the practical answer to the question the README leaves open. It is not one library that abstracts over every game, because the split is per game with a shared layer underneath. If you write a plugin against plugin_sa, you are compiling against a surface specific to that game rather than a portable API you can reuse unchanged in another title. The README does not document how much code actually lives in shared versus the per-game layers, so treat any expectation of easy porting between San Andreas and Vice City as unverified.

The primary language is C, and the licence is Zlib, which is permissive and short. It is the kind of licence that lets a commercial or closed-source plugin ship without much ceremony, though the notice requirements are yours to check.

The README is a pointer to a wiki, not an installation guide

If you came here for build instructions, the README does not contain any. It gives three steps, each one a link into the project wiki rather than a command you can copy. The first is to install a development environment, the second is to copy plugin-sdk to your computer and set it up, and the third is to create your first plugin. The wiki pages are titled Installing development environment (IDE), Set up plugin sdk and Creating a new plugin in plugin sdk.

So the honest answer to how to install this project is: the project says to read those three wiki pages, and it says nothing else about compilers, IDE versions, project files or SDK directories. No build command appears in the README, no package manager entry is named, and no configuration file is shown. The top-level listing does contain a tools directory and an installer-launcher.exe at the root, but the README does not explain what either is for, and guessing at their purpose would be reading intent into filenames.

That is the single biggest practical difference between this project and a typical modern SDK. There is no one-command onboarding, and a first-time user is expected to read three wiki pages and follow them. Anyone evaluating plugin-sdk for a team should read those pages first, because the wiki is where the real setup contract lives, and the repository itself is mostly source.

For day to day communication the README points at a Discord server, listed separately for English and Russian readers. That is the support channel, and it is a chat server rather than an issue tracker.

The examples tree is the closest thing to an API catalogue

Since the README keeps the API in the wiki, the examples directory is where you can read what the SDK actually exposes. The listing carries about two dozen projects under examples/, and their names read like a map of the callable surface: CreateCar, VehicleSpawner, PedSpawner, PedPainting, RotateDoor, OpenDoorExample, PlayerWeapon, VehicleRemap, FullNitrousControl, HandSignals, Neon, ColouredObjects, DXFont, GPS, ScriptDrawsTest, ScriptCommands, Speedometer, Texture, TimeNotTouchingPadOpcode, UniversalTurnlights, DecisionMaker, Test and UnitTests.

Read those as categories of work rather than a formal API listing. ScriptCommands and ScriptCommands-adjacent folders suggest the SDK can reach the game's script command system, opcode-oriented folders such as TimeNotTouchingPadOpcode suggest direct access to individual game operations, and folders like Texture, DXFont and Neon point at the rendering side. UnitTests is worth a second look because it tells you the project has a place to put assertions, though the README does not say whether the suite is run in CI, and the repository does contain a.github directory.

There is also examples/examples.csv at the top of that directory. A CSV listing example projects suggests the examples are tracked in a machine readable list, which is how a build system or an index would pick them up. The README does not describe the file format or its columns.

For a developer choosing this SDK, the examples are the fastest way to judge coverage. If the game feature you need to touch has a matching example, the surface area exists and the plumbing is proven. If it does not, you are looking at writing the low level part yourself, which is exactly what the SDK was supposed to save you from.

Hooking, the injector and safetyhook carry the stability risk

Three top-level directories name the mechanics the SDK depends on: hooking, injector and safetyhook. The injector is what gets a plugin into the running game process, and hooking is what lets the plugin intercept and extend game behaviour. safetyhook is a separate vendored-looking directory that appears to provide the interception layer the other two rely on.

Here the README goes quiet. It does not explain which interception technique is used, what happens when a game patch changes the addresses being hooked, or whether the injector requires any particular launcher. That silence is the risk to price in. A plugin SDK whose layers cover five games and at least two engine variants has to hook code that a shipping game may repoint at any time, and the presence of a README_breaking_changes.md file at the repository root is itself a signal that the API surface moves.

The modutils directory suggests additional tooling for loading and managing mods, and injector-launcher.exe sits at the root, which points to a Windows-oriented flow for getting code into the game. Again, the README does not document either. The takeaway is practical: treat this as a source-level dev-kit that you integrate, compile and debug yourself, and expect to read the wiki and the source rather than to run an installer.

The Unreal suffixed directories hint at a second engine target

Sitting next to plugin_iii, plugin_vc and plugin_sa are plugin_iii_unreal, plugin_vc_unreal and plugin_sa_unreal. The names are the only evidence, since the README does not mention them, but the pattern is clear enough to state as an observation: for each of the three classic titles there is a directory whose name differs only by the Unreal suffix.

That suggests the SDK carries parallel bindings for a version of those games built on a different engine, and it explains the presence of an injector in the first place, because loading code into an Unreal-based game is a different problem from hooking the RenderWare-era originals. Whether the Unreal variants are complete, experimental or abandoned cannot be determined from what is available here. The README does not list them among its supported titles, which lists GTA2, GTA3, GTA: Vice City, GTA: San Andreas and GTA:IV but not an Unreal-based game.

If your target is one of the newer engine versions, this is the first thing to check in the tree, and the second thing to check is whether the corresponding wiki page exists. A directory that exists in the source without documentation is common in long lived modding projects, and it usually means the feature is in progress rather than supported.

No releases, a long contributor list, and a last push in September 2026

The repository has no GitHub releases at all. There is no version tag to install, no changelog on the releases page and no packaged artifact. The README itself points readers to the wiki for setup, which is consistent with a project that expects people to clone and build against the current branch.

Maintenance is clearly active rather than abandoned: the last push was on 2026-09-08. The contributor section is long and, notably, organised by era. It separates maintainers of new versions (Crspy, DK22Pac, FrogByteDQ, _AG, quiret, kenking, LINK/2012) from maintainers of old versions (DK22Pac, fastman92, SilentPL, LINK/2012), and it credits named individuals such as Deji, listener, Wesser, Den_spb, Seemann, Alien and Ryosuke, plus the MTA Team, sannybuilder.com guys and gtaforums.com coders.

That roster tells you two things about the upgrade cost. The work has been passed between several maintainers across two eras, so knowledge is spread rather than concentrated. And the credits to community collectives and forum communities mean the SDK inherits conventions from tools and modding scenes that predate it, which is useful context if you are coming from CLEO scripting and surprising if you are not.

One more file deserves attention before you commit to a version: README_breaking_changes.md. Since there are no tagged releases to fall back on, that document and the git history are your only way to see what changed between the commit you built last week and the one in front of you now.

Editorial conclusion

Plugin-SDK suits C developers who already know the GTA modding scene and want typed access to game internals for San Andreas, Vice City or GTA III rather than raw memory offsets. It does not suit anyone who needs a reproducible, versioned toolchain, because the repository publishes no GitHub releases at all and the last push was on 2026-09-08. Before adopting it, check that the wiki page named in the README, the setup page and the new-plugin page, matches the state of the source tree you cloned, and read README_breaking_changes.md to see what the maintainers changed underneath the API. If you need stable versioned artefacts, you will have to pin your own commit, because the project gives you no tag to pin to.

Frequently asked questions

Official sources

1. DK22Pac/plugin-sdk on GitHub
2. Issues
3. License: Zlib
4. README