Reemplazar otrosdoorlocks

Todos los doorlocks de FiveM — ox_doorlock, qb-doorlock, nui_doorlock, esx_doorlock y Doorlock Creator— bloquean las puertas mediante el mismo sistema nativo de puertas. Si ejecutas dos, cada uno vuelve a poner la puerta en su propio estado: puertas que se desbloquean y se cierran de golpe, avisos que dicen "Unlock" en una puerta abierta, dos llaves en la misma puerta. Elimina el antiguo antes del primer inicio.

Eliminar el doorlock antiguo#

1. Haz una lista de tus puertas

   Antes de eliminar nada, anota qué puertas existen y quién las abre. Dónde encontrarlas:

   Recurso	Las puertas se guardan en
   ox_doorlock	La tabla ox_doorlock de la base de datos: una fila por puerta con sus datos JSON.
   qb-doorlock	configs/*.lua y config.lua dentro del recurso.
   nui_doorlock · esx_doorlock	config.lua (y configs/ si existe).

2. Evita que se inicie

   Elimina o comenta su línea en server.cfg, y saca la carpeta de resources/: un recurso dentro de una carpeta [category] que se inicia entera con ensure sigue arrancando.

   # ensure ox_doorlock
   # ensure qb-doorlock
   ensure qs-doorlock-creator

3. Comprueba qué dependía de él

   Los scripts de golpes, robos, housing y trabajos suelen bloquear y desbloquear puertas mediante los exports o eventos del recurso antiguo. Busca su nombre en tus recursos — ox_doorlock, qb-doorlock:server:updateState, nui_doorlock — y cambia esas llamadas como se muestra abajo.

4. Instala Doorlock Creator y recrea las puertas

   Sigue Instalación, luego abre /doorlockcreator y crea cada puerta de tu lista: apunta, haz clic, pon los mismos trabajos y rangos, y guarda. Uso explica cada campo.

5. Elimina los datos antiguos

   Cuando todas las puertas funcionen, borra la carpeta antigua. Con ox_doorlock también puedes eliminar su tabla:

   DROP TABLE IF EXISTS `ox_doorlock`;

Traer puertas con un script#

Para una lista larga, o para puertas que pertenecen a un script (una cámara acorazada, un bloque de celdas), el export de servidor EnsureDoors las crea a partir de un modelo y unas coordenadas, exactamente lo que contienen los archivos de config antiguos. Es seguro llamarlo en cada inicio: las puertas que ya existen se identifican por su nombre y se dejan como están.

-- A server file in any resource that starts after qs-doorlock-creator
local doors = {
    { name = 'mrpd_front_left', model = 'gabz_mrpd_reception_entrancedoor', coords = vector3(434.74, -983.21, 30.84), heading = 90.0, locked = true },
    { name = 'mrpd_cells_main', model = -53345114,                          coords = vector3(476.61, -1008.87, 26.48), locked = true },
}

CreateThread(function()
    -- The exports answer with an empty list until the doors are loaded from the database
    local ids = {}
    repeat
        ids = exports['qs-doorlock-creator']:EnsureDoors(doors)
        if #ids == 0 then Wait(1000) end
    until #ids > 0
end)

Las puertas creadas así son puertas simples sin reglas de acceso —cualquiera puede abrirlas y cerrarlas— hasta que las abras en el creador y añadas trabajos, ítems o un código. Los modelos y coordenadas de arriba son ejemplos; copia los tuyos de la config antigua.

Cambiar las llamadas de los scripts#

Las puertas se identifican por su id numérico —que el creador muestra como Edit door #12, y que devuelven EnsureDoors y GetAllDoors— en lugar de los nombres o índices del recurso antiguo.

-- Before
local door = exports.ox_doorlock:getDoorFromName('bank_vault')
TriggerEvent('ox_doorlock:setState', door.id, 0)

-- After (server side)
local id = exports['qs-doorlock-creator']:EnsureDoors({
    { name = 'bank_vault', model = 'v_ilev_gb_vauldr', coords = vector3(254.12, 225.13, 101.87), heading = 160.0 },
})[1]
exports['qs-doorlock-creator']:SetDoorState(id, false) -- false = unlocked

-- Before
TriggerServerEvent('qb-doorlock:server:updateState', 'pacific-vault', false, false, false, true)

-- After (server side)
exports['qs-doorlock-creator']:SetDoorState(12, false) -- 12 = the door's id

Todos los exports aparecen en Comandos y exports.