Integraciones

Cómo funcionan las integraciones#

Treasure Hunting detecta lo que usas a partir de los recursos que se inician antes que él, y llega a cada uno mediante un pequeño archivo abierto que puedes leer y editar. No hay que configurar nada para un recurso compatible.

Cada integración opcional se degrada por sí sola. Que falte un recurso de target, de llaves o de interfaz nunca detiene una búsqueda: el script recurre a la versión básica y continúa.

Inventarios#

Con ox_inventory y qs-inventory se habla directamente para cada recuento, adición y retirada, nunca a través del framework. Eso importa en ESX con qs-inventory: es_extended solo redirige sus funciones de ítems para ox_inventory, así que pasar por el framework escribiría en una mochila que nadie mira. Con cualquier otro inventario, el framework es el inventario y se usa tal cual.

Antes de dar nada, el script pregunta al inventario si el ítem existe. Así distingue una mochila llena (el cofre se queda y no se cobra nada) de un ítem no registrado (se nombra una vez en la consola del servidor y al jugador, y se conserva el progreso). Si ox_inventory y qs-inventory están en marcha a la vez, se usa ox_inventory salvo que añadas Config.InventoryScript = 'qs' a la configuración.

Recursos de buceo#

Si otro recurso ya gestiona el buceo — qbx_divegear y similares —, deja que controle el aire:

-- config/config.lua
Config.ManageDivingGear = false

Entonces Treasure Hunting nunca toca SetEnableScuba, SetPedMaxTimeUnderwater ni SetPedDiesInWater, ni siquiera al reiniciar. diving_gear deja de venderse, registrarse, entregarse o exigirse, el indicador de la botella no aparece nunca, la mejora de oxígeno desaparece del tooltip y la guía indica a los jugadores que traigan su propio equipo.

El traje de buceo#

Con Config.Clothing activado, ponerse el equipo cambia al jugador a un traje de neopreno y quitárselo restaura su aspecto. El traje se define al principio de client/clothing.lua, con una tabla por género:

local playerClothing = {
    male = {
        ["arms"] = 17,
        ["tshirt_1"] = 15, ["tshirt_2"] = 0,
        ["torso_1"]  = 243, ["torso_2"] = 0,
        ["pants_1"]  = 94,  ["pants_2"] = 0,
        ["shoes_1"]  = 67,  ["shoes_2"] = 0,
        -- ...
    },
    female = { --[[ ... ]] },
}

En ESX el traje pasa por esx_skin y skinchanger; en QBCore, por qb-clothing:client:loadOutfit y qb-clothes:loadPlayerSkin. Para illenium-appearance, la línea de recarga ya está en el archivo, comentada. Con Config.QuasarInventory activado, qs-inventory se bloquea durante el cambio.

Notificaciones#

Las notificaciones integradas combinan con el panel. Para enviarlas a través de tu propio recurso, desactívalas y completa SendTextMessage en la configuración:

-- config/config.lua
Config.DefaultNotifications = false

function SendTextMessage(msg, type)
    -- type is 'info', 'error' or 'success'
    exports['Notify']:Alert(msg, type)
end

Los avisos y las pistas siguen usando la capa integrada en cualquier caso.

Logs de Discord#

Desactivado por defecto. Se pueden registrar cinco eventos, cada uno con su propio color:

-- config/config.lua
Config.Webhooks = {
    Enabled   = true,
    Url       = 'https://discord.com/api/webhooks/...',
    Name      = 'qs-treasure-hunter',
    Avatar    = '',
    Timestamp = true,

    Events = {
        MissionStarted   = true,
        MissionFinished  = true,
        MissionAbandoned = true,
        MoneyPaid        = 'https://discord.com/api/webhooks/staff-channel',
        ExperienceGiven  = false,
    },
}

Cada evento es true (el Url compartido), false, o una URL propia, de modo que el dinero puede ir a un canal del staff mientras las misiones van a uno público. Cada embed incluye el nombre del jugador, su id de servidor y su identificador. El envío nunca bloquea un pago. El formato es común con los demás trabajos de Quasar, así que todos pueden publicar en un mismo canal.

Misiones de qs-inventory#

Con Config.QuasarInventoryQuests = true y qs-inventory en marcha, se crean tres misiones para cada jugador al cargar, y avanzan a medida que juega:

Los títulos, descripciones y recompensas están en server/missions.lua. Una subida de nivel también reporta level_up_treasure_hunter, para una misión con ese nombre si creas una.

Dinero del trabajo#

Cuando qs-job-management está iniciado, los pagos de las búsquedas pasan por su export AddJobMoney con el trabajo treasure_hunter en lugar de ir directamente al efectivo. Las ventas de la tienda, los reembolsos de barcas y las recompensas de la clasificación siempre van al efectivo.

Añadir tu propio sistema de llaves#

Cada sistema de llaves es un archivo en client/vehiclekeys/ que permanece inactivo salvo que Config.Vehiclekeys lo nombre.

1. Copia el archivo más parecido

   Duplica none.lua o el sistema más cercano al tuyo, con el nombre de tu recurso.

2. Escribe las dos funciones

   if Config.Vehiclekeys ~= 'my_keys' then
       return
   end
   
   function AddVehiclekeys(vehicle, plate)
       exports['my_keys']:GiveKeys(plate)
   end
   
   function RemoveVehiclekeys(vehicle, plate)
       exports['my_keys']:RemoveKeys(plate)
   end

3. Regístralo para la detección

   Añade ['my_keys'] = 'my_keys' a la tabla vehicleKeys al principio de config/config.lua.

Los puentes del framework en client/framework/ y server/framework/ están abiertos del mismo modo (dinero, ítems, nombres, la barra de progreso y el blip) para un servidor cuyo core se haya renombrado o modificado.