Configure HCP Unreal
Settings are edited in Edit → Project Settings → Plugins → HEAT Capture. They are written to
the project’s Config/DefaultGame.ini, under [/Script/hcp_unreal_plugin.HEATSettings].
UpdateRate is read fresh on every tick and applies immediately. Every other setting on this
page - including ServerHostname and ServerPort - is read once, when the level starts (the
capture subsystem’s Initialize), and baked into the running connection. Changing them requires
restarting the level (or the editor) to take effect.
Connection
| Setting | Type | Default | Effect | When to change |
|---|---|---|---|---|
ServerHostname | string | "localhost" | Host HCP Unreal connects to for both the WebSocket and the session HTTP calls | HEAT Capture runs on a different machine |
ServerPort | integer | 5005 | Port for both the WebSocket and the session HTTP calls | Matches HEAT Capture’s own configured port already, out of the box |
UpdateRate | float (seconds) | 1.0 | Minimum time between frame-build attempts; 0 attempts every tick | See Data produced for how this interacts with per-entity and per-component timing |
ServerHostname and ServerPort are correct for a HEAT Capture instance running with its own
shipped defaults - unlike some other plugins in this catalogue, no port correction is needed out
of the box.
Connection reliability
Once StartSession() is called, the plugin keeps the session and the publish WebSocket up on
its own - reconnecting automatically, with backoff, through a HEAT Capture restart or a network
interruption - until StopSession() is called. See
Interface control document for the full state machine.
| Setting | Type | Default | Effect | When to change |
|---|---|---|---|---|
RetryInitialDelaySeconds | float (seconds) | 0.5 | First retry delay after a session-start or connection failure | Rarely |
RetryMaxDelaySeconds | float (seconds) | 15.0 | Cap on the retry delay - it doubles from the initial delay up to this on repeated failures, then resets to the initial delay on the next success | Rarely |
RequestTimeoutSeconds | float (seconds) | 5.0 | Timeout for each current-session/start-session/stop-session REST call | Slow or remote HEAT Capture instance |
MaxBufferedFrames | integer | 300 | Maximum frames held in the rolling buffer while disconnected or reconnecting | Bounds outage memory only - see caution below |
MaxBufferedMegabytes | integer | 32 | Maximum total size of the rolling frame buffer | Same |
StopDrainTimeoutSeconds | float (seconds) | 3.0 | How long StopSession() waits for a best-effort flush of buffered frames before closing the connection | See Interface control document for why this is best-effort, not confirmed delivery |
MaxBufferedFrames/MaxBufferedMegabytes bound how much memory an outage can consume - they are
not a capture-volume control. The buffer drops its oldest entry first once either cap is
reached, so a sustained outage loses old data to make room for new, rather than refusing new
data.
There is no scene-scanning setting: every entity is registered explicitly, either by
AHEATActor::BeginPlay or by your own code calling RegisterEntity/RegisterComponentEntity -
see Data produced. Log detail is controlled entirely by Unreal’s own
LogHEATCapture category and its standard log levels, not by a project setting: filter the
Output Log, or run Log LogHEATCapture Verbose in the console for detailed messages.
Capture timing
UpdateRate sets the outer, global gate: the capture subsystem’s Tick does nothing at all
until at least UpdateRate seconds have passed since the last frame attempt. Below that gate,
individual entities and components can throttle further - see
Data produced for the full three-tier precedence.