Config apply helper

@bs_config/shared/apply.lua is what makes F1 changes reach your resource.

Include it

Last shared script, after your config files:

shared_scripts { 'config/config.lua' }
-- ...
shared_script '@bs_config/shared/apply.lua'

What it does

• On start and on every change, the server sends a payload { _global = {...}, <resource> = { ['Path.To.key'] = value } } through bs_config:apply.
• The helper takes the part for your resource and patches your global tables in place: MyRes.Settings.reward = 75.
• It only touches keys that already exist with the same type. It never invents config.
• When an override is removed it puts the original value back.
• It fires bs_config:changed:<resource> after each apply, so you can react:

AddEventHandler('bs_config:changed:' .. GetCurrentResourceName(), function()
    rebuildSomething()
end)

Reading values

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(), both sides.

Live or restart

Patching the table is enough when your code reads the table each time:

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

It’s not enough when you copy it into a local at load:

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

bs_config detects that pattern (top-level local x = Cfg.key) and marks the setting as “restart”. Prefer reading the table.

Adding your settings to F1

Add rows to bs_config/shared/schema.lua. The id is <resource>:<path>, with type, min/max/step, category, description and the live flag. The default is read from your file at runtime, the fb value in the schema is only a fallback. Only add keys that really exist in your config.