Shipping a native runtime module — documentation

Module, editor, custom templates and export configuration with explicit dependencies.

A vendor runtime module is native code compiled into a custom Reckfell export template. An editor plugin can configure that template and expose settings, but installing the plugin does not add the native module to an unmodified editor. Use this approach when integration requires an engine build; consider ReckfellExtension when a separately loaded native library is sufficient.

Choose what must run in the editor

Integration needs	Required editor and template arrangement
Settings and export-time configuration only	A plugin can run in the standard editor; exported applications use custom templates containing the module.
Native classes while previewing or running the project in the editor	The editor must also contain the module, or the integration must supply a separate editor-compatible extension. A template alone cannot provide editor functionality.
A script attached to a vendor-specific native Entity type	That type must be registered where the asset is loaded. A runtime availability check cannot rescue a scene/prefab whose native type is missing.

Build the module using Custom C++ modules. Register runtime types at the appropriate non-editor initialization level; reserve editor integrations for MODULE_INITIALIZATION_LEVEL_EDITOR and editor-only build guards. The existing identifier MODULE_INITIALIZATION_LEVEL_SCENE is an initialization stage, not a separate Entity type or an ECS system.

If the standard editor does not contain the module, avoid hard references to its generated managed types and vendor-native assets in the editor-facing part of the package. Check the actual registered class or singleton before using it; checking the product version or an export feature tag does not prove that native code exists. Provide a clear unsupported state instead of failing during asset loading.

Build and package the supported variants

For every supported platform and architecture, build both target=template_debug and target=template_release with the module enabled. Use the relevant compilation guide. Keep precision, SDK/API assumptions, C# support and required native dependencies consistent with the project and consumer bindings.

Ship a manifest identifying Reckfell 1.0.0, binary hashes, target platform/architecture, debug/release configuration, module version, dependencies and licenses. A module package version identifies the integration; it is not an additional engine revision. Do not substitute a desktop editor executable for an export template.

For a Windows x86_64 integration, the package might contain these two actual built binaries:

addons/vendor_runtime/templates/windows-x86_64-debug.exe
addons/vendor_runtime/templates/windows-x86_64-release.exe

These are example package paths, not included downloads. Put the matching binaries there before using the configuration below. In the existing Windows preset's options section of export_presets.cfg, set:

Configuration
[preset.0.options]
binary_format/architecture="x86_64"
custom_template/debug="asset://addons/vendor_runtime/templates/windows-x86_64-debug.exe"
custom_template/release="asset://addons/vendor_runtime/templates/windows-x86_64-release.exe"

Use your preset's real index instead of 0. Merge these entries into its existing options section; do not replace the preset or append a duplicate section. The two template options select different binaries for debug and release exports. Confirm their paths and executable architecture before exporting. Keep template binaries out of the game's packed resources; they are build inputs, not game content.

This example applies to the desktop PC exporter. Do not copy executable paths into mobile or web presets: those platforms have different template packaging and dependencies.

Optional editor wrapper

A manual preset is sufficient for the template selection above. If you supply an editor wrapper, register one EditorExportPlugin through EditorPlugin.AddExportPlugin when enabling the plugin and unregister that same instance through RemoveExportPlugin when disabling it. Give the export plugin a stable _GetName() and implement _SupportsPlatform(EditorExportPlatform) for the platforms actually included in the package; the native default is false.

_GetExportOptionsOverrides(EditorExportPlatform) can supply a dictionary with custom_template/debug and custom_template/release for a supported desktop platform. These overrides replace user values and hide overridden options from the UI, so make the selected package/configuration explicit. The preset skips unsupported plugins; conflicting overrides from several plugins produce a warning and later values replace earlier ones. Avoid competing wrappers for the same template options.

Use _ExportBegin(string[] features, bool isDebug, string path, uint flags) for export preparation appropriate to the platform. It is not a mechanism to load the module into the editor or compile missing templates. Do not silently fall back to a standard template when the exported project requires vendor-native functionality.

Verify the delivered package

Symptom	Check
Class or singleton absent in the editor	Whether the editor contains the module, and whether its runtime types are registered outside editor-only code.
Class absent only in the exported application	Selected custom template, debug/release branch, architecture and module build option.
Template path missing	Package installation location and both `custom_template/*` values; the plugin does not create the binaries.
Wrapper options have no effect	Plugin enabled, registered export-plugin instance, `_SupportsPlatform` and conflicting overrides.
Export succeeds but the application cannot start	Missing native dependencies, wrong binary architecture or incompatible module/bindings. Export success is not runtime acceptance.

Validate both debug and release exports on a clean target machine: initialize the integration, perform one real operation, release its resources and exit normally. Check the unsupported configuration too. If C# is exposed, rebuild and test its consumer bindings against the delivered module; an editor wrapper alone does not generate them.

This guide is source-reviewed against the module initialization and desktop export code and current SDK signatures. The package paths are illustrative. No vendor SDK, module compilation, wrapper execution, packaged application or target-device operation was tested in this review.