KK_Plugins is a per-game plugin set that other mods can build against

Everything runs on BepInEx, and the install order is three dependencies

The plugin set is a layer on top of a modding runtime rather than a standalone application, and the installation sequence says so. You install the latest versions of three things first: BepInEx v5, the BepisPlugins release, and IllusionModdingAPI. Then you download the plugin release you want, making sure it is a version for your game, and extract the plugin .zip into the game folder, which is the folder holding the BepInEx folder and the game .exe. The dependency chain is worth internalising because it determines what a plugin can assume at runtime. BepInEx provides the loader that injects the plugin into the Unity runtime, BepisPlugins provides the shared plugin infrastructure, and IllusionModdingAPI provides the modding API that individual plugins build on. Several plugins name their specific prerequisites in their own entries, which is how you find out before installing that a plugin needs something beyond these three.

The release filename prefix is the game, and picking the wrong one wastes an evening

The release convention is simple enough to learn and important enough to get right. You download the version for your game, where the part before the separator is the initials of the game, with HS2 given as the example for HoneySelect2. The plugin repository covers Koikatu, Koikatsu Sunshine, EmotionCreators, AI Girl, HoneySelect2 and some other games. The set of games a single plugin supports therefore varies, and the prefix in the release name is the only thing telling you which. A second convention matters just as much. If a plugin is listed but its entry is not a link, then it is either experimental or obsolete, and the documentation is explicit that you will need to compile it from source yourself and you will not get any support. That is a useful signal: no link means no binary and no help, so plan on a source build before you promise a feature.

The repo is built for modders to interoperate with, not just to install

The repository is organised around two audiences, and the modder half is the part that distinguishes it from a list of zips. If you would like to create a mod that is compatible with various plugins in this repository, the documentation points you at the Guides folder in the repository and at the project wiki, and there is a template linked for the uncensor plugin specifically, showing how to configure your own content for compatibility with a plugin that expects a particular structure. The contribution path is the ordinary one: fork the repository, create a new branch, push your changes and open a pull request. The root layout shows the shape of the thing, with `src/` for the code, `tests/` for the tests, `mods/` and `libs/` for shipped and vendored artifacts, a `Guides/` directory, a `Directory.Build.props` file for shared build settings, a `nuget.config` and a `KK_Plugins.sln` solution, plus a `release.ps1` script.

Building it needs Visual Studio 2022 with three specific workloads

The build requirements are unusually specific, and they tell you what kind of project this is. To build the repository you need VisualStudio2022 or later with the `.NET desktop development` and `Game development for Unity` workloads, and `.NET Framework 3.5 development tools` plus targetting packs and SDKs for at least `.NET Framework 4.6`, with the advice being to install them all. All dependencies are downloaded via nuget on the first build of the solution, and the documentation points at the wiki if the build steps are failing. The release procedure is also documented: remove the old `bin\out` folder, rebuild the whole repository in Release configuration, and afterwards run release.ps1 to generate the combined zip files. So the build produces per-plugin binaries that are then packed into the distributable zips you download as a user. For a consumer this is invisible. For a contributor it means a full Visual Studio install, which is the main reason the wiki and the CI workflow exist as workarounds.

Nightly CI builds give you a plugin the release page has not published

There is a second source of binaries, and for modders it is often the practical one. The documentation says you can get the latest nightly builds of all plugins from the CI workflow, by opening the latest successful run and downloading the build from the Artifacts section. That is a meaningful difference from waiting for a tagged release, and the release numbering shows the cadence: v271 on 2026-09-10, v270 on 2026-06-03 and v269.1 on 2026-02-04. The plugins themselves are small and single-purpose, and the descriptions make the granularity obvious. CharaMakerLoadedSound plays a sound when the character maker finishes loading, useful if you spend the load time alt-tabbed. StudioSceneLoadedSound does the same for a Studio scene finishing loading or importing. ForceHighPoly forces all characters to load in high poly mode even in the school exploration mode. ReloadCharaListOnChange reloads the list of characters and coordinates when any card is added or removed from the folders, and supports adding and removing large numbers of cards at once.

Plugins that change what a character can wear touch the save format

A group of plugins is worth reading as one because they share a mechanism. ClothingUnlocker allows gender restricted clothing to be used on all characters, and also allows unlocking bras or skirts with any top on a per-character, per-outfit basis, with the setting saved and loaded with the character card or coordinate card to ensure compatibility. InvisibleBody sets the Invisible Body toggle for a character in the character maker to hide the body, with any worn clothes or accessories remaining visible, and it notes that the invisible state saves and loads with the scene. HairAccessoryCustomizer adds configuration options for hair accessories in the character maker, letting them match the hair colour, enable hair gloss, modify the outline colour and pick a separate colour for the hair tie part, with the length slider appearing for hairs that support it. ListOverride allows overriding vanilla list files, with the caveat that any part of a list can be changed except the ID, and the example use given is enabling bras with shirts or skirts with tops. All of these persist state into the game's own save data, which is why they are grouped in practice rather than in the documentation.

A plugin that depends on another mod has to be checked against it

The UncensorSelector entry is the clearest illustration of the interdependency problem, and it is worth reading in full before you install anything. The plugin lets you specify which uncensors individual characters use and removes the mosaic censor, either per character in the character maker or by setting a default in the plugin settings, and the default applies to any character that does not have one selected. Its stated requirements are three: Marco's KKAPI, Marco's Overlay Mods, and BepisPlugins with the ExtensibleSaveFormat and Sideloader pieces. For anyone making uncensors, there is a linked manifest template showing how to configure an uncensor for UncensorSelector compatibility. And the documentation ends with a warning that is easy to skim past: remove any sideloader uncensors and replace your oo_base with a clean, unmodified one to prevent incompatibilities. The Subtitles plugin, by contrast, has no such requirements and is scoped per game, adding subtitles for scenes, spoken dialogue and the character maker for Koikatsu, and for the character maker in the AI Girl trial version. The difference between the two entries is the difference between a self-contained plugin and one that shares state with other mods.

Where a plugin collection is the wrong answer

Two limits are worth stating plainly. The first is that this is a plugin set for games that are themselves niche and adult, and the practical cost of the whole arrangement is that every layer can be a source of failure. A plugin that misbehaves can be caused by the plugin, by BepInEx, by BepisPlugins, by the IllusionModdingAPI version, or by another mod that touches the same save data, and the diagnostics for that are the Discord channels rather than a stack trace. The second is the support model. The documentation says outright that a plugin listed without a link is experimental or obsolete, must be compiled from source, and comes with no support, and that the way to get help is the modding channels on the Koikatsu Discord server, where the pinned messages link to various modding guides. The alternative to weigh against is writing the mod yourself against the IllusionModdingAPI directly, with no plugin dependency to reconcile. The difference in approach is that a plugin gives you a solved problem in one file, at the cost of a shared save format and another version to track, whereas a private mod gives you exactly the behaviour you want with no coordination, and none of the interoperability work that the Guides folder exists to support. For a user who wants the feature, the plugin wins. For a developer whose mod is the product, the API is the better base.

Editorial conclusion

KK_Plugins is worth adopting if you mod one of the covered Unity titles and want small, focused plugins that behave consistently across game versions, because the release convention of one zip per game prefix and the nightly CI artifacts mean you can update a single feature without rebuilding your whole load order. It is a poor fit if you are not already inside the BepInEx and IllusionModdingAPI ecosystem, since every plugin here expects those two layers to be present and configured. It is also a poor fit for a project that needs a supported API, because the plugins whose downloads are missing are described as experimental or obsolete and come with no support. Before you build a mod against it, read the Guides folder for the specific plugin you want to interoperate with, check that a release exists for your exact game rather than assuming the prefix matches, and note that the last push to the repository was on 2026-10-13 with the most recent tagged release v271 from 2026-09-10.

Frequently asked questions

Official sources

1. IllusionMods/KK_Plugins on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases