1. The Visibility Problem
I initially assumed there was a straightforward public API for the Sequence Recorder. I spent a good hour digging through headers, only to find that the primary functional logic was trapped inside a private module interface. It felt like I was being forced to use the Blueprint Function Library.
The current implementation required me to place a Blueprint-aware actor in the viewport simply to call a start function. This introduced a four-second delay and added unnecessary scene management overhead that felt completely wrong for a clean, automated pipeline.
- Identified SequenceRecorder.h as being restricted.
- Noted the overhead of using scene-bound actors.
- Rejected the idea of modifying engine source code.
2. Investigating Module Access
My first instinct was to consider patching the module header, but that would create a nightmare for future engine updates. I pivoted to inspecting how the editor actually communicates with the module, suspecting there might be an interface I had overlooked in the module manager.
I focused on the module lifecycle. If I could grab the module instance before the editor fully initialized the sequence UI, I could potentially hook into the recording logic directly.
- Checked ModuleManager functionality.
- Evaluated ISequenceRecorder interface visibility.
- Verified module dependencies in the build file.
3. The C++ Workaround
The breakthrough came when I stopped looking for a public header and started using the module loader directly. By referencing the module via the module manager, I could access the ISequenceRecorder interface without needing to touch private headers or rely on wrapper actors.
This allowed me to pass my actor list directly into the recording function. It removed the mandatory delay and kept my plugin code strictly within the C++ layer.
- Load the module using FModuleManager.
- Cast to the ISequenceRecorder interface.
- Call StartRecording with a custom actor array.
4. Verifying the Solution
After implementing the call, I ran a series of tests to ensure the sequence captures the expected data. Everything worked immediately without the need for manual actor placement or Blueprint hacks. The timing was exact, and the generated assets were stored correctly.
This approach is robust because it relies on the internal interface rather than the UI-heavy Blueprint nodes. It should remain stable as long as the interface contract is maintained by Epic.
- Validated recording start/stop cycles.
- Confirmed asset output naming conventions.
- Verified zero lag compared to manual triggering.
Key snippets
Directly Triggering Sequence Recorder
cppThis approach bypasses the Blueprint Function Library and interacts directly with the module interface.
ISequenceRecorder& SequenceRecorder = FModuleManager::LoadModuleChecked ("SequenceRecorder"):
TArray ActorsToRecord = GetActorsToRecord();
SequeceRecorder.StartRecording( ActorsToRecord, nullptr, nullptr);
FAQ
Do I need to modify the engine source to make this work?
No. By using FModuleManager to load the module, you access the existing interface without editing any source files.
Does this work in a packaged build or only the editor?
The Sequence Recorder is primarily an editor tool. This approach is intended for editor-time automation plugins, not runtime gameplay systems.