Ultimate ASI Loader: the DLL that teaches a game to load .asi plugins

What the project is, in one sentence

The repository description says it plainly: a proxy DLL that loads custom .asi libraries into any game process. The readme narrows that claim and the narrowing is the most useful thing in the documentation. It says the DLL adds ASI plugin loading functionality to any game that uses any of the listed libraries, and the list is a table of Windows system DLLs spanning Direct3D 8 through Direct3D 12, the DirectX graphics infrastructure interface, two DirectInput variants, DirectSound, and a group of the older multimedia libraries.

That distinction matters more than the marketing sentence suggests. A proxy DLL works by replacing a library the target executable already imports, then forwarding every call to the real library while doing its own work alongside. Which library you can replace is therefore not a preference, it is a hard constraint set by the game's own import table. A game that statically links its renderer cannot be intercepted this way no matter how capable the loader is, and the matrix is the honest statement of which games qualify.

The language is C++, the license is MIT, and the project sits at 2292 stars and 153 forks with a single open issue. A one-open-issue count on a repository of this adoption is unusual, and the likely explanation is the shape of the deliverable. This is not a library that people file bugs against, it is a set of binaries they download, place next to an executable, and either work or do not.

One binary per system library, not one universal download

The delivery model is the first real thing to understand. There is no installer and no single artifact. Each row of the matrix is its own release asset, named after the library it proxies and suffixed with the architecture, and each link points at a rolling tag rather than a version number.

The rolling tags are Win32-latest and x64-latest. That means the download URL for a given library never changes, and what you get is whatever the most recent CI run produced on that architecture. For a modding tool this is a reasonable trade: users install once and receive updates without tracking release notes. For anything in a scripted or reproducible setup it is a problem, because the URL does not identify a version and there is nothing in it you can pin.

The matrix also tells you which combinations exist. Some rows have a single dash, meaning no build for that architecture. The Direct3D 8 row, the DirectDraw row, and several of the older multimedia rows are Win32 only, which reflects the fact that those APIs died before 64-bit Windows became the default. Direct3D 9 through 12, dxgi, dinput8 and dsound have both.

One detail is worth flagging because the documentation does not explain it. dinput and dinput8 are listed as separate rows with separate archives. A game importing one name will not load the loader built for the other, and picking the wrong row produces a game that starts normally and silently ignores your plugins. If you are unsure, check the import table of the game executable rather than guessing from era.

What the repository tree says about the build

The tree is a Windows native toolchain and it is worth reading as a description of how the maintainer works.

The build front end is premake5, with premake5.lua as the project definition, plus premake5.bat and a bundled premake5.exe. Committing the generator executable alongside the scripts is a choice that trades reproducibility for convenience: anyone cloning the repository on Windows can generate projects without installing anything, but the binary in the tree is the one you get rather than one you verify.

Release packaging is a set of batch scripts. There are release-Win32.bat, release-x64.bat and a release.bat that appears to drive both, with release.ps1 alongside them. Signing has the same pair, sign.bat and sign.ps1, and embedpdb.bat with embedpdb.exe handles program database embedding, which matters for shipping symbols with the binaries. The archive step uses 7za.exe, committed to the tree, so the zip format of the published assets is fixed by a tool version rather than by whatever the runner happens to have.

Continuous integration is the older AppVeyor shape. appveyor.yml sits at the root and the readme carries an AppVeyor build badge alongside a GitHub Actions msbuild badge, so both systems are wired up. A .gitmodules file and an external directory mean some dependencies arrive as submodules rather than being vendored directly.

The data directory and the tests directory are the two entries that hint at intent rather than mechanics. A tests directory means there is automated coverage of some kind, which is worth noting for a project whose readme offers no engineering narrative at all. A data directory suggests shipped resources, plausibly configuration. Neither is explained anywhere in the documentation.

The readme is mostly sponsors, and the table is the whole manual

The documentation for a 2292-star project is thin in a way worth describing accurately rather than exaggerating. The readme is dominated by a block of sponsor and social links near the top: a Patreon progress banner, GitHub Sponsors, Ko-fi, PayPal, Patreon and Boosty buttons, then Discord, Telegram, YouTube and X icons. After that comes a two-sentence description, a heading, and the library table.

There are no install instructions. There is no configuration reference. There is no section on writing a plugin, no compatibility list of specific game titles, no troubleshooting, and no statement about which .asi file naming convention is expected. The related search terms for the project are almost entirely game titles, Ultimate ASI Loader RDR2, GTA 4, Starfield, GTA SA, Bully, Sims 3, Crimson Desert, which tells you where the actual user documentation lives. It is not here.

The matrix itself also does not end cleanly in the stored copy. The available text stops partway through the final visible row, in the Direct3D era naming with an entry beginning ver, so the last library name and its Win64 status cannot be confirmed from this copy of the readme. If you need the complete row, read the readme on the master branch, because the answer is definitely there.

So the practical reading advice is straightforward. Use the table to pick a binary, use the release assets to download it, and use the project issue tracker and the maintainer's linked communities for everything else. This is a working tool distributed by someone whose primary documentation surface is somewhere else.

Three 2026 releases whose notes repeat the readme

The releases are v9.7.2 from 2026-06-02, v9.7.3 from 2026-08-14 and v9.7.4 from 2026-08-16. The most recent push to master is dated 2026-09-28, which is about six weeks after the last tagged release, so development on the branch is ahead of what the tags describe.

Here is the gap worth knowing about before you rely on those versions. All three release descriptions begin with the same sentence as the readme and then reproduce the same library table. None of them says what changed. For a numbered patch series where the third release came two days after the second, a reader has no way to learn whether v9.7.4 fixes a crash, adjusts proxy behaviour for a particular library, or only rebuilds against a newer toolchain.

That is not unusual for this category of project, where the interesting changes live in the source diff rather than in the notes. But it does mean version selection is guesswork, and it reinforces the rolling-tag behaviour of the download links: users are expected to take the latest build rather than choose. If you need to know what a specific version contains, the tag comparison in the repository is the only source.

The topic list is four entries long and all of them are the project's own name in variants: asi, asi-loader, asi-plugins, asiloader. A topic list that only repeats the project name adds nothing to search or discovery, which is a small missed opportunity for a project whose name is generic enough to collide with unrelated search results.

Choosing between this and the alternatives

Search interest around ASI loaders splits along lines that this repository does not address. The recurring question is whether a silent loader or a loader of this kind is better, and the honest answer is that they solve different problems rather than competing at the same one.

A silent loader, in the sense that phrase is used in this scene, hides its presence from the game so that plugin code is less likely to be detected by anti-cheat or by a game that checks its own module list. That is a different goal from broad compatibility, and it comes with a different risk profile, since anything designed to evade a game's integrity checks is a decision about account safety rather than about modding. This project does not claim that behavior, does not mention it, and its documentation is entirely about which libraries it can proxy.

For the practical question of installing a loader on a specific game, the sequence is short. Find out which system libraries the game executable imports, match those against the matrix, download the archive for that library and architecture, extract it into the game directory, and place your .asi files alongside. If the game imports several proxied libraries, the more relevant one is generally the graphics library since that is what almost every mod hooks, but the archives are built independently and you can install more than one.

If a game is not in the matrix and does not import any listed library, no version of this loader will work on it. That is the honest boundary of the project, and the repository's own documentation is the place to confirm it.

Editorial conclusion

Adopt Ultimate ASI Loader when you want to attach .asi plugins to a Windows game and you know which system library that game imports. The project is a per-library binary rather than a single installer, which means the first decision you make is which row of the matrix your title needs, and a game that statically links its renderer is out of scope regardless of how popular it is. Two things to verify before you commit. The repository description promises a loader for any game process while the documentation only supports games that use one of the listed libraries, so treat the library matrix as the real scope. And the published releases, v9.7.2 through v9.7.4, carry the same prose as the readme rather than a change list, so if you need to know what a version changed, read the diff between tags in the source tree.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ThirteenAG/Ultimate-ASI-Loader on GitHub