Comprendre Resmon et les performances des scripts
Le resmon La commande dans FiveM affiche les mesures de performances des ressources en temps réel, indiquant le nombre de millisecondes consommées par chaque script par tick de serveur. Un script bien optimisé devrait afficher 0,00 ms en résolution la plupart du temps, avec une augmentation brève uniquement lors du traitement actif des événements. Les scripts qui affichent systématiquement des valeurs de resmon élevées dégradent les performances du serveur, augmentent la désynchronisation des joueurs et peuvent provoquer le redoutable décalage du serveur qui éloigne les communautés. Le profilage régulier de tes scripts est la première étape vers le maintien d'un serveur fluide.
Gestion des fils de discussion et temps d'attente
Le plus gros problème de performances dans les scripts FiveM est une mauvaise gestion des threads. En utilisant Citizen.Wait(0) à l'intérieur d'une boucle signifie que ton code exécute chaque image, soit environ 60 fois par seconde. La plupart des tâches n'ont pas besoin de cette fréquence. Augmentez tes temps d'attente pour Wait(500) ou Wait(1000) pour les contrôles qui ne doivent être exécutés que périodiquement, comme la détection de proximité pour les marqueurs ou les contrôles de zone. Pour les systèmes basés sur la distance, utilisez une approche à plusieurs niveaux dans laquelle tu vérifies à des intervalles plus longs lorsque tu es loin des points d'intérêt et à des intervalles plus courts lorsque tu es à proximité.
Désactiver les discussions inutiles
Au lieu d’exécuter des threads en continu, envisagez de les activer uniquement en cas de besoin. Utilisez des événements ou des changements d’état pour démarrer et arrêter les boucles de traitement. Par exemple, un script de pêche n'a pas besoin d'exécuter sa boucle de lancement lorsque le joueur n'est pas près de l'eau. Suivez une variable d'état active et quittez le thread avec return lorsque la fonctionnalité n’est pas utilisée. Ce modèle peut réduire ton script de 0,50 ms constant à 0,00 ms pendant les périodes d'inactivité, ce qui constitue la différence entre un script qui évolue et un autre qui paralyse ton serveur.
Mise en cache et évitement des appels redondants
Les appels de fonctions natives dans FiveM entraînent une surcharge, en particulier lorsqu'ils sont appelés à plusieurs reprises dans des boucles étroites. Cachez les résultats des appels comme GetEntityCoords, GetPlayerPed, et GetPlayerServerId au début de ton itération de boucle plutôt que de les appeler plusieurs fois au cours du même cycle. Stockez les données statiques telles que les valeurs de configuration, les positions des marqueurs et les coordonnées des points dans des variables locales au moment du chargement du script. Cette technique simple peut réduire considérablement le temps d’exécution de ton script et constitue l’une des optimisations les plus efficaces que tu puissies réaliser.
Optimisations mathématiques
Les calculs de distance font partie des opérations les plus courantes dans les scripts FiveM. Remplacer la norme #(coords1 - coords2) vérification de la distance avec des comparaisons de distance au carré lorsque tu n'avez besoin que d'une distance relative. Étant donné que le calcul de la racine carrée est coûteux, la comparaison des distances au carré avec les seuils au carré permet d'obtenir le même résultat sans opération mathématique coûteuse. De plus, évitez d'appeler GetDistanceBetweenCoords natif lorsque tu peux calculer la distance dans Lua, car les appels natifs entraînent une surcharge supplémentaire par rapport aux opérations Lua pures.
Gestion des entités et des Blips
La création d'entités, de blips et de marqueurs entraîne des coûts de rendu et de réseau. Supprimez les blips et les entités lorsqu'ils ne sont plus nécessaires plutôt que de les laisser dans le monde du jeu. Utiliser DrawMarker uniquement lorsque le joueur est à distance de rendu, et non globalement sur toute la carte. Pour les scripts qui gèrent de nombreuses entités, implémentez le partitionnement spatial pour traiter uniquement les objets proches. Pensez à utiliser des systèmes de streaming qui créent et détruisent des entités en fonction de la proximité des joueurs plutôt que de tout charger en même temps au démarrage de la ressource.