Courses-poursuites FiveM : les 5 réglages qui comptent

Les courses-poursuites FiveM tiennent sur cinq réglages précis : OneSync, les convars réseau du server.cfg, la gestion du verrouillage des entités, le calibrage des scripts police et fuite, et le handling des véhicules. Sans cette synchronisation, un fuyard traverse les murs aux yeux d'un policier pendant que l'inverse se produit côté serveur. Voici comment régler chacun de ces points pour limiter le desync pendant une poursuite à grande vitesse.

Pourquoi le desync casse les courses-poursuites FiveM

Dans une poursuite, chaque client envoie sa position au serveur, qui doit la valider et la redistribuer à tous les autres joueurs. Plus il y a de véhicules, de tirs et de collisions simultanées, plus ce calcul devient lourd. Un retard de quelques dizaines de millisecondes suffit à décaler la position perçue d'un fuyard par rapport à sa position réelle.

Les symptômes typiques d'une poursuite désynchronisée

• Véhicules qui se téléportent ou disparaissent un instant avant de réapparaître plus loin.
• Collisions qui ne se déclenchent pas alors que les deux modèles 3D se chevauchent visuellement.
• Tirs qui touchent un suspect déjà hors de portée côté serveur.
• Portières ou herses qui s'activent sans effet visible chez l'autre joueur.

Un calcul physique de ce type consomme du temps CPU en continu, surtout quand plusieurs véhicules se percutent au même instant. Un hébergement FiveM adossé à un Ryzen 9 7950X3D absorbe mieux ces pics qu'une machine partagée avec d'autres instances, ce qui réduit directement la fréquence des micro-coupures pendant une poursuite.

OneSync : la base de la synchronisation en poursuite

OneSync est le système qui permet à FiveM de synchroniser plus de 32 joueurs et de gérer les entités réseau (véhicules, peds, objets) de façon cohérente entre tous les clients. Sans lui, le jeu revient au mode legacy, pensé pour de petites sessions, et les poursuites à plusieurs voitures de police deviennent instables très vite.

La licence FiveM reste gratuite, mais dépasser 32 slots et activer OneSync Infinity nécessite un abonnement Element Club côté Cfx.re. C'est ce palier qu'il faut viser dès qu'une communauté police/voleur tourne régulièrement à plus de trente joueurs connectés en simultané pendant les poursuites.

set onesync on
set onesync_population true
set sv_maxclients 48
set sv_entityLockdown "strict"
set sv_filterRequestControl "strict"

Ces lignes activent la synchronisation étendue, laissent le moteur gérer la population d'IA (piétons, trafic) et imposent une attribution stricte de la propriété réseau des entités. Résultat concret : un véhicule change de propriétaire réseau proprement quand il passe d'un joueur à un autre pendant une course.

server.cfg : les convars réseau à calibrer

Deux convars gouvernent directement qui a le droit de créer ou modifier une entité sur le réseau : sv_entityLockdown et sv_filterRequestControl. Mal réglées, elles ouvrent la porte à des conflits de propriété entre le véhicule du fuyard et celui du policier qui le percute.

Valeur	Effet	Usage recommandé
inactive	Aucune restriction, tout client peut créer des entités	À éviter en production
relaxed	Restrictions partielles, certains scripts legacy fonctionnent encore	Transition seulement
strict	Création d'entités strictement contrôlée par le serveur	Recommandé pour les poursuites

En complément, limite le nombre de slots au strict nécessaire avec sv_maxclients. Un palier dimensionné pour le nombre réel de joueurs en poursuite simultanée réduit la charge réseau par entité et laisse plus de marge CPU au calcul physique des collisions.

Scripts de police et de fuite : réduire la charge de calcul

Les scripts de métier (police, GPS, alertes, menottage) tournent souvent en boucle pour vérifier des distances ou des états. Une boucle mal écrite, sans Wait correctement dimensionné, consomme du temps serveur en continu et grignote la marge disponible pour la synchronisation des véhicules.

CreateThread(function()
  while true do
    Wait(500)
    -- vérifie la distance au suspect toutes les 500ms
    -- plutôt qu'à chaque frame
  end
end)

Pour les données de poursuite (sirène active, état menotté, vitesse du véhicule), privilégie les state bags natifs plutôt que des événements réseau répétés. Un state bag ne retransmet la donnée que lorsqu'elle change réellement, ce qui allège nettement le trafic pendant une course à dix véhicules.

Points à vérifier dans un script de fuite

• Fréquence des événements de mise à jour de position (éviter le tick par défaut du client).
• Distance de rendu des blips de poursuite, souvent inutilement élevée.
• Appels redondants à GetEntityCoords sur des dizaines de peds en même temps.

Véhicules et handling : stabiliser la physique en haute vitesse

Le fichier handling.meta définit la masse, la suspension et l'adhérence de chaque véhicule. Des valeurs trop extrêmes (masse très faible, friction excessive) rendent la prédiction physique côté serveur instable, surtout lors d'un contact à haute vitesse entre deux voitures.

Pendant une poursuite, la propriété réseau d'un véhicule migre régulièrement d'un client à l'autre selon la proximité. Un script qui force cette migration via NetworkRequestControlOfEntity sans vérifier l'état du transfert précédent peut créer un conflit de propriété et provoquer un recul brutal du véhicule à l'écran.

Limite aussi le nombre de véhicules actifs simultanément sur la carte avec un système de pooling, qui retire les épaves ou les véhicules inoccupés après un délai court. Moins d'entités physiques actives en permanence, c'est moins de calculs à synchroniser pendant la course elle-même.

Check-list des 5 réglages anti-desync

Pour récapituler concrètement les cinq réglages qui conditionnent la stabilité d'une course-poursuite FiveM, voici l'ordre dans lequel les appliquer avant d'ouvrir une session publique.

1. Activer OneSync (et Infinity via Element Club au-delà de 32 slots) pour gérer correctement la population d'entités.
2. Fixer sv_entityLockdown et sv_filterRequestControl sur strict dans le server.cfg.
3. Optimiser les boucles des scripts police et fuite, et migrer les états partagés vers des state bags.
4. Calibrer le handling.meta des véhicules et activer un pooling pour limiter les entités actives.
5. Dimensionner sv_maxclients et les ressources matérielles au nombre réel de joueurs en poursuite simultanée.

Documente ces valeurs directement dans ton server.cfg avec des commentaires, et teste chaque modification séparément : empiler plusieurs changements à la fois rend impossible d'identifier celui qui a réellement réduit le desync. La documentation officielle détaille l'ensemble des convars disponibles : Documentation OneSync.

Conclusion

Avant d'ajuster quoi que ce soit d'autre, active OneSync et verrouille la gestion des entités en strict : c'est le réglage qui évite le plus de téléportations de véhicules. Ensuite seulement, optimise les scripts de police et de fuite, puis le handling. Une erreur fréquente est d'empiler des mods de gameplay avant d'avoir stabilisé ces bases réseau.

FAQ

Pourquoi un joueur avec un bon ping voit-il quand même des sauts de véhicule ?

Le ping mesure la latence réseau individuelle, pas la charge de calcul du serveur. Si le serveur met du temps à traiter la physique de plusieurs véhicules en collision, tous les joueurs subissent des sauts de position même avec une connexion excellente, car le retard vient du traitement côté serveur et non du trajet des paquets.

Combien de RAM prévoir pour un serveur orienté poursuite avec beaucoup de scripts ?

Un serveur FiveM avec des scripts de police complets (menottage, coffres, radio, alertes) et une trentaine de joueurs actifs demande en général entre 8 et 12 Go de RAM dédiée, en plus de la marge nécessaire pour les pics de population pendant les poursuites à plusieurs véhicules.

Faut-il désactiver les mods graphiques des joueurs pour réduire le desync ?

Non, les mods graphiques côté client (textures, éclairage, effets visuels) n'affectent pas la synchronisation réseau, qui dépend du serveur et des convars OneSync. Seuls les mods qui modifient le comportement physique des véhicules ou interceptent les événements réseau peuvent introduire un décalage avec les autres joueurs.