Une configuration de police complète pour FiveM repose généralement sur plusieurs systèmes plutôt que sur une seule ressource. Le métier de police gère les services et les interactions, un MDT ou un CAD organise les dossiers, et le dispatch transmet les incidents et les informations sur les unités. Les cartes, véhicules, preuves et procédures médicales peuvent compléter ces systèmes centraux. Ce guide d’achat distingue les responsabilités afin que les propriétaires de serveurs choisissent des composants compatibles plutôt que des fonctionnalités redondantes.
Comprendre les trois couches principales
| Couche | Responsabilité habituelle | Questions à poser avant l’achat |
|---|---|---|
| Métier de police | État de service, grades, interactions, arrestations, accès aux preuves ou à l’armurerie | Quels systèmes de framework, d’inventaire et de ciblage utilise-t-il ? |
| MDT ou CAD | Profils, rapports, mandats, véhicules, incidents et permissions | Comment les personnages, les métiers et les enregistrements de la base de données sont-ils identifiés ? |
| Dispatch | Alertes, indicatifs radio, unités, marqueurs de carte, itinéraires et coordination des intervenants | Quels événements et exports relient les métiers, le téléphone et les alertes personnalisées ? |
Certains produits combinent deux ou trois couches. Cela peut réduire le travail d’intégration, mais aussi faire doublon avec un système existant. Avant vos achats, dressez une liste simple des responsabilités : un système gère l’état de service, un autre centralise les rapports et un autre les appels du dispatch. Si deux ressources créent toutes deux des alertes ou des dossiers, décidez quelle intégration désactiver.
Commencer par la compatibilité du framework et des identifiants
Confirmez l’intégration exacte à ESX, QBCore ou QBOX et l’identifiant de personnage utilisé par chaque couche. Un métier de police peut enregistrer les grades différemment d’un MDT, tandis qu’un serveur multicharacter peut nécessiter un identifiant précis de citoyen ou de personnage. Vérifiez comment les permissions correspondent aux noms de métiers et aux grades, si les états hors service sont pris en charge et comment les indicatifs radio sont enregistrés.
Listez les dépendances d’inventaire, de ressource de ciblage, de bibliothèque de menus, de pilote de base de données, de téléphone et de voix. Vérifiez que chaque version requise convient au serveur et que l’intégration utilise son interface documentée.
Concevoir le parcours d’un incident avant l’installation
Parcourez un incident réaliste du début à la fin. Une action civile ou un appel manuel crée une alerte. Le dispatch la transmet aux unités éligibles. Un agent l’accepte, se rend sur les lieux et consigne le résultat dans le MDT. Des preuves ou des objets d’inventaire peuvent être créés, et le personnel médical peut avoir besoin d’une procédure associée. Cet exercice révèle les événements manquants et les responsabilités en double avant que les joueurs en subissent les effets.
Demandez si les alertes peuvent être créées via des exports ou événements documentés, comment les unités changent de statut, comment les marqueurs de carte expirent et si l’historique du dispatch est lié aux rapports. Si une application téléphonique crée des appels d’urgence, vérifiez aussi son intégration. Une fonctionnalité visible dans une démonstration ne prouve pas qu’un téléphone ou un métier tiers se connectera automatiquement.
Adapter les systèmes au commissariat et à l’environnement
Les serrures, salles des preuves, armureries, garages et ascenseurs peuvent nécessiter des coordonnées ou des zones correspondant à l’intérieur installé. Utilisez les vérifications de compatibilité MLO pour identifier les conflits de cartes, puis vérifiez chaque point d’interaction.
Installer les composants dans un ordre sûr
- Sauvegardez la base de données et les ressources de police actuelles.
- Installez les bibliothèques partagées et les passerelles du framework.
- Configurez le métier de police et vérifiez les grades, la prise de service et les interactions.
- Ajoutez le MDT et testez les dossiers des personnages, des véhicules, des rapports et des permissions.
- Ajoutez le dispatch et testez les alertes manuelles, automatiques et issues du téléphone.
- Reliez le commissariat, les portes, l’inventaire, les preuves et les procédures médicales.
Testez avec au moins deux rôles policiers et un rôle civil, y compris les reconnexions et les refus de permission. Vérifiez que les incidents, dossiers et preuves sont conservés après le redémarrage prévu et qu’un seul système assume chaque responsabilité.
Tester le cycle complet d’un incident
Le test d’intégration essentiel ne consiste pas seulement à vérifier que chaque interface s’ouvre. Il faut vérifier qu’un incident conserve le même lieu, le contexte de l’appelant, le statut et les unités affectées, de sa création dans le dispatch à sa clôture. Préparez un scénario de préproduction couvrant la réception de l’appel, l’affectation par l’opérateur, l’accusé de réception de l’agent, la consultation du MDT, les changements de statut et la clôture.
- Vérifiez séparément les permissions des civils, des opérateurs du dispatch, des agents, des responsables et des administrateurs.
- Vérifiez que les reconnexions et les redémarrages de ressources ne dupliquent pas les incidents actifs et ne font pas perdre le statut des unités.
- Vérifiez les règles de conservation avant de stocker des noms, rapports, images ou autres données liées aux joueurs.
- Documentez quelle ressource gère les alertes, les dossiers et les preuves afin que deux systèmes n’écrivent pas des données contradictoires.
Un ensemble plus réduit de systèmes aux responsabilités bien définies est généralement plus simple à exploiter que plusieurs ressources de police qui se recoupent.