Hooks et actions serveur

But : brancher votre propre code là où aucun preset ne convient, et créer des actions contrôlées par le serveur. Fichiers : config_client.lua (Config.ClientHooks) et config_server.lua (Config.ServerHooks, Config.ServerActions).

Principe des hooks

Un hook défini remplace le preset correspondant : le bridge appelle votre fonction et n’exécute plus le code du preset. Laissez un hook à nil (non défini) pour garder le preset choisi dans config.lua. Les hooks serveur sont appelés après les contrôles du moteur : inutile d’y revérifier la permission de l’action qui les déclenche.

Quelques hooks changent aussi la disponibilité d’une option : définir SendBill, GiveVehicleKeys ou RestoreAppearance rend l’option correspondante disponible même avec le sélecteur sur 'custom'.

Exception notable : avec Config.Medical.nativeHealFallback = true, le heal natif complémentaire s’applique après votre hook HealSelf ou HealPlayer.

Hooks client

Hooks serveur

Exemple : notifications personnalisées

mon_notify est un nom d’exemple de ressource.

Config.ClientHooks.Notify = function(message, ntype, duration)
    exports['mon_notify']:Show(message, ntype, duration)
end

Config.ServerHooks.Notify = function(source, message, ntype, duration)
    TriggerClientEvent('mon_notify:show', source, message, ntype, duration)
end

Routines client

Le serveur peut lancer une routine client whitelistée : TriggerClientEvent('ox_target:core:run', id, '<Routine>', ...). Routines documentées par l’archive : PlayEmote(emote), Me(text), ReviveSelf(), HealSelf(), NativeRevive(), NativeHeal(). Elles passent par le bridge, donc par vos hooks client. PlayEmote revalide le nom avec Config.Emotes ; Me tronque à 120 caractères.

Config.ServerHooks.RevivePlayer = function(source, targetId)
    TriggerClientEvent('ox_target:core:run', targetId, 'NativeRevive')
end

Actions serveur personnalisées

Une action déclarée dans Config.ServerActions est appelée par une option type = 'server_action'. Le moteur exécute ses contrôles puis votre handler(ctx).

Les noms des actions intégrées (admin_revive, weather_set…) ne peuvent pas être réutilisés.

Règles d’arguments

Chaque règle accepte optional = true. Un argument manquant non optionnel ou invalide fait refuser la requête (invalid_input) et la signale comme suspecte.

Objet ctx

Exemple complet

Côté serveur (config_server.lua) ; mon_script:afficherPermis est un nom d’exemple :

Config.ServerActions = {
    check_license = {
        permission  = 'everyone',
        jobs        = { 'police' },
        target      = 'player',
        maxDistance = 3.0,
        cooldown    = 2000,
        args        = { { type = 'string', oneOf = { quick = true, full = true } } },
        handler     = function(ctx)
            TriggerClientEvent('mon_script:afficherPermis', ctx.target, ctx.source, ctx.args[1])
            ctx.notify('Demande envoyée.', 'success')
        end,
    },
}

Côté client (config_interactions.lua) :

{ name = 'check_license', label = 'Vérifier les papiers', icon = 'fa-solid fa-id-card', jobs = { 'police' }, type = 'server_action', action = 'check_license', args = { 'quick' } },

Le client envoie l’ID serveur de la cible pour les listes Joueurs et Soi-même, et le network ID de l’entité pour les autres listes. Choisissez target en conséquence.

Journaliser

Config.ServerHooks.OnActionExecuted = function(source, actionName, ctx)
    print(('[ox_target] %s a utilisé %s'):format(GetPlayerName(source), actionName))
end

D’autres ressources peuvent enregistrer des actions avec exports.ox_target:registerAction.

Erreurs fréquentes

• Action sans permission : autorisée à tout le monde, ce qui est rarement voulu pour une action sensible.
• target = 'player' sur une option de véhicule : la requête envoie un network ID, refusé comme « cible joueur inexistante ».
• Hook vide function() end : le preset est remplacé par une fonction qui ne fait rien.
• Handler qui modifie de l’argent ou un inventaire sans revérifier les montants : le moteur valide les types et bornes déclarés, pas la logique métier.