Skip to main content

Framework Integration

Auto-deteccion​

Config.Framework = 'auto' intenta cargar en este orden:

  1. qbox
  2. qbcore
  3. esx

Integracion con Qbox​

Como se integra​

  • Disponibilidad: GetResourceState('qbx_core') == 'started'
  • Logout: exports.qbx_core:Logout(source)
  • Crear personaje: exports.qbx_core:Login(source, nil, newData)
  • Cargar personaje: exports.qbx_core:Login(source, citizenId)
  • Lista de personajes: consulta SQL directa sobre players
  • Preview ped data: consulta SQL directa sobre playerskins

Post-spawn en Qbox​

Despues de cargar personaje:

  • dispara QBCore:Server:OnPlayerLoaded
  • dispara QBCore:Client:OnPlayerLoaded
  • resetea metadata de qb-houses y qb-apartments
  • si es personaje nuevo, abre el creator configurado en Config.Appearance

Starter items​

Si ox_inventory esta iniciado, el recurso intenta leer starterItems desde qbx_core/config/shared.lua y entregarlos al crear personaje nuevo.

Integracion con QB-Core​

Como se integra​

  • Disponibilidad: qb_core arrancado y qbx_core apagado
  • Logout: QBCore.Player.Logout(source) o player.Functions.Logout()
  • Crear personaje: QBCore.Player.Login(source, false, newData)
  • Cargar personaje: QBCore.Player.Login(source, citizenId)
  • Lista de personajes: consulta SQL directa sobre players
  • Preview ped data: consulta SQL directa sobre playerskins

Post-spawn en QB-Core​

Despues de cargar personaje:

  • dispara QBCore:Server:OnPlayerLoaded
  • dispara QBCore:Client:OnPlayerLoaded
  • resetea metadata de qb-houses y qb-apartments
  • si es personaje nuevo, abre el creator configurado en Config.Appearance

Starter items​

Si ox_inventory esta iniciado, el recurso intenta leer items desde:

  • QBCore.Shared.StarterItems
  • o QBCore.Config.Player.PlayerDefaults.items

Integracion con ESX​

Como se integra​

  • Disponibilidad: GetResourceState('es_extended') == 'started'
  • Logout: TriggerEvent('esx:playerLogout', source)
  • Crear/cargar personaje: TriggerEvent('esx:onPlayerJoined', source, ...)
  • Lista de personajes: consultas SQL directas sobre users
  • Preview ped data: lectura de users.skin
  • Ultima posicion: lectura de users.position

Formato de identificadores​

En ESX, los personajes secundarios usan:

char<slot>:<baseIdentifier>

Ejemplo:

char2:license:xxxxxxxx

Columnas opcionales que aprovecha​

Si existen en users, las usa:

  • firstname
  • lastname
  • dateofbirth
  • sex
  • nationality
  • accounts
  • job
  • job_grade
  • position
  • money
  • bank
  • skin

Apariencia en ESX​

Si el personaje es nuevo y esta iniciado illenium-appearance o esx_skin, el cliente abre el creator configurado tras el spawn.

Integracion de apariencia y creator​

  • Preview auto: illenium-appearance -> fivem-appearance -> custom
  • Creator auto en qbox y qbcore: illenium -> qb_clothes -> qb_clothing -> custom
  • Creator auto en esx: illenium -> esx_skin -> custom
  • Si ningun provider funciona, el preview cae a aplicacion nativa o a ped aleatorio.

Integracion con spawn​

  • cinematic_selector: usa el selector interno de cold_multichar
  • last_location: intenta usar posicion en memoria o almacenada del personaje
  • default: usa Config.DefaultSpawn

Permisos y comandos​

  • El comando de slots revisa primero ACE.
  • Tambien acepta permisos de qbox y qbcore segun la cadena mod -> admin -> god.
  • Si ejecutas el comando desde consola (source == 0), la respuesta se imprime en consola.

Notificaciones​

  • El script envia feedback del comando de slots con TriggerClientEvent('cold_library:notify', ...).
  • No hay fallback interno a notificaciones de framework para ese caso.
  • Si no tienes un recurso escuchando ese evento, el comando sigue funcionando, pero no veras popup.