Pour une intégration simple, modifiez uniquement config/medical.lua. Le choix du script, le nom de sa ressource, les appels Heal/Revive et la lecture de son état médical sont regroupés dans ce fichier. Redémarrez cdt_admin après modification. Ces réglages proviennent des fichiers, pas de la configuration SQL ni du menu en jeu.
1. Script déjà intégré
Remplacez provider='auto' par le fournisseur utilisé :
| Valeur | Ressource par défaut |
|---|---|
qbx | qbx_medical |
esx | esx_ambulancejob |
qb | qb-ambulancejob |
wasabi_v2 | wasabi_ambulance_v2 |
wasabi | wasabi_ambulance |
qs | qs-medical-creator |
brutal | brutal_ambulancejob |
sky | sky_ambulancejob |
ak47 | ak47_ambulancejob |
auto sélectionne le seul fournisseur connu réellement démarré. Si plusieurs sont présents, choisissez un fournisseur explicitement. Une convar existante cdt_admin:medical reste prioritaire : retirez-la pour utiliser le choix du fichier. Évitez d'utiliser une convar serveur pour choisir un fournisseur différent de celui configuré dans le fichier partagé avec les clients.
Les APIs dépendent de votre version du script ambulance. Brutal intègre la réanimation ; ses soins et les actions AK47 nécessitent des appels personnalisés. Les autres intégrations utilisent les APIs déjà prévues dans CDT. Heal et Revive restent deux actions distinctes : ne configurez pas Heal avec une fonction qui réanime.
Pour une ressource renommée, utilisez providers. Exemple :
provider='qbx',
providers={
qbx={resource='mon_qbx_medical'},
},
2. Script personnalisé
Voici un exemple complet de config/medical.lua. Les noms mon_ambulance, RevivePlayer et mon_ambulance:heal sont des exemples, à remplacer par les noms exacts de la documentation de votre ambulance.
return {
provider='custom',
providers={},
custom={
resource='mon_ambulance',
revive={
side='server',
type='export',
name='RevivePlayer',
args={'$playerId'},
},
heal={
side='client',
type='event',
name='mon_ambulance:heal',
args={'full'},
},
-- Facultatif, seulement si votre ambulance publie cet état côté serveur :
-- state={key='dead',deadValue='dead',laststandValue='laststand'},
},
}
| Réglage | Signification |
|---|---|
resource | Nom exact de la ressource ambulance démarrée |
side='server' | Exécuter l'appel sur le serveur |
side='client' | Exécuter l'appel chez le joueur ciblé |
type='export' | Appeler un export de la ressource ambulance |
type='event' | Déclencher un événement local sur le côté choisi |
name | Nom exact de l'export ou de l'événement |
args | Liste des arguments dans l'ordre requis, ou {} si aucun argument |
$playerId | Identifiant serveur du joueur ciblé, même pour un appel client |
Un événement configuré côté serveur utilise TriggerEvent, pas TriggerServerEvent. Un événement côté client est déclenché localement chez la cible après une demande du serveur. N'ajoutez pas l'identifiant cible aux paramètres d'un événement client si son API attend uniquement des paramètres locaux.
Les booléens, nombres, chaînes et tableaux imbriqués sont acceptés. Exemple pour un export serveur attendant (source, options) :
heal={
side='server',type='export',name='ApplyHeal',
args={'$playerId',{health=200,injuries={{type='all',limb='all'}},resetNeeds=true}},
},
$playerId est également remplacé dans les tableaux imbriqués. N'utilisez pas un identifiant fixe de joueur. args doit être une liste sans trous ; les fonctions et les expressions Lua exécutables ne sont pas acceptées comme paramètres.
Un export retournant false ou levant une erreur fait échouer l'action. true ou l'absence de retour confirme l'appel. Les autres valeurs de retour nécessitent une adaptation avancée. Pour un événement, la confirmation signifie que l'événement a été déclenché : elle ne garantit pas que l'ambulance a terminé le soin, ni qu'un gestionnaire existe pour ce nom.
3. Remplacer une action d'un script connu
Vous pouvez conserver l'intégration native de la réanimation et modifier seulement les soins, dans le même fichier :
provider='qbx',
providers={
qbx={
heal={side='server',type='export',name='Heal',args={'$playerId'}},
},
},
Une action absente conserve son intégration native pour un fournisseur connu. Une action définie à false est désactivée. Une action personnalisée invalide est refusée et ne bascule pas vers une autre API. Pour custom, renseignez explicitement les deux actions souhaitées ; aucune API n'est devinée.
4. Lire la mort et l'état critique
Si votre ambulance publie un état dans Player(source).state, ajoutez :
state={key='dead',deadValue='dead',laststandValue='laststand'},
Adaptez la clé et les valeurs à votre script. Exemple numérique : state={key='medical:death',deadValue=2,laststandValue=1}. Exemple booléen sans état critique : state={key='isDead',deadValue=true}.
Cette lecture sert au profil médical ; elle ne modifie pas l'état du joueur. Les autres valeurs représentent un joueur vivant. Si l'état n'est pas disponible côté serveur, CDT conserve les métadonnées du framework. Pour une API d'état plus complexe, utilisez l'option avancée.
5. Intégrations avancées et distribution
Les fichiers config/medical_server.lua et config/medical_client.lua restent disponibles pour enchaîner plusieurs appels, interpréter un retour particulier, lire une API d'état ou installer un audit. Les fonctions avancées restent prioritaires sur les réglages simples du côté concerné. Pour un appel client, une fonction avancée serveur peut aussi remplacer toute l'opération avant son transfert au joueur.
Les permissions, le service staff et la protection de la cible sont toujours contrôlés côté serveur par les actions admin. Aucun nom d'export, événement ou paramètre fourni dans une requête de l'interface ne remplace ceux du fichier installé.
Tous les fichiers de cette distribution sont exclus de la protection Asset Escrow (escrow_ignore { '**/*' }), y compris les trois fichiers médicaux. config/medical.lua et config/medical_client.lua sont partagés avec les joueurs : n'y mettez aucun secret. Les fonctions privées et secrets éventuels restent dans config/medical_server.lua.
Vérifier l'installation
- Démarrez l'ambulance avant
cdt_admin, puis vérifiez le fournisseur et le nom de ressource. - Redémarrez
cdt_adminaprès avoir sauvegardé le fichier. - Avec un staff autorisé en service, testez Heal sur un joueur vivant blessé, puis Revive sur un joueur mort ou en état critique.
- Vérifiez les points de vie, blessures, saignements et besoins selon les effets documentés par votre ambulance. Testez aussi sur un second joueur pour vérifier la cible.
Les tests automatisés de CDT couvrent le routage et les paramètres ; la compatibilité avec votre version réelle d'ambulance doit être vérifiée en jeu.
