Qu'est-ce qu'un framework RedM et lequel choisir pour son serveur ?

Un framework RedM est la couche logicielle qui structure toute la logique roleplay d'un serveur RedM : gestion des joueurs, inventaire, économie, jobs et connexion à la base de données. Il évite de recoder chaque système depuis zéro. RedEM:RP, VORP et RSG Core sont les trois options dominantes, avec des choix d'architecture et de compatibilité de ressources qui orientent directement ton projet roleplay.

Qu'est-ce qu'un framework RedM et à quoi sert-il ?

Un framework RedM regroupe un ensemble de ressources Lua qui gèrent les fonctions communes à tout serveur roleplay : connexion du joueur, sauvegarde du personnage, système d'argent, inventaire partagé et interface utilisateur. Sans lui, chaque script devrait redéfinir sa propre logique, ce qui multiplie les conflits entre ressources tierces.

Techniquement, un framework s'appuie sur un fichier fxmanifest.lua qui déclare ses dépendances, des events partagés entre client et serveur, et des exports que les autres ressources appellent pour lire ou modifier les données d'un joueur. Le tout communique en permanence avec une base de données MySQL.

fx_version 'cerulean'
game 'rdr3'
rdr3_warning 'I acknowledge...'

server_scripts {
    '@oxmysql/lib/MySQL.lua',
    'server/main.lua'
}
client_scripts {
    'client/main.lua'
}

Si tu pars de zéro et cherches une base technique fiable pour installer l'un de ces frameworks, un hébergement RedM avec console live et accès FTP complet simplifie l'import des ressources et l'édition des fichiers de configuration.

Les fonctionnalités techniques d'un système roleplay complet

Au-delà de la structure de base, un framework roleplay prend en charge plusieurs blocs métier qui reviennent dans les trois solutions étudiées ici, avec des noms de ressources et des schémas différents.

Gestion des joueurs et des personnages

Chaque framework attribue un identifiant unique au joueur (license, steam ou discord) et permet de créer plusieurs personnages liés à ce compte. Les données de personnage (nom, apparence, position, argent) sont sérialisées et rechargées à chaque connexion depuis la table charinfo ou son équivalent.

Inventaire et objets

L'inventaire gère le poids, les métadonnées d'objet (durabilité, munitions restantes) et le partage entre coffres, chevaux et joueurs. C'est souvent la ressource la plus lourde à migrer d'un framework à l'autre, car la structure JSON des items diffère.

Jobs et économie

Les jobs définissent les grades, les salaires liés à une société et les permissions d'accès (armurerie, ranch, saloon). Le système économique s'appuie sur des comptes bancaires séparés du cash physique, avec des exports pour créditer ou débiter un montant.

Base de données et sauvegarde

Toutes ces données transitent par un connecteur MySQL, généralement oxmysql en requêtes asynchrones ou mysql-async selon l'âge du framework. Un script d'import schema.sql crée les tables au premier lancement, et des sauvegardes régulières de la base restent indispensables en complément des sauvegardes de fichiers.

RedEM:RP : le pionnier historique du roleplay RedM

RedEM:RP a été l'un des premiers frameworks structurés pour RedM, construit sur une logique proche des premiers frameworks FiveM. Son architecture reste relativement monolithique : les ressources principales dialoguent beaucoup entre elles via des events directs plutôt que par exports isolés.

Sa base de données utilise des tables spécifiques (users, characters) et un connecteur mysql-async plus ancien que les solutions actuelles. L'écosystème de ressources compatibles s'est réduit avec le temps, ce qui limite le choix de scripts tiers prêts à l'emploi.

ensure mysql-async
ensure redem_roleplay
ensure redem_inventory
ensure redem_hud

Consulter la documentation officielle Cfx.re reste utile pour comprendre les events natifs sur lesquels s'appuie ce type d'architecture, même si RedEM:RP ne dispose pas de documentation aussi fournie que ses concurrents.

VORP Core : une architecture modulaire et un écosystème actif

VORP Core découpe chaque fonction en ressource indépendante : vorp_core pour le cœur, vorp_character, vorp_inventory, vorp_jobs. Cette modularité facilite la maintenance, car une mise à jour de l'inventaire n'impose pas de toucher au reste du framework.

Les exports sont clairement nommés (Core.getUser, Character.getCharacter) et bien documentés dans la communauté, ce qui explique la quantité de scripts tiers déjà compatibles nativement. La base de données utilise des tables préfixées vorp_ avec un schéma plus récent que RedEM:RP.

ensure vorp_core
ensure vorp_character
ensure vorp_inventory
ensure vorp_jobs

Pour un serveur qui compte s'appuyer sur beaucoup de ressources communautaires prêtes à l'emploi, cette architecture modulaire réduit le temps d'intégration par rapport à un framework plus fermé.

RSG Core : l'héritage QBCore adapté à RedM

RSG Core reprend la logique et les conventions de nommage popularisées par QBCore sur FiveM, transposées à RedM. Les administrateurs déjà familiers avec un framework FiveM de ce type retrouvent une structure d'exports et un player object très similaires.

Cette proximité facilite la portabilité de certains scripts entre les deux jeux, à condition d'adapter les natives spécifiques à RedM. La base de données suit un schéma proche de qb-core, avec des tables comme players et gangs déjà connues des développeurs venus de FiveM.

ensure oxmysql
ensure rsg-core
ensure rsg-inventory
ensure rsg-fuel

L'écosystème RSG Core progresse rapidement en nombre de ressources maintenues, notamment grâce aux développeurs qui migrent leurs scripts QBCore existants vers RedM.

Compatibilité des ressources entre RedEM:RP, VORP et RSG Core

Les trois frameworks ne partagent ni exports, ni structure de base de données, ni format d'inventaire. Une ressource écrite pour VORP appelle Core.getUser tandis qu'une ressource RSG Core appelle QBCore.Functions.GetPlayer ou son équivalent RedM. Installer un script sans vérifier sa dépendance déclarée provoque des erreurs silencieuses en console.

• Vérifie toujours le fxmanifest.lua de la ressource tierce pour identifier le framework cible réel.
• Compare le schéma de base de données attendu (colonnes charinfo, metadata, items) avant d'importer un script.
• Certaines ressources dites "bridge" traduisent les exports d'un framework vers un autre, mais elles ajoutent une couche de maintenance supplémentaire.
• Migrer un serveur d'un framework à l'autre implique de réécrire l'inventaire et les jobs, rarement une simple copie de fichiers.

En pratique, mieux vaut choisir un framework dès le lancement du projet et s'y tenir, plutôt que de migrer une communauté active avec des personnages et un inventaire déjà en place.

Comment choisir le framework adapté à ton projet roleplay

Le choix dépend surtout de la taille de la communauté, du niveau technique de l'équipe d'administration et de la disponibilité de scripts déjà compatibles avec le framework retenu.

Critère	RedEM:RP	VORP	RSG Core
Architecture	Peu modulaire	Modulaire	Modulaire, inspirée QBCore
Écosystème de ressources	Restreint	Large	En forte croissance
Connecteur base de données	mysql-async	oxmysql	oxmysql
Portabilité depuis FiveM	Faible	Faible	Élevée

Un serveur mono-scripts avec une petite équipe technique gagnera du temps sur VORP grâce à sa documentation communautaire. Une équipe déjà à l'aise avec QBCore sur Serveur FiveM ira plus vite en démarrant sur RSG Core, du fait des conventions partagées entre les deux.

Pour éditer la configuration MySQL depuis un environnement Linux, la commande reste identique quel que soit le framework choisi.

set mysql_connection_string "mysql://user:password@localhost/database?charset=utf8mb4"

Sur un VPS Pterodactyl, cette variable se déclare directement dans l'onglet de configuration de l'instance, sans toucher au fichier server.cfg en édition manuelle.

Conclusion

Pour un serveur qui veut s'appuyer rapidement sur des scripts communautaires nombreux, VORP reste le choix le plus sûr aujourd'hui. Une équipe venue de FiveM avec des développeurs QBCore ira plus vite sur RSG Core. Évite en priorité de mélanger des ressources conçues pour des frameworks différents sans vérifier leurs exports et leur schéma de base de données.

FAQ

Peut-on faire tourner deux frameworks RedM en même temps sur la même instance ?

Techniquement possible, mais fortement déconseillé. Les deux frameworks créeraient des tables concurrentes en base de données et des conflits d'exports entre ressources, ce qui provoque des erreurs de sauvegarde de personnage et des doublons d'inventaire difficiles à diagnostiquer en production.

Un framework roleplay ralentit-il les performances d'un serveur RedM ?

Un framework bien optimisé, avec des requêtes MySQL asynchrones via oxmysql, a un impact limité sur les performances. La charge vient surtout de l'accumulation de scripts tiers mal codés qui multiplient les boucles côté client, plus que du framework de base lui-même.

Faut-il savoir coder en Lua pour administrer un framework RedM ?

Une connaissance de base en Lua aide à lire les logs d'erreur et à ajuster des paramètres simples dans les fichiers de configuration. Un niveau de développeur complet n'est pas indispensable pour l'administration courante, mais devient utile dès qu'on veut personnaliser un job ou un système d'inventaire.