Saltearse al contenido

Helper de config apply

@bs_config/shared/apply.lua es lo que hace que los cambios de F1 lleguen a tu recurso.

Último shared script, después de tus archivos de config:

shared_scripts { 'config/config.lua' }
-- ...
shared_script '@bs_config/shared/apply.lua'
  • Al arrancar y en cada cambio, el servidor envía un payload { _global = {...}, <resource> = { ['Path.To.key'] = value } } mediante bs_config:apply.
  • El helper toma la parte de tu recurso y modifica tus tablas globales en el sitio: MyRes.Settings.reward = 75.
  • Solo toca claves que ya existen con el mismo tipo. Nunca inventa config.
  • Cuando se quita un override, repone el valor original.
  • Dispara bs_config:changed:<resource> tras cada aplicación, para que puedas reaccionar:
AddEventHandler('bs_config:changed:' .. GetCurrentResourceName(), function()
rebuildSomething()
end)
local mult = BSConfigGet('Global.xpMultiplier', 1.0) -- globals or your own paths, no export call
-- or from anywhere:
local size = exports.bs_config:Get('bs_factions:Factions.Squad.maxSize')

Exports: Get(key, default), GetPayload(), GetActiveProfile(), en ambos lados.

Modificar la tabla basta cuando tu código lee la tabla cada vez:

-- live: sees the new value next call
local function reward() return RadioTower.Settings.reward end

No basta cuando la copias a un local al cargar:

-- cached: F1 changes do nothing until restart
local REWARD = RadioTower.Settings.reward

bs_config detecta ese patrón (local x = Cfg.key en el nivel superior) y marca el ajuste como “reinicio”. Prefiere leer la tabla.

Añade filas a bs_config/shared/schema.lua. El id es <resource>:<path>, con tipo, min/max/step, categoría, descripción y el flag live. El valor por defecto se lee de tu archivo en runtime; el valor fb del schema es solo un fallback. Añade solo claves que existan de verdad en tu config.