Custom Overrides
Two files exist specifically so your project-specific additions survive a wc_libs update: _custom/client.lua and _custom/server.lua. They load last, after the rest of wc_libs has already been assembled.
server/modules/money.lua by hand and later pull a wc_libs update, your change gets overwritten. Anything in _custom/ stays untouched — you only need to glance at these two files after an update, not the whole lib.
Adding a new function
Since _custom/ loads after WCLib already exists, you can add fields directly to it and re-export them the same way the core lib does.
WCLib.GetHonorLevel = function(source)
local ch = WCLib.GetCharacter(source)
if not ch or not ch.skills then return 1 end
local honor = ch.skills["Honor"]
return honor and honor.Level or 1
end
exports('GetHonorLevel', WCLib.GetHonorLevel)
Now every resource on the server can call wc:GetHonorLevel(source), even though it's specific to your project and not part of the core lib.
Overriding existing behaviour
Same pattern, just reassigning a field that already exists. Useful if your VORP server tracks something (like job duty status) that the stock adapter doesn't have a confirmed event/field for.
local originalGetJob = WCLib.GetJob
WCLib.GetJob = function(source)
local job = originalGetJob(source)
if job and job.onduty == nil then
-- fill in duty status from wherever your server actually tracks it
job.onduty = MyDutySystem.IsOnDuty(source)
end
return job
end
exports('GetJob', WCLib.GetJob)
WCLib.GetJob alone doesn't change what wc:GetJob(...) calls from other resources — exports are bound at registration time. Always call exports('GetJob', WCLib.GetJob) again after changing the field, as shown above.
When to graduate something out of Raw
If you find yourself reaching for Raw.VORP() / Raw.RSG() for the same thing more than once or twice, that's the signal to wrap it properly in _custom/ instead — every resource gets the clean version, and the raw native call only needs to be written correctly one time.