Locked Block

Per-player protection on a single block, with an explicit accessor list — independent of faction land ownership.

A lock protects one block — typically a chest or door — for one player, with an explicit list of other players allowed to use it.

Owned by a player, not a faction

This is the notable thing about the design: a locked block belongs to an MfPlayerId, not an MfFactionId. Protection is personal and survives changes of faction. A member can secure their own chest inside their faction's claim against their own faction-mates, and keep it when they leave.

Land ownership and container ownership are therefore two independent protection systems that both run on every block interaction. Faction Permission governs the first; the accessor list governs the second.

Chunk coordinates are denormalised

The record stores chunkX and chunkZ alongside the full block position, even though both are derivable from it by integer division. This is an index: the common query is "which locks exist in this chunk?", asked whenever a chunk's ownership changes or a player interacts within it. Storing the chunk lets that be a lookup rather than a scan over every lock in the world.

Typed unlock result

MfUnlockResult gives unlocking a typed outcome — SUCCESS, NOT_LOCKED, or FAILURE — so a caller can tell "there was nothing to unlock" apart from "the unlock was refused" and produce the right message for each. Compare the broader Service Layer failure model, which reaches for Result4k to make the same distinction.

Related

Locks are among the records carried over by Legacy Data Migration.