RPS SDK
One SDK, one module per provider.
RPS SDK is the consumer documentation for the Rock / Paper / Scissors stack: the public header, a complete API reference, and buildable examples for each provider. The runtimes are open source — this is the focused path through them for someone building a mod, instead of a tour of their internals.
How you use it
Each module is a header, not a library. There is nothing to link and no framework layer between your code and the provider. You include the module's header, ask it to find the provider DLL at runtime, and receive a struct of function pointers. Calling one calls straight into the provider.
#include "ROCKProviderApi.h" // one header, nothing linked
#include "PAPERApi.h" // include only what you use
RockProviderApi::initialize(...); // inline: locate ROCK.dll,
// negotiate the table extent
RockProviderApi::inst->registerConsumerV1(...); // call the provider directly
paper::api::PaperApi::initialize(...); // same model for PAPER.dll
The example plugins each module ships are teaching projects you copy from, not a runtime you depend on. Take one, rename its plugin definition, and build your mod on top of it.
Modules
A module is a directory under SDK/. It carries its own public headers,
reference documentation, integration recipes, and buildable example consumers.
Adding a provider does not change any existing module's contract or release
history.
Hands, equipped weapons, generated collision, contacts, input, animation phases, and bounded interaction authority. 90 table slots on ABI V1.
SDK/PAPER · availablePAPER — animation and reloadsRuntime state, native hand/finger capture, reload evidence and stages, passive or exact animation data, resolved pose diagnostics, weapon-motion paths, manipulation telemetry, and development capture. 50 table slots on ABI V1.
No public consumer contract is published yet. This entry exists to mark the module boundary, not to imply an available API.
What you can rely on
The runtime source is public and worth reading. What the SDK gives you is the part that is stable: the header, the versioned contract, and examples built on it. Code that reaches past that into a runtime's internals is not covered by the API version and can break on any release.
Within that contract, a module defines exactly what it hands out and what it refuses. Consuming one does not make your plugin part of a provider — there is no static link to a runtime DLL and no authority to mutate arbitrary scene or Havok state.
The SDK is also not an F4SE plugin. Your DLL keeps ownership of its own F4SE bootstrap, lifecycle, runtime gating, and shutdown ordering.
Choosing between the SDK and the Framework
These solve different problems and compose cleanly.
| RPS SDK | RPS Framework | |
|---|---|---|
| Boundary | Cross-DLL provider contract | Statically linked into your DLL |
| You get | Copied values, bounded requests, leased authority | Checked native calls against FO4VR's engine |
| Provider must run | Yes — the provider DLL owns the state | No — it is your own code |
| Native memory access | Deliberately not granted | Yes, with explicit ownership and epoch rules |
Use the SDK when you want a provider to arbitrate something it already owns. Use the Framework when your plugin needs to call FO4VR engine mechanics itself. A plugin may reasonably use both.