Reference

02

Blueprint control and lifecycle functions#

Profile, footwear, enablement, transfer state, and diagnostic controls are explicit.

03

Surface Impression receiver functions#

The included receiver exposes explicit binding, mapping, reset, and occupancy controls; field creation remains lazy.

04

Public provider and receiver interfaces#

Four extension seams integrate equipment, custom decal placement, source-presentation ownership, and project-owned impression backends without transferring gameplay authority.

05

C++ module and public headers#

Consumers depend only on the FootstepSystem runtime module and the public types they use.

PublicDependencyModuleNames.AddRange(new[]
{
    "Core",
    "CoreUObject",
    "Engine",
    "FootstepSystem"
});

#include "Movement/Footsteps/FootstepMaterialContract.h"
#include "Movement/Footsteps/UFootstepComponent.h"
#include "Movement/Footsteps/UFootstepFootwearProfile.h"
#include "Movement/Footsteps/UFootstepFootwearProvider.h"
#include "Movement/Footsteps/UFootstepProfile.h"
#include "Movement/Footsteps/UFootstepDecalProjectionAnchorProvider.h"
#include "Movement/Footsteps/UFootstepSourceExclusionProvider.h"
#include "Movement/Footsteps/UFootstepSurfaceImpressionReceiver.h"
#include "Movement/Footsteps/UFootstepSurfaceImpressionReceiverComponent.h"
#include "Movement/Footsteps/UFootstepSurfaceImpressionSubsystem.h"
#include "Movement/Footsteps/UFootstepWorldBudgetSubsystem.h"

06

C++ trigger and equipment examples#

C++ receives the same resolved context and stable rejection reason as Blueprint.

FFootstepEventKey Event;
Event.Type = EFootstepEventType::Step;

FFootstepResolvedContext Context;
EFootstepRejectReason Reason = EFootstepRejectReason::None;
const bool bAccepted = Footsteps.TriggerFootstepFromSocket(
    &Mesh, EFootstepContactType::LeftFoot, NAME_None, Event,
    FMath::Clamp(Strength01, 0.0f, 1.0f), Context, Reason);

FFootstepEventKey Event;
Event.Type = EFootstepEventType::Pivot;

FFootstepResolvedContext Context;
EFootstepRejectReason Reason = EFootstepRejectReason::None;
const bool bAccepted = Footsteps.TriggerFootstepAtLocation(
    &SourceComponent, ContactLocation, Event, 1.0f, Context, Reason);

FFootstepEventKey Event;
Event.Type = EFootstepEventType::Land;

FFootstepResolvedContext Context;
EFootstepRejectReason Reason = EFootstepRejectReason::None;
const bool bAccepted = Footsteps.TriggerFootstepFromHit(
    GroundHit, &SourceComponent, Event, Strength01, Context, Reason);

FFootstepTriggerRequest Request;
Request.SourceComponent = &SourceComponent;
Request.Contact = EFootstepContactType::CustomSocket;
Request.CustomSocket = TEXT("front_paw_l");
Request.Event.Type = EFootstepEventType::Custom;
Request.Event.CustomName = TEXT("Claw");
Request.Strength01 = 0.8f;
Request.bUseWorldLocationOverride = true;
Request.WorldLocationOverride = ContactLocation;
Request.FootwearProfileOverride = ContactProfile;

FFootstepResolvedContext Context;
EFootstepRejectReason Reason = EFootstepRejectReason::None;
const bool bAccepted = Footsteps.TriggerFootstep(Request, Context, Reason);

These are separate function-body examples, not one concatenated program. Footsteps is a UFootstepComponent reference, Mesh a USkeletalMeshComponent reference, SourceComponent a USceneComponent reference, ContactLocation an FVector, GroundHit a valid blocking FHitResult, Strength01 a float, and ContactProfile an already loaded UFootstepFootwearProfile pointer. Obtain these from your owning Actor or integration function. TriggerFootstepFromHit performs no plugin ground trace, although accepted decals may perform separate bounded placement queries. A Custom event requires a non-empty name. The world-location override bypasses socket lookup; without it, the socket path requires a real socket on the supplied skeletal mesh. Inspect the returned reason during integration.

07

Data Asset responsibilities#

Three asset families separate runtime policy, surface payloads, and optional equipment presentation.

• Validate every project-owned copy before production use.
• Enabled weighted channels and footwear texture stages require usable non-null positive-weight resources; transfer material stages require a valid Deferred Decal material.
• Duplicate identities and invalid ranges fail with property-specific Data Validation messages.

08

Decal material parameter reference#

The two decal masters share one Color, RSM, footwear, filtering, and source-exclusion contract; only the ColorNormalRSM master writes DBuffer Normal.

09

Surface Impression material parameter reference#

Project-authored surface response stays separate from the three receiver-owned field bindings.

10

Delegates#

Resolved, spawned, and rejected events deliberately represent different points in the presentation pipeline.

11

Stable rejection reasons#

The first failed gate produces one stable reason that can be diagnosed without guessing.

12

Documented bounds and defaults#

Authoring and runtime containers are intentionally bounded; zero has different meanings at different budget layers.

• At the profile channel layer, a maximum of 0 disables that channel's emissions.
• Lower retained capacities forget old presentation history sooner but do not invalidate a contact.
• Runtime clamps malformed cooked capacities defensively; valid authored assets must pass Data Validation instead of relying on fallback.

13

Runtime diagnostics#

Opt-in counters distinguish admission, ground-query, spawn, transfer, footwear, and budget behavior.

• Compare Accepted and Spawned when a route resolves but no channel appears.
• Compare Surface Transfer acquisition, consumption, emission, expiration, and clear counters.
• Compare footwear overlay emissions with surface audio emissions before justifying an extra voice.
• Reset counters between capture phases and retain the profile, data assets, engine version, and minimal logs for support.