FiveM prend officiellement en charge Lua, JavaScript et C#. Choisissez le runtime qui correspond à votre framework, aux compétences de votre équipe et aux bibliothèques requises, et non à un classement de performances universel supposé. Les trois peuvent appeler les natives FiveM, gérer les événements et exposer les API de ressources. Les différences pratiques sont la limite du runtime, l'écosystème de packages, le flux de travail de construction et le code déjà utilisé par vos dépendances.
Les exemples de configuration et de code ici ciblent FiveM pour GTA V Legacy. Enhanced a des règles d'exécution et de compatibilité différentes ; vérifiez les changements Legacy-to-Enhanced de Cfx.re avant de les appliquer à un serveur Enhanced.
Comparaison des langages FiveM
| Runtime | Bonne adéquation | Limite importante | Flux de travail typique |
|---|---|---|---|
| Lua | Frameworks Lua existants, ressources compactes et exemples FiveM directs | CfxLua est un runtime Lua 5.4 modifié, pas une installation Lua système arbitraire | Modifiez les fichiers source et chargez-les via le manifeste de ressource |
| JavaScript | Équipes utilisant les outils JavaScript/TypeScript et npm | Les scripts client ne reçoivent pas les API de navigateur ou Node.js ; les scripts serveur utilisent le runtime Node de FiveM | Exécutez la source directement ou compilez/regroupez TypeScript en JavaScript listé dans le manifeste |
| C# | Équipes .NET, code de domaine typé et projets compilés | La ressource doit livrer les assemblages et les fichiers attendus par le runtime Cfx.re | Construire à partir d'un modèle Cfx.re, puis déployer la sortie de la construction |
Lua : le chemin direct du framework
Cfx.re présente CfxLua en tant que runtime Lua 5.4 modifié. Cela est important lorsque vous comparez le code FiveM avec d'anciens tutoriels Lua : les fonctionnalités du langage et le comportement du runtime doivent être vérifiés par rapport à CfxLua, et non déduits du package du système d'exploitation d'un serveur.
Lua est généralement le choix le moins perturbateur lorsque le framework et les ressources voisines sont déjà écrits en Lua. Vous pouvez conserver les événements, les exportations et la configuration partagée dans le même langage et éviter d'ajouter une étape de construction uniquement pour le style. Un petit manifeste peut lister des scripts client, serveur et partagés distincts. Gardez les secrets et les vérifications d'autorité côté serveur hors des fichiers clients, même lorsque les deux côtés utilisent Lua.
La syntaxe courte facilite la lecture des gestionnaires d'événements, mais elle ne remplace pas la conception d'interface. Documentez chaque charge utile d'événement, validez les valeurs sur le serveur et évitez de traiter un événement client comme une preuve que l'argent, l'inventaire ou les autorisations sont valides.
JavaScript et TypeScript : sachez quel côté est en cours d'exécution
Le guide officiel de l’environnement d’exécution JavaScript décrit la prise en charge d’ES2017 et une distinction essentielle entre client et serveur. Les scripts clients s’exécutent dans l’environnement client de FiveM et ne disposent ni des API du navigateur ni de celles de Node.js. Les scripts serveurs utilisent un environnement Node.js personnalisé. Pour l’environnement Legacy, la version serveur par défaut documentée est Node.js 16 ; une ressource peut choisir Node.js 22 en ajoutant node_version '22' dans fxmanifest.lua.
Ne supposez pas qu’un paquet fonctionnant dans un projet Node ordinaire fonctionne aussi dans un script client FiveM. Gardez côté serveur les dépendances liées au système de fichiers, à la base de données et les dépendances npm destinées au serveur. Pour les définitions de l’éditeur et de TypeScript, Cfx.re publie les paquets @citizenfx/client et @citizenfx/server. Ils améliorent la vérification des types, mais ne donnent pas accès aux API absentes de l’environnement d’exécution choisi.
FiveM documente également les contraintes d'affinité de thread pour certains appels natifs côté serveur. Lorsque le code Node asynchrone doit revenir au thread de jeu principal, suivez les directives d'exécution et utilisez setImmediate si nécessaire. Testez le JavaScript compilé que vous déployez réellement, y compris les cartes sources et l'ordre de démarrage, plutôt que seulement la source TypeScript.
C# : utilisez la forme de projet prise en charge
La documentation de l’environnement d’exécution C# fournit les modèles de projet et les consignes de compilation actuels. Commencez par là plutôt que de copier une ancienne organisation d’assemblies provenant d’une application .NET sans rapport. Une ressource C# possède normalement un projet qui référence les assemblies CitizenFX pris en charge, compile son code et place les fichiers produits là où le manifeste peut les charger.
C# peut être un excellent choix lorsque l'équipe utilise déjà les types, les outils et les pratiques de test .NET. Le compromis est opérationnel : les contributeurs et l'intégration continue ont besoin du SDK et de la commande de construction corrects, et l'artefact déployé doit rester synchronisé avec sa source. Enregistrez le modèle, le framework cible et le processus de publication dans le référentiel afin qu'une mise à jour du serveur soit reproductible.
Le modèle commun : manifestes, fonctions natives, événements et exports
Le choix du langage ne modifie pas le contrat de ressource. Chaque ressource a besoin d'un fxmanifest.lua qui déclare les métadonnées et les fichiers à charger. Le code client s'exécute pour les joueurs connectés ; le code serveur s'exécute sous FXServer. Les fichiers partagés sont livrés aux deux côtés, ils ne doivent donc pas contenir d'informations d'identification ou de décisions de confiance uniquement côté serveur.
- Les fonctions natives exposent les fonctions du jeu et de la plateforme. Consultez la référence actuelle des fonctions natives et vérifiez si la fonction concernée s’exécute côté client ou côté serveur.
- Les événements transmettent des messages au sein d’un contexte ou entre le client et le serveur. Considérez les données reçues du réseau comme non fiables et validez-les côté serveur.
- Les exports publient des fonctions pour les autres ressources. Documentez les noms, les paramètres, les valeurs de retour et les dépendances nécessaires au démarrage.
- Dépendances appartiennent au manifeste ou à l'ordre de démarrage du serveur lorsqu'une autre ressource doit être disponible en premier.
Un serveur utilisant plusieurs langages est normal. La limite stable est l'événement ou l’export documenté, et non le langage d'implémentation qui le sous-tend. Cela permet de remplacer une ressource sans réécrire toute la pile.
Comment choisir pour un projet réel
- Commencez par le framework. Si le serveur dépend d'une ressource ESX, QBCore, Qbox établie ou autonome, utilisez ses points d'extension et ses conventions linguistiques pris en charge.
- Listez les bibliothèques requises. Confirmez que chaque pilote de base de données, pont UI et package est compatible avec le client ou le runtime serveur où il sera exécuté.
- Tenez compte de l’équipe. Privilégiez le langage que les contributeurs pourront relire, tester et maintenir après le départ de l’auteur initial.
- Définissez le processus de compilation. Lua peut être livré directement ; TypeScript et C# nécessitent généralement une compilation reproductible et un répertoire de sortie clair.
- Créez un prototype des interfaces entre les composants. Vérifiez le fonctionnement d’un appel natif, d’un événement réseau validé par le serveur, d’un export et d’un redémarrage de dépendance avant de développer la fonctionnalité complète.
Liste minimale de vérifications
- Démarrez la ressource sur un serveur de staging et inspectez les journaux du serveur et du client F8.
- Reconnectez un client propre et redémarrez la ressource pour exposer les fichiers manquants ou les hypothèses d'ordonnancement.
- Envoyez des charges utiles d'événements invalides et non autorisées et confirmez que le serveur les rejette.
- Vérifiez la version de Node documentée ou la sortie de build .NET sur l'hôte de déploiement réel.
- Épinglez les versions des dépendances et conservez une copie de restauration de la dernière ressource fonctionnelle.
Rien ne permet d’affirmer, preuves à l’appui, qu’un des trois langages de programmation FiveM est toujours le plus rapide ou le plus populaire pour toutes les ressources. Choisissez Lua, JavaScript/TypeScript ou C# selon les capacités documentées du runtime pris en charge, le framework utilisé et le coût de maintenance que votre équipe peut assumer.
Différences du runtime Enhanced
Enhanced modifie l'environnement d'exécution JavaScript et C# ainsi que certains comportements de la plateforme. Utilisez la documentation pour l'édition client/serveur exacte plutôt que d'appliquer les hypothèses Legacy Node ou Mono. Reconstruisez et testez les dépendances par rapport à cet environnement.