Pular para o conteúdo

Helper de config apply

O @bs_config/shared/apply.lua é o que faz as alterações do F1 chegarem ao teu recurso.

Último shared script, depois dos teus ficheiros de config:

shared_scripts { 'config/config.lua' }
-- ...
shared_script '@bs_config/shared/apply.lua'
  • No arranque e a cada alteração, o servidor envia um payload { _global = {...}, <resource> = { ['Path.To.key'] = value } } através de bs_config:apply.
  • O helper pega na parte do teu recurso e altera as tuas tabelas globais no local: MyRes.Settings.reward = 75.
  • Só toca em chaves que já existem com o mesmo tipo. Nunca inventa config.
  • Quando um override é removido, repõe o valor original.
  • Dispara bs_config:changed:<resource> após cada aplicação, para poderes reagir:
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(), em ambos os lados.

Alterar a tabela chega quando o teu código lê a tabela de cada vez:

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

Não chega quando a copias para um local no carregamento:

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

O bs_config deteta esse padrão (local x = Cfg.key no nível superior) e marca a definição como “restart”. Prefere ler a tabela.

Adiciona linhas a bs_config/shared/schema.lua. O id é <resource>:<path>, com tipo, min/max/step, categoria, descrição e a flag live. O valor por defeito é lido do teu ficheiro em runtime; o valor fb no schema é só um fallback. Só deves adicionar chaves que realmente existem na tua config.