Doors

ACrimsonCoreDoor is a replicated, world-saved door that puts the whole interaction stack to work: the prompt, the context menu, interaction conditions, a lockpick channel and the save system. It swings or slides, has one or two leaves, and can optionally take a key (consumed on unlock if you choose), be lockpicked, carry a bolt that works from one side only, be knocked on, and close itself after a delay. One rule set drives the prompt, the menu and the server, so what a player is offered is always what the server will accept.

What's included

1. Place a door

Place B_CrimsonCore_Door (tick Show Plugin Content in the Content Browser settings to see it), or make your own Blueprint child of Crimson Door and assign its meshes. The blue editor arrow points at the door's Front side.

2. Lock it with a key

Set KeyItem to an item definition and tick Door State -> Locked on the placed instance. A player carrying the key gets Unlock; one without it sees Locked with the key on the prompt's checklist and no key glyph. Tick bConsumeKeyOnUnlock to take one key out of the bag on unlock. Add more requirements to ExtraKeyConditions; they are checked with the key for both Lock and Unlock.

3. Make it lockpickable (optional)

Tick bLockpickable, then add the requirements to LockpickConditions (or LockpickConditionSets), for example Has Item with a lockpick and Attribute Compare Health >= 50. Set LockpickAbilityClass to a duration ability (the shipped GA_Door_Lockpick, or UCrimsonCoreGameplayAbility_InteractionDuration itself for the default 3 s channel).

4. Add a one-sided bolt (optional)

Tick bHasBolt and set BoltSide (Back by default). Only a player on that side can bolt or unbolt; from the other side the prompt reads Barred ("Barred from the other side") and the menu's Unbolt is grayed out. Bolting needs the door closed. Bolt and Unbolt are held for 3 s (BoltHoldDuration), on the prompt and in the menu. Tick Door State -> Bolted to start it barred.

How the prompt and the menu decide

Three functions on the door hold every rule; the prompt, the menu and the server all call them.

Listing - `ShouldListAction`. Whether the menu lists a verb at all. It reads only replicated state, so client and server build the same list.

Availability and reasons - `GetActionAvailability`. Returns Hidden, Disabled with a reason, or Enabled. A disabled row is grayed out with its reason, and the server refuses anything that is not Enabled. Side checks live here, never in the listing, so a client and server that disagree about a pawn standing on the door plane produce a refusal rather than a mismatched menu.

Primary action - `GetPrimaryAction`. What one press of the interaction prompt does, checked in order. The menu marks the same verb as its default row.

Hold times - `GetActionHoldDuration`. Lock and Unlock take a KeyHoldDuration hold (1 s by default), Bolt and Unbolt a BoltHoldDuration hold (3 s); every other verb is instant. The same duration applies on both surfaces: the prompt offers an available Unlock or Unbolt as a Hold option and fills the progress ring around the key glyph, and the context menu marks those four rows HoldToConfirm with the door's duration in HoldToConfirmSeconds, so the row fills while it is held and fires when full. Releasing early cancels. The informational Locked and Barred prompts stay instant. Set either duration to 0 to make those verbs instant.

Multiplayer and save

• Server owns the state. RequestDoorAction (server, BlueprintAuthorityOnly) is the one validated entry point: reach (MaxUseDistance, 550 by default), then GetActionAvailability, then apply. Prompt presses and menu clicks both end there. It refuses Lockpick; a lock is only picked by a completed channel.
• Prompt presses carry the verb. On the pressing client, CustomizeInteractionEventData writes GetPrimaryAction into the trigger event's EventMagnitude; UCrimsonCoreGameplayAbility_DoorInteract decodes it on the server. Two players pressing Open at once both get an open door, never a toggle back to shut.
• Holds are a UX delay, not an authority check. The hold is timed on the owning client, on the prompt and in the menu; nothing reaches the server until it completes, and the server then validates the verb through RequestDoorAction like any other.
• The menu runs on the server, except Pick Lock, which runs on the owning client because its channel is a locally predicted ability.
• Motion is local on every machine, the dedicated server included, so leaf collision is real; transforms never replicate. A late-joining client, or one receiving a restored save, snaps the door into place with no sound.
• Blocking. A leaf that would move into a pawn holds; after a moment the server reverses it (bReverseWhenBlocked) and fires On Door Blocked. Auto-close waits while the doorway is occupied.
• Events. OnDoorStateChanged(Previous, Current), On Door State Changed, On Door Motion Finished and On Knocked fire on every machine. Knock and the locked-door rattle are unreliable multicasts.
• Save. DoorState is SaveGame and saves with the world: open, locked and bolted state and the swing direction come back on load. A consumed key stays consumed through the player's inventory save.

Mesh pivot rules

The layout reads mesh bounds, not pivots, so most door meshes work unchanged.

• Leaf. Width is the Y extent, height the Z extent; the thickness is centered on the door plane and the bottom sits on the floor. The hinge is the vertical edge nearest the mesh origin, so a leaf with its pivot on the hinge works whichever way it extends (+Y or -Y). A centered pivot hinges on the min-Y edge.
• Double door. The right leaf is a Y mirror of the left one (negative Y scale, not a 180-degree turn), so both keep their front faces on the Front side. Model one leaf only.
• Frame. FrameEdgeMesh is a vertical post, stretched to the leaf height on each side; the same mesh rolled 90 degrees is the lintel. FrameCornerMesh fills the two top corners. Any of them may be left empty.
• The interaction volume and the nav modifier are sized to the doorway in the same pass.

Build a door showcase

Place six B_CrimsonCore_Doors in a level of your own and configure each as below, plus three B_CrimsonItemSpawnerPads (/CrimsonCore/GameplayTesting/) for ItemDef_Key_Brass, ItemDef_Key_Iron and ItemDef_Lockpick. Set the level's RecastNavMesh to Dynamic Modifiers Only first.

API reference

See also

• Interaction Integration - the interact ability, prompt widget and progress ring the door relies on.
• Context Menu - how the menu gathers, validates and executes the door's entries.
• Inventory Showcases - spawner pads and the item definitions the keys are built from.