import { type KitBlueprint, type KitInvokePolicy } from './core.js'; /** * The authority source that may operate a lockable object. Several may be * combined (any one grants access — they are OR'd): * * - `owner` — only the container's owner (`owner_of_self`); "only the owner * of this chest can open it". * - `key` — the caller must own a matching key item; "if a player has key 1 * they can open door 1". Adds a required `key_id` (`container_ref`) param. * - `gridPermission` — the caller must hold a runtime grid permission; ties * the object to a world region ("movement permission on chunk X opens the * doors in it"). * - `groupPermission` — the caller must be in a team/group (optionally with a * specific group permission). * - `custom` — any hand-written {@link KitInvokePolicy} rule. */ export type LockAuthority = { kind: 'owner'; } | { kind: 'key'; } | { kind: 'gridPermission'; key: string; gridId?: string; } | { /** * The caller must hold the runtime permission on the grid covering the * chunk the OBJECT stands in (`cx`/`cy`/`cz` int properties, seeded via * `ObjectsKit.create({ chunk })`). No hand-pinned grid id — one function * serves every such object in the world. `mode` picks the covering grid * when several overlap: 'first' (enforcement parity, default) | * 'smallest' (innermost plot) | 'largest'. Requires game-api v0.13.12+. */ kind: 'chunkPermission'; key: string; mode?: 'first' | 'smallest' | 'largest'; } | { kind: 'groupPermission'; groupId: string; permission?: string; } | { kind: 'custom'; rule: KitInvokePolicy; }; /** Options for {@link lockBlueprint}. */ export interface LockBlueprintOptions { /** * Container type name for the lockable object (`Door`, `Chest`, `Gate`, …). * Also drives the function names (`open_door` / `close_door`). Defaults to * `'Lockable'`. */ objectTypeName?: string; /** Key item type name (only used with a `key` authority). Defaults to `Key`. */ keyTypeName?: string; /** One or more authority sources; any one grants access. */ authority: LockAuthority | LockAuthority[]; /** * Extra policy rule AND'ed on top of the OR'd authorities — e.g. * `featureGate('vip')` for members-only doors regardless of keys. */ policyExtra?: KitInvokePolicy; } /** Names derived by {@link lockBlueprint} for a given object type. */ export interface LockNames { objectType: string; keyType: string; openFn: string; closeFn: string; } /** Compute the type/function names a lock blueprint (and its runtime helper) uses. */ export declare function lockNames(objectTypeName?: string, keyTypeName?: string): LockNames; /** * Blueprint for a **lockable game object** (door, chest, gate, switch) whose * `open`/`close` functions are gated by a configurable authority source: * ownership, a key item the caller must hold, a runtime grid permission, a * team/group permission, or any custom policy rule. Multiple authorities are * OR'd, so "the owner, or anyone with the right key" is one blueprint. * * Runtime counterpart: `client.kit(appId).objects`. */ export declare function lockBlueprint(options: LockBlueprintOptions): KitBlueprint; //# sourceMappingURL=locks.d.ts.map