Installing APIAPI's Interaction Kit

Assumes you have finished quick-start.

Supported engine versions

The kit ships one archive per engine version and supports the newest three: 5.6, 5.7, 5.8. Install the archive that matches your engine — an archive built for another version will not load.

This list always names exactly the engine versions with a live archive. When a version is about to leave it, you get 60 days' notice: one line is added in this section — Deprecated: UE <version> — supported until <date> (60-day notice) — and the identical line is posted in the Fab listing's description and in that update's Version Notes. This file ships inside your archive through the /Docs/... folder rule of Config/FilterPlugin.ini.

Supported install locations

There are exactly two supported locations, and the kit behaves identically in either one. Nothing in the kit reads its own install path, and no feature, test or default changes between them.

Any other location is unsupported — not because it will necessarily fail, but because it is not tested and no behaviour is promised there.

"Behaves identically" is a measured claim, not a design intention: the plugin's automation suite is run headless (-nullrhi -unattended, Automation RunTests UK.Interaction) from each of the two locations in turn, and the two runs must report the same pass count and that count must equal the suite total. Two runs that agree at zero — the shape you get when the suite never loaded — are a failure, not a match.

Enable the kit in Edit → Plugins → Gameplay → APIAPI's Interaction Kit and restart the editor. The plugin is not enabled by default (EnabledByDefault: false).

Do not install it in both at once

Installing the kit in both locations at the same time is unsupported and is reported by the editor validator as an Error, UK-VAL-011, naming both paths. The kit relies on no precedence rule and does not detect its own duplication at runtime.

Measured on UE 5.8: a duplicate install does not produce a loud failure. The engine picked one copy silently, and the project copy won — so an outdated copy under <Engine>/Plugins/Marketplace/ is simply ignored while a stale copy there combined with a removed project copy silently reverts you to the old version. That is precisely the "my fix did not apply" support ticket UK-VAL-011 exists to prevent. Remove one copy; do not rely on which one wins.

Renaming the folder does not uninstall it (measured on UE 5.8). The engine discovers plugins by scanning Plugins/*/*.uplugin; the folder name is irrelevant. A copy parked as Plugins/UKInteraction.old/ (or any other name) is still an installed UKInteraction plugin and still wins the silent precedence above. To remove a copy, move it out of Plugins/ entirely. The same applies under <Engine>/Plugins/Marketplace/.

The per-engine breakdown of that observation is in the Duplicate installs section below.

Enabling the kit also enables Enhanced Input and OnlineSubsystemUtils — both are engine plugins that are on by default in every 5.6–5.8 template, so this changes no realistic project's enabled set. The editor validator reports the Enhanced Input auto-enable as UK-VAL-010.

Duplicate installs

If the same plugin exists in both locations, the behaviour is engine-version dependent and may be a hard UBT failure ("found more than one plugin with the name …") rather than a silent precedence. The kit relies on no precedence. The editor validator reports a duplicate as an Error (UK-VAL-011) naming both paths, because a stale engine copy is the most common "my fix did not apply" support ticket.

On the one engine measured so far (5.8) the behaviour is the silent-precedence case, not the hard failure: no "more than one plugin" line is printed.

Observed per-engine behaviour on 5.6 / 5.7 / 5.8. Nothing in this table is inferred: an engine that has not been measured is written as unmeasured.

What this means for you on 5.8 (and, until measured, what you should assume on 5.6 / 5.7 while relying on nothing): a stale copy under <Engine>/Plugins/Marketplace/ is ignored without any notice while a project copy exists, and silently becomes the live copy the moment the project copy is removed. Keep exactly one copy.

Renaming is not removing (measured on UE 5.8). The engine discovers plugins by scanning Plugins/*/*.uplugin; the folder name plays no part. A copy parked as Plugins/UKInteraction.old/ is still an installed UKInteraction plugin and still takes part in the precedence above. Move the copy out of Plugins/ (or out of Plugins/Marketplace/).

Cooked-target module loading

The kit ships two runtime modules. UKInteraction is Runtime and loads everywhere. UKInteractionClient is ClientOnly — prompts, glyphs and the sample widget live there, and a dedicated server is not supposed to load it. What follows is measured, per configuration, so you can reason about your own ClientOnly components.

Uncooked Windows -server, Development — measured 2026-09-14 on 5.8

Run: one UnrealEditor-Cmd <project> L_UKInteractionDemo?game=… -server process plus one -game 127.0.0.1 client. Two questions were asked in the server process, and they give opposite answers:

They do not contradict each other. EHostType::ClientOnly kept the plugin manager from loading the module, which is the descriptor doing its job. The module's DLL was nevertheless pulled into the process by the import chain of the kit's own UncookedOnly test module, which links UKInteractionClient on every target that is not a Server target — and a loaded DLL registers its UClasses with the object system whether or not a module object was ever created.

On the same frame: UKInteraction loaded, UMG loaded, Slate not loaded. UMG is a Runtime module and loads on a dedicated server too, so "the server has no UI module" is not what the kit's split means. What it means is that nothing the kit ships from UKInteractionClient is loaded by the plugin manager there.

What this does and does not tell you. It tells you the descriptor behaves as declared. It does not tell you that a ClientOnly class is resolvable on a cooked dedicated server — in this process it was resolvable for a reason that cannot exist in a cooked Server build, where the test module is not compiled at all and UKInteractionClient is excluded from the target outright.

Cooked Linux Server/Development — not yet measured

This is the decisive reading and it has not been taken yet, in either Development or Shipping. The automation test that takes it, UK.Interaction.Core.Demo.test_demo_pawn_loads_on_cooked_linux_server_multiprocess, is registered today and skips with tier_gated until then. The Server/Shipping variant — where check() is compiled out — is measured by hand, not by an automated run.

Nothing above may be quoted as a statement about a cooked server.

What this means for your own ClientOnly component

Until the cooked reading exists, the safe rule is the one the kit follows itself: no asset that a dedicated server loads may name a ClientOnly class in its component list. The kit ships none — its own client-side entry points are subsystems and a widget class a client resolves at runtime, not components placed on replicated actors. If you add a ClientOnly component to a pawn Blueprint, put it on a client-only path (add it at runtime on the owning client, or keep it in a separate client-only Blueprint), and cook a Server target of your project early enough to find out.

That sentence is about component lists, and it is not the whole cook. The same measurement found a kit asset of a ClientOnly class in a real Linux Server cook — …/Client/Glyphs/DA_UKGlyphs, whose class is /Script/UKInteractionClient.UKGlyphSet — because the plugin always-cooks its Client/ folder. No component list names it and nothing on a server loads it, so the rule above is unchanged; but a Server cook of your project will contain it, and that is worth knowing before you go looking for a leak. Whether the always-cook rule should narrow is open and is not a verdict here.

C++ vs Blueprint-only projects

The kit itself works in a Blueprint-only project. The optional adapters (GAS, CommonUI) are a C++-project feature: they are compiled in only when your project is rebuilt with the adapted plugin enabled. A Blueprint-only project gets a one-line diagnostic instead of a silent no-op — see Docs/adapters.md.