Architecture publique — ox_target

Rôle de chaque fichier accessible d’ox_target MrPoulpi Labs, ordre de chargement réel du manifeste et frontière entre fichiers en clair et cœur protégé par l’escrow.

But : savoir quel fichier modifier, et lesquels ne pas toucher.

Fichiers en clair (modifiables)

Fichier	Côté	Rôle
`config.lua`	client + serveur	Réglages partagés : intégrations, commandes, groupes, permissions, fonctionnalités, distances, sécurité, médical, emotes, véhicules, facturation, PFC, anti-punch, Dev Tools, météo, notifications et textes.
`config_interactions.lua`	client	Toutes les options du target : joueurs, soi-même, véhicules, PNJ, objets, modèles et zones.
`config_client.lua`	client	`Config.ClientHooks` : fonctions qui remplacent les presets du bridge client.
`config_server.lua`	serveur	`Config.ServerHooks` et `Config.ServerActions` : hooks serveur et actions sécurisées.
`bridge/client.lua`	client	Adaptateurs client vers les scripts externes (presets) ; appelle d’abord votre hook s’il existe.
`bridge/server.lua`	serveur	Adaptateurs serveur (groupes, métier, inventaire, médical, météo, 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	Moteur ox_target d’origine (MIT) chargé par `require`, laissé en clair.
`web/`, `locales/*.json`, `stream/`	—	Interface NUI (menu et fenêtre Pierre Feuille Ciseaux `web/rps/rps.html`), traductions des options d’origine et de la fenêtre PFC, animations PFC.

config.lua est chargé des deux côtés : n’y placez aucune fonction qui utilise des natives propres au client ou au serveur. Les hooks vont dans config_client.lua ou config_server.lua.

Cœur protégé

Le manifeste liste comme protégés client/main.lua, server/main.lua (script serveur d’origine d’ox_target) et les fichiers core/ (partagé, client et serveur). Ils contiennent la boucle de ciblage, le registre qui transforme config_interactions.lua en options, les fonctionnalités intégrées et la sécurité serveur. Vous n’avez pas besoin de les lire : leur comportement observable est documenté dans ce site, et ce site ne publie pas leur code.

Ordre de chargement réel

D’après 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 (en dernier)
serveur : config_server.lua → bridge/server.lua → server/main.lua
          → core/server/core.lua → builtins → trunk → rps

Conséquences pratiques :

Config est créé une seule fois par config.lua (Config = {}). Les autres fichiers ne font qu’ajouter leurs tables (Config.ClientHooks = {}, Config.ServerHooks = {}, Config.ServerActions = {…}). Ne recréez jamais Config ailleurs.
config_interactions.lua peut lire Config.Distances (d’où local D = Config.Distances) car config.lua est déjà chargé.
Les options sont construites une fois au démarrage par le registre : modifier la configuration exige un restart ox_target.

Chaîne d’une action

NUI → client (option) → [action serveur ?]
    → moteur protégé : action connue → anti-spam → fonctionnalité → disponibilité
      → permission → métier → arguments → cible et distance → item
    → Bridge.* → Config.ServerHooks.* si défini, sinon preset → script externe

Les options purement client (copier l’ID, coordonnées, emotes perso…) n’envoient aucune requête au serveur. Le détail par fonctionnalité est dans Interactions et Permissions et sécurité.

Escrow et bonnes pratiques

Modifiez uniquement les fichiers en clair. Les fichiers .lua protégés ne sont pas lisibles et ne doivent pas être remplacés.
Les fichiers web/, locales/ et stream/ ne sont pas chiffrés : les modifier est techniquement possible mais sort du cadre de la configuration publique, et vos changements seraient perdus à la mise à jour.
Gardez une copie de vos quatre fichiers config*.lua : c’est ce que vous reporterez lors d’une mise à jour.