Administration

• Admin Panel & Wizard
• Door Interaction & Visuals
• Permissions
• Lockpicking

Admin Panel & Wizard

The administrator UI is designed to keep the main screen focused on saved door cards. Creation and editing are handled through a modal wizard.

Opening the Panel

Default command:

/doors

Configured with:

Config.AdminCommand = 'doors'

Access is validated on the server through the configured ACE and framework administrator groups.

Door Cards

Each saved door is displayed as a card. A card can show information such as:

• ID
• Name
• Locked/unlocked state
• Single or double door
• Object count
• Interaction distance
• Public or restricted access
• Auto-lock
• Lockpick availability

Click a door card to edit it.

Wizard — General

The General step controls the basic door definition.

Name

Friendly identifier used by administrators and developer exports.

Example:

Mission Row Front Entrance

Interaction Distance

Defines how close a player must be for normal interaction.

Server-side distance validation adds the configured tolerance:

Config.ServerDistanceTolerance = 2.0

Auto Lock

Number of seconds before an unlocked door automatically locks again.

Use:

0

to disable automatic relocking.

Default Locked

Determines the default state stored in the door definition.

Lockpick Enabled

Allows that door to participate in the lockpick workflow when global lockpicking is enabled.

Wizard — Door Objects

A door can contain one or two physical objects.

Door 1 is required.

Door 2 is optional and is intended for double doors.

The capture system uses multiple object-detection methods so solid doors, barred gates and some MLO door objects can be captured.

Wizard — Access

Access can be defined by jobs, identifiers and ACE permissions.

The access types are additive alternatives: a player only needs one valid access route.

An administrator is also allowed through the configured admin permission system.

Editing Existing Doors

Open a saved card, change the required values and save.

The server checks whether the new definition overlaps a physical door already owned by another entry. Conflicting definitions are rejected.

Deleting Doors

Deleting a door removes the persistent definition, broadcasts a full synchronization and retires its old DoorSystem hashes on clients.

Door Interaction & Visuals

Nord Doorlock can provide interaction through its built-in NUI, supported target systems or supported Text UI providers.

Interaction Key

Default:

Config.ToggleKey = 38 -- E

Interaction Distances

Config.InteractionDistance = 2.0
Config.DoorUIShowDistance = 6.0
Config.DoorUIInteractDistance = 2.0

DoorUIShowDistance controls how far away the interaction UI may become visible.

DoorUIInteractDistance controls the custom NUI interaction range.

Each door also stores its own distance.

Custom Door NUI

Enable:

Config.CustomDoorNUI = true

The custom NUI displays the current door action and state near the door.

Native Door State Icon

Enable:

Config.ShowDoorStateIcon = true

Default icon visibility distance:

Config.DoorStateIconDistance = 6.0

The resource uses GTA streamed textures:

'mpsafecracking', 'lock_open'
'mpsafecracking', 'lock_closed'

The icon is drawn in world space and disappears outside the configured distance.

Duplicate Icon Protection

Config.DoorStateIconMergeDistance = 0.35

Nearby icon centers are merged so the same physical location does not display multiple lock icons.

Door Closing Behaviour

Config.DoorCloseRate = 10.0
Config.DoorCloseTimeoutMs = 2500
Config.DoorCloseSnapFallback = true
Config.DoorPhysicalFallback = true

When locking, Nord Doorlock attempts to close the door before applying the final physical lock fallback. This avoids freezing a door while it is still open.

DoorCloseSnapFallback may use the captured heading after the normal close timeout for doors that do not correctly report their DoorSystem close state.

DoorPhysicalFallback adds an entity freeze only after the door is considered closed.

Permissions

Door access can be restricted by jobs, identifiers and ACE permissions.

If all access fields are empty, the door is public.

Jobs & Grades

Wizard format:

police:0, ambulance:2

This means:

Job	Minimum Grade
police	0
ambulance	2

A player with the matching job must meet or exceed the minimum grade.

Door data representation:

access = {
    jobs = {
        police = 0,
        ambulance = 2
    }
}

Identifiers

Add one identifier per line.

Example:

license:xxxxxxxxxxxxxxxx
discord:123456789012345678

Door data:

access = {
    identifiers = {
        'license:xxxxxxxxxxxxxxxx',
        'discord:123456789012345678'
    }
}

ACE Permissions

Add one ACE string per line.

Example:

door.pd
door.staff

Then grant the ACE in your server configuration as appropriate.

Example:

add_ace group.police door.pd allow

Administrator Access

Administrators can be recognized through:

Config.AdminAce = 'nord.doorlock.admin'

and/or:

Config.AdminGroups = {
    admin = true,
    superadmin = true,
    god = true
}

Custom Authorization

External scripts can extend or override authorization with the doorAuthorization hook.

See the Authorization Hooks page.

Server Authority

Do not trust a client-side permission check for security-sensitive logic.

HasAccess is available as a server export and should be preferred when another server resource needs to determine whether a player may use a Nord Doorlock door.

Lockpicking

Nord Doorlock includes an optional lockpick workflow.

Enable Globally

Config.EnableLockpick = true

Enable Per Door

Enable Lockpick in the door wizard.

Door structure:

lockpick = {
    enabled = true
}

Default Key

Config.LockpickKey = 74 -- H

Lockpick Configuration

Config.Lockpick = {
    item = 'lockpick',
    consumeOnSuccess = false,
    consumeOnFail = true,
    fallbackSuccessChance = 45,
    oxDifficulty = { 'easy', 'easy', 'medium' },
    oxInputs = { 'w', 'a', 's', 'd' }
}

item

Inventory item required before the attempt starts.

consumeOnSuccess

When true, one configured lockpick item is removed after a successful attempt.

consumeOnFail

When true, one configured lockpick item is removed after a failed attempt.

fallbackSuccessChance

Percentage used when an ox_lib skill check is unavailable.

oxDifficulty / oxInputs

Passed to lib.skillCheck when supported.

Server Validation

Before starting a lockpick attempt, the server checks:

• The door exists
• The player is near the door
• Lockpicking is globally enabled
• Lockpicking is enabled for the door
• The inventory bridge reports the required item

The server stores a short-lived pending attempt and validates it again when the client returns the result.

Standalone Inventory Warning

The default standalone inventory fallback cannot verify a real inventory item and therefore returns success for inventory checks.

If your standalone server uses a custom inventory, integrate it in:

server/bridge/inventory.lua

This is strongly recommended when lockpick items must be enforced.