Troubleshooting HCP MACE
The plugin does not appear under System Settings → Third Party Plugins at all
Cause. MACE rejects a plugin DLL through two silent gates before it ever logs anything: the
assembly’s product name must be exactly MACEPlugIn, and it must contain a type whose name
matches the DLL’s own file name. If either check fails, MACE skips the DLL with no log entry and
no entry in the plugin list - this is the single most common reason a plugin “isn’t seen.”
Fix. Confirm you copied HEATCapturePluginMACE.dll itself (not a renamed copy - renaming
breaks the name-matching gate) directly into
C:\Users\Public\Documents\MACE\PlugIns\, not into a subfolder, and that you’re deploying a
build produced for the MACE version installed on this workstation.
The plugin appears in the list but never loads, with an error in the MACE log
Cause. Unlike the discovery gates above, a dependency that fails to resolve after discovery
succeeds is logged (to mace-error-log-*.txt). The most common cause is the
HEATCapturePluginMACE\ dependency subfolder being missing or incomplete next to the DLL.
Fix. Confirm the deploy included both HEATCapturePluginMACE.dll and its
HEATCapturePluginMACE\ subfolder (containing HEAT.ProtoLib.CSharp.dll) together, at the same
location - see Install.
The plugin loads, but nothing ever reaches HEAT Capture
Cause. Almost always one of:
AutoStartTransportis off - there is no other way to start capture in this version; see Configure.- No user is signed in to HEAT Capture. The plugin waits up to
SessionIdentityBufferTimeoutSeconds(default 120 s) for a valid authenticated session identity; captured data queues during that wait, then is discarded if it expires. CaptureBaseUrldoesn’t match where HEAT Capture is actually listening.
Fix. Confirm AutoStartTransport is on, sign in to HEAT Capture before or shortly after
starting the mission, and confirm CaptureBaseUrl.
Data arrives, then stops for a while, then resumes with a gap
Cause. Expected behaviour under a HEAT Capture outage, not a fault. The frame buffer is
bounded (MaxBufferedFrames/MaxBufferedMegabytes) and drops the oldest buffered frame first
once full - there is no in-band signal for this beyond the buffer count and LastError, so a
sustained outage produces a silent gap. Buffered events are bounded the same way, but their
drops are counted in DroppedEventCount, so events and frames do not behave identically under
the same backpressure.
Fix. Not a setting to fix directly - raising the buffer size only delays when the drop starts, it doesn’t prevent it under a sustained outage. Investigate why HEAT Capture was unreachable.
Data captured right at mission stop never arrives
Cause. Mission stop performs a best-effort drain of whatever is still buffered, over the
still-open socket, bounded by StopDrainTimeoutMs (default 3000 ms). If the socket is already
down, or the drain doesn’t finish in time, the still-buffered frames are discarded rather than
published - the HEAT session has to close either way, and the socket is not valid once it does.
Fix. Not generally actionable per-mission; if this happens often, increase
StopDrainTimeoutMs (see Configure) or investigate why the
connection was already degraded before the mission stopped.
A changed setting doesn’t seem to take effect
Cause. Settings are read into the running capture pipeline exactly once, at plugin initialization. Saving the settings file does not reconfigure an already-running pipeline.
Fix. Restart MACE (or reload the plugin) after saving a settings change.
A component I expect is missing, or a field is always the same value
Cause. Several fields are known, permanent MACE-side limitations rather than bugs - see
Data produced for the full list: WeaponLoadoutComponent
is never populated at all, max_health is always 1.0, LinkedEntityComponent.link_type is
never set, IFF modes 4/5 carry no code, and lighting only distinguishes on/high-beam.
Fix. Not configurable - confirm the field you need is on that list before assuming a deployment problem.