Pourquoi FiveM est la plateforme de référence pour le GTA RP

FiveM GTA RP fonctionne grâce à un client modifié qui relance ta copie de GTA V hors des services Rockstar, pour la connecter à un runtime maison : FXServer. Tout le reste (métiers, police, inventaire, téléphone) n'est que du code Lua chargé par ce runtime. Comprendre cette pile explique pourquoi les villes RP se ressemblent techniquement et divergent totalement dans le gameplay.

FiveM GTA RP : un client modifié greffé sur GTA V

Le client FiveM n'est pas un jeu autonome. Il détecte ton installation légitime de GTA V, injecte le framework Citizen dans le processus, coupe la couche multijoueur Rockstar Online Services et redirige le trafic réseau vers l'infrastructure Cfx.re. Le moteur graphique, la carte de Los Santos et les animations restent ceux du jeu de base.

Côté machine distante tourne FXServer, distribué sous forme d'artifacts régulièrement mis à jour. Ce binaire embarque un runtime de script (ScRT) capable d'exécuter du Lua, du JavaScript et du C#, un système de ressources et une couche de synchronisation réseau. Il ne charge aucune logique de gameplay par défaut : sans ressources, un joueur apparaît nu au milieu de la ville, sans argent ni inventaire.

La clé de licence s'obtient sur le keymaster Cfx.re et se colle dans server.cfg. Elle identifie l'instance auprès du réseau et conditionne son apparition dans la liste publique. Element Club, le programme de soutien de Cfx.re, sert uniquement à dépasser le palier de 32 slots et à activer OneSync Infinity.

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
sv_maxclients 64
sv_hostname "Los Santos Life RP"
sv_licenseKey "cfxk_xxxxxxxxxxxxxxxxxxxx"
sv_enforceGameBuild 2802
set onesync on

ensure oxmysql
ensure es_extended
ensure spawnmanager

Pour aller au bout de la logique et poser ta ville sur une machine calibrée pour FXServer, la page hébergement FiveM détaille la configuration matérielle et le NexusPanel associé.

Le framework, colonne vertébrale d'une ville roleplay

Un framework est un ensemble de ressources qui fournit les briques communes : identité du personnage, portefeuille, banque, inventaire, métiers, permissions et sauvegarde en base de données. Toutes les autres ressources s'y branchent via des exports ou des événements. Changer de framework en cours de route revient à réécrire la moitié des scripts installés.

ESX ou QBCore : ce qui change concrètement

Critère	ESX (es_extended)	QBCore (qb-core)
Accès à l'objet joueur	ESX.GetPlayerFromId(source)	QBCore.Functions.GetPlayer(source)
Identité	Un personnage par licence par défaut	Multicharacter intégré
Inventaire	Souvent délégué à ox_inventory	qb-inventory fourni d'origine
Base de données	MySQL via oxmysql	MySQL via oxmysql
Écosystème	Très large, historique	Plus récent, orienté RP structuré

D'autres bases existent, comme Qbox ou ox_core, qui poussent davantage de logique côté serveur pour limiter la triche. Le choix se fait surtout sur le stock de ressources que tu comptes réutiliser : un script écrit pour ESX ne se contente jamais d'un copier-coller vers QBCore, il faut adapter les événements, les callbacks et les items.

Dans tous les cas, une base MariaDB ou MySQL accompagne le framework. Les tables users, owned_vehicles ou players contiennent la totalité de la progression des joueurs. Une base corrompue sans sauvegarde, c'est la ville entière remise à zéro.

Les ressources Lua : la brique élémentaire du gameplay

Chaque fonctionnalité vit dans un dossier de resources/ contenant un manifeste. Le fichier fxmanifest.lua déclare la version du runtime, le jeu ciblé, les scripts client, les scripts serveur et les fichiers d'interface. FXServer ne charge que ce qui est déclaré, ce qui rend le débogage plus lisible qu'un dossier de mods classique.

fx_version 'cerulean'
game 'gta5'
author 'staff'
description 'Metier livreur'
version '1.0.0'

shared_script '@ox_lib/init.lua'
client_scripts { 'client/main.lua' }
server_scripts { '@oxmysql/lib/MySQL.lua', 'server/main.lua' }
ui_page 'html/index.html'
files { 'html/index.html', 'html/app.js' }

Client, serveur et la frontière de confiance

Le script client tourne dans le jeu du joueur : il gère les touches, les blips, les animations, les menus NUI en HTML. Le script serveur tourne sur la machine distante et détient la vérité : argent, items, permissions. Toute transaction validée côté client uniquement est une porte ouverte aux cheats, puisque le joueur contrôle son propre processus.

-- client/main.lua
RegisterNetEvent('livreur:paye', function(montant)
    TriggerEvent('esx:showNotification', ('Paiement : %s $'):format(montant))
end)

-- server/main.lua
RegisterNetEvent('livreur:finLivraison', function()
    local xPlayer = ESX.GetPlayerFromId(source)
    if not xPlayer then return end
    xPlayer.addMoney(250)
    TriggerClientEvent('livreur:paye', source, 250)
end)

Streaming des assets et poids du téléchargement

Les véhicules add-on, les MLO d'intérieurs, les vêtements et les sons passent par un dossier stream/. FXServer envoie ces fichiers au joueur à la connexion, dans son cache local. Une ville qui empile les packs véhicules impose plusieurs gigaoctets de téléchargement initial, et fait grimper la consommation mémoire du jeu côté client.

La commande resmon 1 dans la console F8 affiche le temps CPU consommé par chaque ressource, en millisecondes. Au-delà de 1 ms sur une ressource en veille, il y a une boucle mal écrite, typiquement un Citizen.Wait(0) qui tourne en permanence pour rien.

OneSync et la synchronisation des joueurs

Le multijoueur d'origine de GTA V repose sur un modèle peer to peer plafonné à 32 participants, où chaque client possède une part des entités. OneSync casse ce modèle : la machine distante devient autoritaire sur les entités, gère le scoping et décide quels joueurs et quels véhicules sont envoyés à qui. C'est la condition pour dépasser la trentaine de connectés.

Mode	Portée	Usage typique
OneSync désactivé	32 participants, modèle historique	Serveurs deathmatch ou tests locaux
OneSync Legacy	Jusqu'à 64 connectés	Petite ville RP, staff réduit
OneSync Infinity	Jusqu'à 2048 connectés, culling avancé	Grosses villes RP publiques

Culling, entity ownership et state bags

Le culling limite la quantité d'informations envoyée à chaque client : un joueur à Paleto Bay n'a pas besoin de recevoir les 400 véhicules garés en centre-ville. Ce filtrage géographique se règle avec onesync_distanceCullVehicles et conditionne directement la bande passante consommée par connecté.

set onesync on
set onesync_population false
set onesync_distanceCullVehicles true
set onesync_forceMigration true
setr onesync_enableInfinity 1

Les state bags permettent de partager un état d'entité entre client et serveur sans spammer d'événements réseau : moteur allumé, gyrophare actif, coffre verrouillé. Bien utilisés, ils réduisent nettement le trafic. Mal utilisés, en écriture par frame, ils saturent la file de synchronisation et provoquent les téléportations en arrière que les joueurs appellent rubber banding.

La documentation officielle de Cfx.re détaille chaque convar de synchronisation et leurs effets mesurables : Source.

Ce que cette architecture exige de la machine

FXServer répartit mal la charge sur plusieurs cœurs : le thread principal exécute la boucle de tick et la majorité des ressources. La fréquence par cœur pèse donc davantage que le nombre de cœurs. Un Ryzen 9 7950X3D, avec son cache empilé et ses fréquences élevées, absorbe bien mieux une ville chargée qu'un processeur mutualisé à faible fréquence.

La base de données est le second goulot d'étranglement. Chaque sauvegarde de position, chaque transaction bancaire, chaque dépôt d'item déclenche une requête. Un stockage SSD NVMe et de la RAM DDR5 ECC évitent que les requêtes s'empilent aux heures de pointe, quand cent joueurs sauvegardent en même temps.

Réseau, latence et protection

Le trafic transite en UDP sur le port 30120 par défaut, avec un flux constant de paquets de synchronisation. Un lien 1 Gbit/s couvre largement une ville RP standard. Sur FiveM et RedM, l'option Anti-DDoS Premium ajoute un proxy qui masque l'IP d'origine et monte la capacité à 10 Gbit/s, l'anti-DDoS restant actif par défaut sans surcoût.

# Vérifier l'écoute du port de jeu
ss -lunp | grep 30120

# Suivre la console FXServer en direct
tail -f /home/container/logs/latest.log

La même pile technique alimente le western roleplay : un Serveur RedM utilise FXServer, les ressources Lua et OneSync, avec des natives et des frameworks propres à Red Dead Redemption 2.

Pourquoi cette pile structure les communautés roleplay

Parce que le code de gameplay appartient entièrement à l'équipe qui l'installe, deux villes basées sur le même framework proposent des expériences opposées. L'une impose des papiers d'identité, une procédure judiciaire et des délais de réanimation réalistes, l'autre laisse braquer une banque toutes les dix minutes. La technique fixe le cadre, la direction RP fixe les règles.

Le contrôle des accès passe par le système ACE, natif à FXServer. Il attribue des permissions à des principals identifiés par licence Rockstar, Steam ou Discord, sans dépendre d'un plugin externe.

add_ace group.admin command allow
add_ace group.moderator command.kick allow
add_principal identifier.license:0a1b2c3d4e5f group.admin
add_principal identifier.discord:123456789012345678 group.moderator

La whitelist, souvent gérée par un bot Discord relié à la base de données, sert de filtre d'entrée et fait basculer la communauté d'un serveur ouvert vers un projet narratif suivi. txAdmin complète l'ensemble avec le redémarrage planifié, les logs d'actions et le suivi des ressources en direct.

Reste la discipline d'exploitation : sauvegardes automatiques de la base et du dossier resources/, mots de passe RCON robustes, mises à jour des artifacts en dehors des heures de pointe. D'autres retours d'expérience sur l'administration FiveM sont publiés sur le Blog Nexus Games.

Conclusion

Fixe ton framework avant d'écrire la première ligne de Lua : migrer d'ESX vers QBCore avec cinquante scripts installés coûte plus de temps que de tout recommencer. Active OneSync dès le départ, même à quinze connectés, pour éviter de refaire toute la logique d'entités plus tard. Et surveille resmon chaque semaine : une seule ressource mal codée plombe le tick de la ville entière.

FAQ

Faut-il posséder GTA V sur PC pour rejoindre une ville FiveM ?

Oui. Le client FiveM vérifie la présence d'une copie légitime de Grand Theft Auto V sur PC, achetée sur Steam, Rockstar Games Launcher ou Epic Games Store, et refuse de démarrer sans elle. Les versions console ne sont pas compatibles, la plateforme n'existant que sous Windows. Aucune copie modifiée ou piratée n'est acceptée par le système d'authentification Cfx.re.

Comment les véhicules add-on et les MLO arrivent-ils chez le joueur ?

Ils sont placés dans un dossier stream/ à l'intérieur d'une ressource, puis envoyés automatiquement au client lors de la connexion et stockés dans son cache local. Le joueur n'installe rien à la main. Plus le volume streamé grossit, plus le premier chargement s'allonge et plus la mémoire vidéo consommée en jeu augmente, jusqu'aux crashs de textures sur les machines modestes.

Quelle différence technique entre FiveM et RedM ?

Les deux reposent sur le même runtime FXServer, le même système de ressources Lua et la même couche OneSync. RedM cible Red Dead Redemption 2 au lieu de GTA V, donc les natives, les modèles de personnages, les véhicules et les frameworks diffèrent totalement. Un script écrit pour ESX ou QBCore ne fonctionne pas tel quel sur RedM, même si la logique de développement reste identique.