Public architecture — ox_target

Role of every accessible file of ox_target by MrPoulpi Labs, the real manifest load order and the boundary between plain files and the escrow-protected core.

Goal: know which file to edit, and which ones to leave alone.

Plain files (editable)

File	Side	Role
`config.lua`	client + server	Shared settings: integrations, commands, groups, permissions, features, distances, security, medical, emotes, vehicles, billing, RPS, anti-punch, Dev Tools, weather, notifications and texts.
`config_interactions.lua`	client	Every target option: players, self, vehicles, peds, objects, models and zones.
`config_client.lua`	client	`Config.ClientHooks`: functions that replace the client bridge presets.
`config_server.lua`	server	`Config.ServerHooks` and `Config.ServerActions`: server hooks and secured actions.
`bridge/client.lua`	client	Client adapters to external scripts (presets); calls your hook first when there is one.
`bridge/server.lua`	server	Server adapters (groups, job, inventory, medical, weather, logs).
`client/api.lua`, `client/utils.lua`, `client/state.lua`, `client/debug.lua`, `client/defaults.lua`, `client/modules/vehicles.lua`, `client/framework/.lua`, `client/compat/.lua`	client	Original ox_target engine (MIT) loaded with `require`, left in plain text.
`web/`, `locales/*.json`, `stream/`	—	NUI interface (menu and Rock Paper Scissors window `web/rps/rps.html`), translations of the original options and of the RPS window, RPS animations.

config.lua is loaded on both sides: never put a function there that uses client-only or server-only natives. Hooks go in config_client.lua or config_server.lua.

Protected core

The manifest lists client/main.lua, server/main.lua (ox_target’s original server script) and the core/ files (shared, client and server) as protected. They contain the targeting loop, the registry that turns config_interactions.lua into options, the built-in features and server security. You do not need to read them: their observable behaviour is documented on this site, and this site does not publish their code.

Real load order

From fxmanifest.lua:

shared : @ox_lib/init.lua → config.lua → core/shared/core.lua
client : config_client.lua → config_interactions.lua → bridge/client.lua → client/main.lua
         → core/client/core.lua → builtins → vehicles → devtools → rps → registry (last)
server : config_server.lua → bridge/server.lua → server/main.lua
         → core/server/core.lua → builtins → trunk → rps

Practical consequences:

Config is created once by config.lua (Config = {}). The other files only add their tables (Config.ClientHooks = {}, Config.ServerHooks = {}, Config.ServerActions = {…}). Never recreate Config elsewhere.
config_interactions.lua can read Config.Distances (hence local D = Config.Distances) because config.lua is already loaded.
Options are built once at start by the registry: changing the configuration requires restart ox_target.

Path of an action

NUI → client (option) → [server action?]
    → protected engine: known action → anti-spam → feature → availability
      → permission → job → arguments → target and distance → item
    → Bridge.* → Config.ServerHooks.* when defined, otherwise preset → external script

Purely client options (copy ID, coordinates, personal emotes…) send no request to the server. Per-feature details are in Interactions and Permissions and security.

Escrow and good practice

Only edit the plain files. Protected .lua files are not readable and must not be replaced.
web/, locales/ and stream/ are not encrypted: editing them is technically possible but outside the public configuration, and your changes would be lost on update.
Keep a copy of your four config*.lua files: that is what you carry over during an update.