Door Data Structure
A Nord Doorlock door is represented as a Lua table.
Example — Single Door
{
id = 1,
name = 'Police Front Door',
distance = 2.0,
autoLock = 0,
locked = true,
defaultLocked = true,
parts = {
{
model = 123456789,
coords = {
x = 440.1234,
y = -998.5678,
z = 30.1234
},
heading = 90.0
}
},
access = {
jobs = {
police = 0
},
identifiers = {},
ace = {}
},
lockpick = {
enabled = false
}
}
Example — Double Door
{
name = 'Main Double Door',
parts = {
{
model = 111111111,
coords = {
x = 100.0,
y = 200.0,
z = 30.0
},
heading = 90.0
},
{
model = 222222222,
coords = {
x = 102.0,
y = 200.0,
z = 30.0
},
heading = 270.0
}
}
}
Field Reference
| Field | Type | Description |
|---|---|---|
id |
number | Persistent internal ID |
name |
string | Friendly door name |
distance |
number | Interaction distance |
autoLock |
number | Seconds before relocking, 0 disables |
locked |
boolean | Current persistent state |
defaultLocked |
boolean | Default configured state |
parts |
array | One or two physical door parts |
access |
table | Jobs, identifiers and ACE rules |
lockpick |
table | Lockpick settings |
Part Structure
{
model = 123456789,
coords = {
x = 0.0,
y = 0.0,
z = 0.0
},
heading = 0.0
}
The captured heading is important for physical fallback behavior on doors that do not correctly close through GTA DoorSystem alone.
Access Structure
access = {
jobs = {
police = 0
},
identifiers = {
'license:...'
},
ace = {
'door.police'
}
}
Lockpick Structure
lockpick = {
enabled = true
}
Developer API Copies
GetDoor, GetDoors and similar read exports return copies.
Changing the returned table does not edit the actual Nord Doorlock definition.
Use UpdateDoor for persistent server-side edits.