Débuter le mapping FiveM : MLO, YouTool et intégration à QBCore

Le mapping est devenu l'un des piliers d'un serveur FiveM RP qui se démarque : un intérieur sur mesure (un MLO) transforme un simple bâtiment du jeu de base en lieu unique pour votre communauté. Mais entre créer un MLO et le faire tourner correctement sur un serveur en production, il y a une étape que la plupart des tutoriels de création passent sous silence : l'intégration, l'optimisation et la sécurité côté hébergement. C'est cette partie que couvre ce guide.

Qu'est-ce qu'un MLO, et pourquoi ça pèse sur un serveur

Un MLO (Map/Milo, terme hérité du modding GTA V) est un intérieur personnalisé ajouté au jeu : un appartement, un commerce, un QG de gang, entièrement modélisé et placé par-dessus la carte de base. Contrairement à un script qui ne consomme que du CPU côté serveur, un MLO ajoute des fichiers de streaming (les cartes d'objets et de collisions du jeu) que chaque client doit télécharger et charger en mémoire à l'approche du lieu. Un serveur qui accumule des dizaines de MLO volumineux sans y prêter attention finit par imposer des temps de chargement longs et une consommation mémoire élevée à tous les joueurs, bien avant que le CPU serveur ne devienne le facteur limitant.

Les outils du mapping FiveM : panorama sans jugement de valeur

Trois familles d'outils cohabitent dans l'écosystème :

• CodeWalker : l'éditeur de carte gratuit et open source de référence, utilisé pour visualiser, ajuster et exporter les fichiers de streaming (ymap, ytyp) qui composent un MLO. C'est l'outil que la majorité des créateurs utilisent pour la partie technique, quelle que soit la façon dont ils ont modélisé les objets.
• Blender, associé à des plugins communautaires d'export vers le format du moteur du jeu, pour créer ou adapter des modèles 3D avant de les intégrer avec CodeWalker.
• YouTool, un outil commercial pensé pour simplifier le placement d'objets et la génération des fichiers de streaming sans passer par l'enchaînement complet Blender + CodeWalker, plus accessible aux créateurs qui débutent.

Aucun de ces outils ne remplace les autres entièrement : beaucoup de créateurs combinent Blender pour la modélisation, YouTool pour le placement rapide, et CodeWalker pour la vérification finale avant export. Le choix dépend surtout du niveau de contrôle recherché et du temps qu'on veut consacrer à l'apprentissage de chacun.

Intégrer un MLO comme ressource FiveM

Une fois les fichiers de streaming exportés, un MLO s'intègre à votre serveur comme n'importe quelle autre ressource :

1. Structure du dossier : les fichiers ymap, ytyp et les modèles associés vivent dans un dossier de ressource dédié, avec son propre fxmanifest.lua qui déclare les fichiers en data_file pour que le moteur les charge au démarrage.
2. Activation : la ressource s'ajoute à server.cfg via ensure nom-du-mlo, comme un script classique.
3. Interconnexion avec le framework : sur QBCore comme sur ESX, un MLO seul n'est qu'un décor. Le rendre fonctionnel (jobs associés à un lieu, zones interactives, boutiques) demande un script de liaison séparé, souvent fourni avec les MLO vendus dans le commerce ou à écrire soi-même pour un import personnel.
4. Test en environnement isolé : chargez le MLO sur un serveur de développement avant la production, avec un seul client connecté, pour repérer les problèmes de collision ou de textures manquantes sans que la communauté ne les découvre en premier.

Ce qui compte vraiment pour les performances

Le poids d'un MLO sur l'expérience de jeu se joue à trois niveaux, dans cet ordre d'impact :

• La taille et la complexité des modèles : un intérieur avec des milliers de props uniques et des textures haute résolution non compressées se charge nettement plus lentement qu'un équivalent optimisé, à qualité visuelle comparable pour le joueur.
• Le nombre de MLO actifs simultanément : chaque intérieur supplémentaire ajoute son propre lot de fichiers à streamer. Un serveur qui installe MLO sur MLO sans jamais retirer ceux qui ne servent plus accumule une dette de performance invisible jusqu'au jour où elle devient un problème de lag généralisé.
• La bande passante et les ressources serveur disponibles pour distribuer ces fichiers aux joueurs qui se connectent : un serveur bien dimensionné absorbe ce trafic de streaming sans ralentir la connexion des autres joueurs déjà en jeu.

Ces mêmes principes rejoignent ceux détaillés dans notre guide sur les performances serveur FiveM : la charge d'un MLO mal optimisé se comporte comme celle d'un script mal écrit, elle finit par se voir au même endroit, dans les temps de chargement et la fluidité ressentie par les joueurs.

D'où viennent vos MLO : un vrai sujet de sécurité

Privilégiez les créateurs identifiables avec une réputation établie (boutiques Tebex reconnues, forum officiel Cfx.re), et méfiez-vous par principe de toute archive « MLO gratuit » qui seule ne pourrait normalement pas être aussi accessible ailleurs.

Checklist avant de mettre un MLO en production

• MLO testé sur un serveur de développement, seul, avant l'ouverture au public.
• Collisions et textures vérifiées : pas de trous, pas de props flottants.
• Nombre total de MLO actifs sur le serveur revu régulièrement, les intérieurs inutilisés retirés plutôt qu'accumulés.
• Provenance vérifiée : créateur identifiable, pas de fichier « leak » d'origine inconnue.
• Script de liaison au framework (QBCore ou ESX) testé indépendamment du MLO lui-même.

Si vous démarrez tout juste votre serveur, notre guide de mise en place d'un serveur FiveM pose les bases avant d'ajouter du contenu personnalisé, et notre comparatif ESX Legacy vs QBCore aide à choisir le framework sur lequel greffer vos futurs MLO. Toutes nos offres d'hébergement FiveM sont dimensionnées pour encaisser le streaming de contenu personnalisé sans que ce soit vos joueurs qui en subissent le poids.