Alertes du jeu

Les alertes du jeu transforment ce qui se passe sur le serveur en appels dans la file du dispatch : « Braquage d’ATM », « Coups de feu », « Car-jacking », un citoyen qui appelle le 911 depuis son téléphone… Sans que personne ne tape rien.

Capture à venirops-game-alert-dispatch

Une alerte du jeu arrive au dispatch : bip, notification et appel marqué

Il faut l’intégration au jeu et la passerelle supermdt-bridge installée sur le serveur (voir Installer la passerelle).

D’où viennent les alertes

SuperMDT ne remplace pas ton script de dispatch : il travaille avec. La passerelle écoute ce que ton serveur signale déjà et l’envoie au MDT, sans modifier aucun script. Les alertes viennent de :

1. Ton script de dispatch, s’il y en a un : ps-dispatch Testé en jeu, ou cd_dispatch, qs-dispatch et rcore_dispatch Expérimental. Quand un script de braquage ou de crime l’appelle, SuperMDT reçoit la même alerte : code, titre, lieu, position, description, véhicule, sexe du suspect quand le script le donne. Par défaut, son titre en jeu devient la nature de l’appel (Titre du jeu ; ou Nom du type, voir Régler les alertes d’un service), dans la langue du script (voir La langue des titres). core_dispatch n’est pas pris en charge : il n’offre rien à écouter ; appelle l’export Alert à la place.
2. Les détections intégrées de la passerelle : coups de feu, personne à terre, vol de véhicule (voir Les détections de la passerelle).
3. Les alertes du framework : l’alerte police et l’alerte EMS de QBCore et Qbox, les braquages (supérettes, banques) et les commandes /911p et /911e.
4. Les appels au 911 des téléphones (lb-phone, npwd, sd-phone, gksphone, qs-smartphone) : le message et la position de l’appelant deviennent un appel, avec son nom et son numéro (et un lien vers sa fiche citoyen quand son personnage est connu).
5. Les scripts maison, par l’export Alert de la passerelle (voir Pour les développeurs).

Pas de doublon

Quand un script de dispatch est écouté, les détections de la passerelle se coupent d’elles-mêmes (mode auto de Config.AlertDetections), et les écoutes du framework (alerte police et EMS, braquages, /911p et /911e) sont coupées par défaut : ton script signale déjà ces faits, la passerelle ne les envoie pas une deuxième fois. Tu peux en réactiver une (voir Les écoutes de la passerelle). Sans script de dispatch, tout reste actif.

Voir ce que ton serveur utilise

La passerelle annonce ses sources à SuperMDT quand elle se présente, puis toutes les 10 minutes et à chaque changement de réglage. Deux endroits les affichent :

• Configuration › Jeu › Intégrations, ligne Alertes et dispatch : le script de dispatch écouté (ou « Aucun script de dispatch détecté »), les autres écoutes actives (Écoute aussi) et celles qui sont coupées (Écoutes coupées), les téléphones écoutés pour le 911, l’état des détections (« actives », « coupées : ps-dispatch s’en charge » ou « coupées dans la configuration du serveur de jeu ») et le niveau de prise en charge du script, avec le même badge que les autres lignes de la page. En dessous, un interrupteur par écoute présente (voir Les écoutes de la passerelle). Si les alertes sont coupées côté serveur de jeu (Config.Alerts), un avertissement le dit : rien n’est envoyé. Le lien Régler les alertes du jeu mène à la carte du service (ci-dessous).
• Configuration › Opérations › Alertes du jeu, encadré D’où viennent les alertes en tête de la carte : les mêmes sources, avec le nom du script détecté, et le lien Comment ça marche vers cette page. Tant que la passerelle ne s’est pas encore annoncée, l’encadré reste général.

Capture à venirgame-integrations

Configuration › Jeu › Intégrations, dont la ligne « Alertes et dispatch »

supermdt status, dans la console du serveur, donne le même détail avec ses compteurs, chaque écoute (« policeAlert (coupée, par défaut) ») et les codes d’alerte retenus.

Les écoutes de la passerelle

Un script de dispatch comme ps-dispatch reçoit déjà les alertes des scripts de braquage, de drogue ou de mort. Si la passerelle écoutait en plus l’alerte police du framework, les braquages de QBCore ou /911p, le même fait arriverait deux fois, ou des alertes sans intérêt s’y ajouteraient. Donc, quand un script de dispatch est écouté :

Écoute	Par défaut
Le script de dispatch (ps-dispatch, cd_dispatch, qs-dispatch, rcore_dispatch)	toujours écouté
Alerte police du framework (policeAlert), alerte EMS (ambulanceAlert), braquages (robberies), /911p et /911e (qbCommands), relais du 911 de Qbox (relay911)	coupées
Appels au 911 des téléphones (lb-phone, npwd, sd-phone, gksphone, qs-smartphone)	actives : ps-dispatch ne reçoit que ses propres commandes /911 et /311, jamais les appels ni les messages des téléphones (vérifié dans son code)

Sans script de dispatch, rien ne change : toutes les écoutes présentes sont actives.

Dans Configuration › Jeu › Intégrations, ligne Alertes et dispatch, chaque écoute présente sur ton serveur a son interrupteur, avec son défaut (« Coupée par défaut : ps-dispatch s’en charge ») ou « Réglée par l’organisation ». Active celle dont tu as besoin, par exemple un script de braquage qui n’envoie ses alertes qu’à l’alerte police du framework ; Revenir au défaut efface ton choix. Il faut la permission Régler le jeu ; chaque changement est écrit au journal d’audit et arrive en jeu en quelques secondes : la passerelle ne branche que les écoutes permises et ignore les événements de celles qui sont coupées.

Capture à venirgame-alert-listeners

Les écoutes de la passerelle, une par une, dans Configuration › Jeu › Intégrations

Config.Alerts.listen et Config.Alerts.phones (config_alerts.lua) gardent le dernier mot côté serveur de jeu : une écoute à false n’est jamais branchée, quoi que dise SuperMDT.

Scripts et téléphones compatibles

Testé en jeu essayé en jeu sur un vrai serveur. Vérifié sur le code la signature a été lue dans le code source publié du script, pas encore essayé en jeu. Expérimental écrit d’après la documentation de l’éditeur (script chiffré) ; vérifie-le sur ton serveur avant de t’y fier. supermdt status dans la console du serveur liste ce qui est écouté.

Script	Ce qui est écouté	Statut
ps-dispatch (v2, v3 ; v1)	événement ps-dispatch:server:notify (v1 : dispatch:server:notify), y compris /911 et /311 ; /911a et /311a restent anonymes (ni nom, ni numéro, ni licence) ; une alerte destinée seulement à des métiers qui ne sont pas des services d’urgence (mécano…) n’est pas envoyée	Testé en jeu
Alerte police de QBCore et Qbox	police:server:policeAlert (qb-policejob, qbx_police)	Vérifié sur le code
Alerte EMS de QBCore et Qbox	hospital:server:ambulanceAlert (qb-ambulancejob, qbx_ambulancejob) ; Qbox : bouton d’urgence EMS (hospital:server:emergencyAlert, qbx_radialmenu) et dernier souffle (qbx_medical:server:onPlayerLaststand)	Vérifié sur le code
Braquages de QBCore et Qbox	l’événement du braqueur : qb-storerobbery:server:callCops, qb-bankrobbery:server:callCops, qbx_bankrobbery:server:callCops	Vérifié sur le code
/911p et /911e de QBCore	QBCore:Server:PreCommandExecution (qb-core), pour les commandes de qb-policejob et qb-ambulancejob	Vérifié sur le code
/911p et /911e de Qbox	relayés par le client d’un agent en service (qbx_police, qbx_ambulancejob)	Vérifié sur le code
cd_dispatch, cd_dispatch3d	cd_dispatch:AddNotification	Expérimental
qs-dispatch	qs-dispatch:server:CreateDispatchCall	Expérimental
rcore_dispatch	rcore_dispatch:server:sendAlert	Expérimental
core_dispatch	rien d’écoutable (exports seulement)	Non pris en charge : appelle l’export Alert
npwd	appels aux numéros d’urgence (onCall, 911 et 912 par défaut), réenregistrés tout seuls après un restart npwd	Vérifié sur le code
sd-phone	messages de l’appli Services (sd-phone:server:services:message) et appels aux sociétés d’urgence (sd-phone:server:call:started) ; ses imitations de lb-phone et gksphone ne sont jamais écoutées en plus : pas de doublon	Vérifié sur le code
lb-phone	messages et appels aux sociétés d’urgence (police, ambulance…) ; seulement le vrai lb-phone, pas une ressource qui l’imite	Expérimental
gksphone (v2)	signalements aux services (gksphone:services:newReport)	Expérimental
qs-smartphone, qs-smartphone-pro	alertes aux métiers, messages SOS	Expérimental

Attention

Avec cd_dispatch « Classic », une alerte envoyée depuis le serveur passe directement aux joueurs (TriggerClientEvent) : elle ne peut pas être écoutée. Celles envoyées depuis le client du joueur, comme le recommande Codesign, le sont.

Les braquages de QBCore et Qbox

qb-storerobbery, qb-bankrobbery et qbx_bankrobbery préviennent la police en deux temps : le client du braqueur envoie un événement au serveur (callCops), puis chaque policier en service renvoie l’alerte depuis sa propre position. La passerelle lit le premier : une seule alerte « Braquage », à la position du braquage (refusée si elle est à plus de 250 m du braqueur), même sans policier en service. Pendant les 15 s qui suivent, les renvois des policiers sont ignorés (sauf un agent à terre). Sans cet adaptateur (Config.Alerts.listen.robberies = false), un même texte renvoyé par plusieurs policiers ne fait toujours qu’une alerte. qbx_storerobbery envoie une alerte police sans texte depuis le client du braqueur : elle devient un braquage.

Les commandes /911p et /911e

• QBCore (qb-policejob, qb-ambulancejob) : la passerelle lit la commande au moment où le joueur la tape (QBCore:Server:PreCommandExecution, un événement serveur de qb-core). /911p devient un appel d’urgence (police), /911e un appel d’urgence (secours), avec le nom, le numéro et la fiche de l’appelant (ces scripts n’ont pas de variante anonyme), même sans agent en service. Réglage : Config.Alerts.listen.qbCommands.
• Qbox (qbx_police, qbx_ambulancejob) : ces commandes ne déclenchent aucun événement écoutable ; elles écrivent seulement aux agents en service. Le client de la passerelle, chez un agent en service, relaie ce qu’il reçoit. Le serveur vérifie que l’agent est bien en service et qu’un seul joueur se trouve à moins de 6 m du point (il devient l’appelant ; Config.Alerts.relay.callerRadius), ne garde qu’un relais du même texte (15 m, 10 s), et ignore ce qu’il a déjà reçu autrement (alerte police ou EMS) ainsi que les plaques signalées par les radars de qbx_police. Réglage : Config.Alerts.listen.relay911.

Attention

Sur Qbox, sans aucun agent en service, un /911p ou un /911e n’arrive pas au MDT : personne ne peut le relayer.

La langue des titres

Le titre d’une alerte vient du script, dans sa langue : ps-dispatch écrit « Discharge of a firearm » en anglais. ps-dispatch passe par les langues d’ox_lib et fournit une traduction française (locales/fr.json : « Fusillade », « Braquage de magasin »…). Dans le server.cfg, avant ensure ps-dispatch :

setr ox:locale fr

setr (et pas set) : les alertes de ps-dispatch sont écrites chez le joueur, qui doit recevoir le réglage. ox_lib laisse aussi chaque joueur choisir sa langue (/ox_lib) ; pour imposer la langue du serveur à tous, ajoute setr ox:userLocales 0.

Pour ne pas dépendre de la langue du script, règle la nature du type sur Nom du type : l’appel s’appelle « Coups de feu », quel que soit le titre envoyé (voir Régler les alertes d’un service).

Les textes des scripts

Un script sans code radio est classé d’après son texte (Config.Alerts.patterns, puis Config.Alerts.keywords dans config_alerts.lua), avec les textes réels des scripts courants, en anglais et en français : « Officer Doe | 12 Down » ou « Officier Doe | 12 Au sol » (qb-policejob, qbx_police) et « Doctor Doe Down » (qbx_ambulancejob) donnent Agent à terre ; « Storerobbery in progress » un braquage ; « Suspicous activity » (orthographe réelle de qb-drugs) une activité suspecte ; « Civilian Died » ou « Civil décédé » une personne à terre. Sur QBCore, un agent à terre crée une alerte police et une alerte EMS.

Les détections de la passerelle

Chacune s’active ou se coupe dans config_alerts.lua (Config.AlertDetections). Par défaut (mode = 'auto'), elles ne tournent que si aucun script de dispatch n’est démarré, pour ne pas signaler deux fois la même chose.

Détection	Quand	Réglages
Coups de feu	le joueur tire avec une arme à feu, en ville, près d’au moins un passant non-joueur	rayon des témoins, nombre minimal, zones « en ville », zones exclues (stands de tir d’Ammu-Nation par défaut), armes ignorées (taser, extincteur…), silencieux
Personne à terre	le joueur est mort ou à terre depuis 15 s (ou selon les scripts d’EMS, voir ci-dessous) ; un agent en service devient « Agent à terre »	délai, témoins, états reconnus
Vol de véhicule	effraction d’un véhicule verrouillé, car-jacking ; une fois par véhicule	témoins, effraction et car-jacking séparés

Personne à terre selon le script d’EMS. Avec qb-ambulancejob (QBCore), le personnage à terre est ressuscité par le script et GTA ne le voit pas mort : la passerelle lit côté serveur les métadonnées isdead et inlaststand du personnage et le marque elle-même à terre. Avec qbx_medical (Qbox) et esx_ambulancejob (ESX), elle lit l’état isDead posé par ces scripts ; sur ESX, la mort (esx:onPlayerDeath, jusqu’à esx:onPlayerSpawn) compte aussi.

Car-jacking. Tenter de monter par la place du conducteur dans un véhicule conduit par un PNJ vivant est un car-jacking, que la portière soit verrouillée ou non : qb-vehiclekeys (Config.LockNPCDrivingCars, activé par défaut) verrouille la voiture d’un PNJ dès la tentative. Côté passager, ce n’est pas un car-jacking (une effraction si le véhicule est verrouillé). Le car-jacking à l’arme (viser le conducteur) est signalé par qb-vehiclekeys et qbx_vehiclekeys eux-mêmes, selon leur probabilité (« Vehicle theft in progress. Type: carjack »).

Les métiers de service en service (reliés dans SuperMDT) ne déclenchent ni coups de feu ni vol de véhicule ; ignoreJobs en ajoute d’autres. La détection tourne chez le joueur, mais le serveur relit la position du personnage, le métier et les zones exclues, et limite la cadence : un client modifié ne peut rien inventer.

Régler les alertes d’un service

Dans Configuration › Opérations, choisis le service, puis la carte Alertes du jeu. Il faut la permission Alertes du jeu › Régler (commandement par défaut).

Les types reçus sont les catégories de SuperMDT : chaque alerte venue du jeu est rangée dans un type (coups de feu, braquage…), qui décide si elle est reçue, sa priorité et la nature de l’appel. Sous la carte, les alertes réellement vues sur ton serveur montrent dans quel type chacune va.

Capture à venirsettings-game-alerts

Configuration › Opérations › Alertes du jeu

1. Active Recevoir les alertes du jeu (désactivé par défaut).
2. Choisis les types reçus : coups de feu, braquage, vol de véhicule, car-jacking, personne à terre, agent à terre, bagarre, explosion, incendie, stupéfiants, activité suspecte, appel d’urgence (police), appel d’urgence (secours), autre. Un service de police et un service médical partent chacun d’une sélection proposée.
3. Pour chaque type, l’icône de réglage ouvre sa feuille : la priorité de l’appel et sa nature :
   • Titre du jeu (par défaut) : le titre envoyé par le script (« Discharge of a firearm »), dans sa langue ; sans titre, le nom du type ;
   • Nom du type : toujours le nom du type (« Coups de feu »), quelle que soit la langue du script ;
   • Liste des natures : une nature de la liste des types d’appel du service ;
   • Modèle d’appel : un modèle d’appel (nature, description et notes types).
4. Règle la fusion, le plafond et la notification (ci-dessous), puis Enregistrer.

Plusieurs services peuvent recevoir le même type : une fusillade peut créer un appel au LSPD et un autre chez les EMS. Quand le script vise un métier (ps-dispatch jobs, cd_dispatch job_table…), seuls les services de ce type la reçoivent, s’il y en a parmi ceux qui reçoivent ce type. La priorité vient toujours du réglage du service : un script ne peut pas rendre toutes ses alertes urgentes.

Capture à venirsettings-game-alert-kind

La feuille d’un type : priorité et nature de l’appel (Titre du jeu, Nom du type, liste, modèle)

Les alertes détectées et leur type

Sous les alertes du service, la carte Alertes du jeu détectées montre ce que ton serveur envoie vraiment : chaque code d’alerte (le codeName de ps-dispatch, le type de rcore_dispatch, le code de l’export Alert…) avec un exemple de titre, le script, et combien de fois il a été vu (« vu 14 fois », et quand). Pour ps-dispatch, la passerelle lit aussi la liste complète de ses alertes dans ses fichiers (client/alerts.lua et Config.Blips, avec le titre de sa langue) : celles qui ne sont jamais arrivées apparaissent comme « Dans la liste du script, pas encore vue ». Les plus vues d’abord ; recherche par code ou par titre ; 20 affichées, puis Afficher plus (150 codes au plus par organisation).

Capture à venirsettings-game-alert-codes

Les alertes détectées sur le serveur et le type où chacune va

Pour chaque code, choisis le type où il va :

• Automatique : Coups de feu (par défaut) : le type trouvé par la passerelle (config_alerts.lua : codes, motifs, mots-clés) ;
• un autre type : par exemple speeding (excès de vitesse) vers Activité suspecte, ou hunting vers Autre alerte ;
• Ignorer : la passerelle ne l’envoie plus du tout (il reste dans la liste, avec son compteur, pour changer d’avis).

Ton choix l’emporte sur config_alerts.lua et vaut pour toute l’organisation ; chaque service décide ensuite s’il reçoit ce type. Il faut la permission Régler le jeu pour changer un rattachement (les autres le voient, verrouillé) ; chaque changement est écrit au journal d’audit et arrive en jeu en quelques secondes. La passerelle applique le rattachement avant de filtrer les types reçus : un code rattaché à un type qu’un service reçoit part, même si son type automatique n’était reçu par personne.

La passerelle regroupe ce qu’elle voit : un nouveau code arrive dans la liste en 15 secondes environ, les compteurs toutes les 5 minutes, et rien n’est envoyé tant que rien ne change.

La fusion des signalements

Vingt passants qui entendent la même fusillade ne font qu’un appel. Deux alertes du même type, à moins du rayon de fusion (150 m par défaut) du premier signalement et moins du délai de fusion (5 min par défaut) après le signalement précédent, sont fusionnées : l’appel garde sa place, son compteur avance (« 12 signalements ») et chaque signalement s’ajoute à son journal (les 20 premiers ; ensuite, seul le compteur). 0 au rayon ou au délai : jamais de fusion. Un appel clos ne reçoit plus rien : l’alerte suivante crée un nouvel appel.

Le plafond

Au plus 60 appels créés par des alertes par heure dans le service (réglable de 1 à 500). Au-delà, les alertes sont ignorées jusqu’à l’heure suivante et le dépassement est écrit une fois au journal d’audit (« Système a ignoré des alertes du jeu »). Les signalements fusionnés ne comptent pas. S’y ajoutent une limite pour toute l’organisation (120 alertes par minute) et, sur le serveur de jeu, une cadence par joueur (6 par minute, une du même type toutes les 10 s, journal dans la console au dépassement) et pour tout le serveur (60 par minute).

Au dispatch

L’appel arrive dans la file avec l’icône Alerte du jeu et, dès le deuxième signalement, le compteur. Sa fiche indique le type et l’origine : script de dispatch, détection de la passerelle, appel au 911 ou script du serveur, avec la ressource et le code radio.

Capture à venirops-game-alert-call

La fiche d’un appel d’alerte et ses signalements fusionnés

Pour une alerte importante (à partir de la priorité Haute par défaut, réglage Bip et notification au dispatch), le dispatch entend un double bip et voit une notification avec Voir l’appel, même si le son des nouveaux appels est coupé. Rien n’est écrit en base en continu : la position n’est posée qu’une fois, sur l’appel.

Pour les développeurs

Un script du serveur (braquage maison, système d’alarme…) envoie une alerte ainsi :

exports['supermdt-bridge']:Alert({
    kind = 'robbery',              -- facultatif : sinon déduit de code, title, message
    code = '10-90',
    title = 'Braquage de la bijouterie',
    message = 'Alarme silencieuse déclenchée',
    coords = vector3(-630.0, -236.0, 38.0),
    street = 'Rockford Hills',
    service = 'police',            -- ou 'ems', un métier, une liste
    gender = 'male',
    vehicle = { model = 'Sultan', plate = 'AB12CD', color = 'Bleu' },
    player = source,               -- facultatif : sans coords, sa position
})

L’export renvoie true si l’alerte part, sinon false et la raison (notReceived : aucun service ne reçoit ce type ; playerLimit, serverLimit, duplicate, far…). Côté joueur, le même export existe : l’alerte passe par le serveur, qui la vérifie comme toute alerte d’un joueur (position proche de son personnage, cadence). priority n’est pas lu : la priorité est celle du service. Types : shooting, robbery, vehicleTheft, carjacking, personDown, officerDown, fight, explosion, fire, drugs, suspicious, emergencyCall, medicalCall, other.

Le code d’un script de dispatch est traduit en type par Config.Alerts.codes puis par des mots-clés (Config.Alerts.keywords) : ajoute les tiens dans config_alerts.lua. Un code passé à l’export est retenu comme ceux des scripts de dispatch (sous le nom de ta ressource) : l’organisation peut le rattacher à un autre type ou l’ignorer depuis Les alertes détectées.

Note

La passerelle n’envoie que les types reçus par au moins un service : un changement de ces réglages arrive en jeu en quelques secondes.