JARVIGManual

Plugins

A plugin is a native module the engine loads through the C ABI. It exports a versioned table. It does not inherit a Rust trait across the DLL.

Each category gets the capabilities it needs and no others.

CategoryMay doMay not do
Runtime pluginSubscribe to world events, register componentsDraw, import files, edit the project
Editor pluginSubmit commands, add panelsOwn import, cook, or simulation
Game moduleThe lifecycle in game-module.mdLink the editor
Asset importerTurn bytes into an engine asset through AssetServiceWrite a private file format only the editor understands
Asset processorCook or derive through the engineShell the editor UI
Physics backendStep bodies the physics service ownsSee materials or the GPU device
Audio backendPlay sounds the audio service submitsMutate the world
Renderer extensionAdd a pass the render service callsTake wgpu types or replace the RHI
Platform extensionOS and device services behind the platform crateBecome a second windowing stack in the game
Build targetPackage through the build commandReimplement cooking

An editor plugin that imports a material by itself is a bug. It submits ImportAsset. The CLI submits that same command.

Load

The module exports one bind entry. The engine passes the API version it speaks and the capabilities it is willing to grant. The module fills a table whose first field is the version it implements. A mismatch returns JARVIG_VERSION_MISMATCH and the module is unloaded. A missing capability is the same kind of failure.

The module is not given a pointer to the engine object. It is given function tables for the capabilities it declared.

Trust

Downloaded project plugins are untrusted relative to the hub. Loading one is an explicit act. This doctrine does not make them sandboxed. It makes their reach small enough that a sandbox is possible later.

The reserved package name packages/plugin-sdk/ is still empty. Do not fill it with a second API.