HasPlayerWorldDoorAccess: Difference between revisions
Document upcoming 0.1.9 custom native keys, shared doors, server Lua callbacks and persistence; not a release |
Release 0.1.9 / BUILD264 / Protocol42: availability and download setup; preserve experimental limits |
||
| Line 1: | Line 1: | ||
= hasPlayerWorldDoorAccess = | = hasPlayerWorldDoorAccess = | ||
'''Available from 0.1.9 | '''Available from 0.1.9. Use matching updated server and clients.''' | ||
Server Lua. Part of [[Custom keys|custom keys and shared placed doors]]. | Server Lua. Part of [[Custom keys|custom keys and shared placed doors]]. | ||
Latest revision as of 13:28, 20 October 2026
hasPlayerWorldDoorAccess
Available from 0.1.9. Use matching updated server and clients.
Server Lua. Part of custom keys and shared placed doors.
Syntax
allowed = hasPlayerWorldDoorAccess(playerId, id)
Parameters and behavior
playerId is a connected player; id is an owned placed door. Checks only its server key requirement and authoritative inventory. This is NOT a range, alive, readiness, busy-state, reservation or animation check.
Returns
Boolean; false for unknown/not-owned doors or disconnected players. No assigned/enabled key requirement means true for a connected player. The operation itself independently revalidates access.
Examples and security
See Custom keys for complete registration, copy issuance, placement, persistence and callback examples. These are server functions, not client RPC endpoints. Do not forward untrusted client arguments without gameplay authorization.