Installer et configurer un HUD sur un serveur FiveM : guide ESX et QBCore

Sur un serveur FiveM de roleplay, le HUD (heads-up display, l'affichage tête haute) est la première chose que voit un joueur après l'écran de chargement : barres de santé, d'armure, de faim et de soif, minimap, compteur de vitesse et jauge de carburant dès qu'il monte dans un véhicule. C'est aussi l'une des rares ressources qui tourne en permanence sur chaque client, à chaque frame ou presque, donc l'une des premières à examiner quand les joueurs se plaignent de leurs FPS. Ce guide s'adresse à la personne qui administre le serveur, chez un hébergeur ou sur une machine qu'elle gère elle-même : choix du HUD selon le framework (esx_hud pour ESX Legacy, qb-hud pour QBCore, et ce qu'il en est du fameux « ox_hud »), installation côté serveur, ordre de démarrage dans server.cfg, configuration des barres affichées, puis mesure et optimisation de la charge client. Si votre serveur n'est pas encore en ligne, commencez par notre guide de mise en place d'un serveur FiveM.

Un HUD FiveM, c'est quoi et d'où viennent ses données

Techniquement, un HUD est une ressource FiveM comme une autre : un dossier dans resources avec un fxmanifest.lua, un script client en Lua et une page NUI (HTML, CSS, JavaScript) que le navigateur Chromium intégré au client FiveM affiche par-dessus le jeu. Le script Lua collecte les valeurs, la page les dessine. Les valeurs viennent de deux endroits. Les natives du jeu, d'abord : GetEntityHealth et GetEntityMaxHealth pour la santé, GetPedArmour pour l'armure, GetEntitySpeed pour la vitesse, GetVehicleEngineHealth pour l'état du moteur, GetPlayerUnderwaterTimeRemaining pour l'oxygène, GetPlayerSprintStaminaRemaining pour l'endurance. Le framework, ensuite, pour tout ce que GTA ne connaît pas : la faim, la soif, le stress, l'argent liquide et le compte en banque, le métier. Ces statuts sont calculés côté serveur, stockés en base de données via oxmysql et poussés au client par des événements. Un HUD ne « crée » donc ni la faim ni la soif : il affiche ce que esx_status ou qb-core lui envoient. Enfin, le HUD d'origine de GTA V reste présent sous le vôtre : la native DisplayRadar montre ou masque la minimap, et HideHudComponentThisFrame cache un à un les éléments natifs (argent, nom de rue, icône d'arme).

Choisir son HUD : esx_hud, qb-hud, et la question d'ox_hud

Le choix se fait d'abord par le framework, parce qu'un HUD écoute les événements d'un framework précis. esx_hud est, selon son propre manifeste, « the default HUD resource for ESX-Legacy » : version 1.10.2, écrite pour ESX Legacy 1.16.2 (champ legacyversion), publiée sous licence GPL-3.0 dans le dépôt ESX-Legacy-Addons, dossier [esx_addons]/esx_hud. Il dépend d'esx_lib, d'es_extended, d'esx_status et d'oxmysql. Ses fonctions, telles que les liste la documentation ESX : compteur de vitesse avec kilométrage, clignotants avec son, affichage de l'arme et du nombre de munitions, compteur de joueurs en ligne, étiquette du métier, bascule km/h ou mph, sélecteur de couleurs et panneau de réglages en jeu, disposition différente pour les véhicules terrestres et aériens, ceinture de sécurité avec son (esx_cruisecontrol en option). Son interface est compilée avec Vite et Tailwind, et le dossier web/dist est livré dans le dépôt : vous n'avez rien à compiler.

qb-hud est le HUD officiel de QBCore, « heads-up display letting players track their hunger, thirst, stress, and more », version 2.2.0 dans le manifeste, dépôt qbcore-framework/qb-hud, dont le dernier commit au 6 novembre 2026 date du 25 août 2026 et renforce la validation côté serveur du retrait de stress. Le dépôt ne déclare aucune licence. Ses particularités : un menu de réglages en jeu (touche I ou /menu) dont les choix sont stockés dans le client du joueur, un système de stress complet (tir, vitesse excessive, métiers exemptés, flou et tremblements à l'écran), un mode cinématique avec bandes noires, une minimap carrée ou ronde, une boussole avec nom de rue, un indicateur de harnais, de nitro et de régulateur de vitesse. Il a besoin d'interact-sound pour ses sons de menu, d'une ressource de carburant qui expose l'export GetFuel de LegacyFuel (qb-fuel, livré avec la recette, déclare provide 'LegacyFuel') et de pma-voice pour l'état de la radio.

Et ox_hud ? Il n'existe pas, en tout cas pas chez Overextended. Le catalogue de l'organisation (ox_lib, ox_inventory, ox_core, ox_target, ox_fuel, oxmysql, ox_doorlock, ox_mdt, ox_banking, ox_police, cfxlua-require) ne contient aucun HUD, et l'adresse github.com/overextended/ox_hud renvoie une erreur 404. Les scripts vendus ou partagés sous ce nom sont des projets tiers, en général conçus pour ox_core ou pour les serveurs Qbox, qui s'appuient sur ox_lib pour leurs notifications et leurs callbacks. Avant d'en installer un, lisez son manifeste : la ligne dependencies vous dit à quel framework il s'adresse réellement, et notre guide scripts FiveM, où les trouver et lesquels éviter liste les vérifications à faire avant d'acheter.

Prérequis côté serveur

• Un framework installé et fonctionnel. Pour ESX Legacy, voyez notre guide installer ESX Legacy sur FiveM ; pour choisir entre les deux, notre comparatif ESX Legacy ou QBCore.
• Une base de données MySQL ou MariaDB reliée par oxmysql : esx_hud charge @oxmysql/lib/MySQL.lua côté serveur, esx_status enregistre les statuts toutes les 30 secondes et qb-core sauvegarde les métadonnées du joueur. Notre guide pour lier une base MySQL à un serveur FiveM couvre cette étape.
• Sur ESX : esx_status démarré (dépendance déclarée d'esx_hud), et esx_basicneeds pour que la nourriture et les boissons remontent la faim et la soif. Sur QBCore : qb-core, interact-sound, qb-fuel (ou toute ressource qui fournit l'export LegacyFuel) et pma-voice, tous présents dans la recette officielle. Pour la partie vocale, voyez installer pma-voice.
• Un accès aux fichiers du serveur et à la console txAdmin. Sur nos offres serveur FiveM, txAdmin est préinstallé, le répertoire resources est accessible depuis le gestionnaire de fichiers du panel ou en SFTP, et la protection anti-DDoS est incluse. Sur un VPS Linux que vous gérez vous-même, un shell SSH et unzip suffisent.

Installer esx_hud sur ESX Legacy

Si votre serveur a été déployé avec la recette txAdmin officielle d'ESX, esx_hud est déjà là : la recette télécharge le dépôt ESX-Legacy-Addons, déplace son dossier [esx_addons] dans resources, et le server.cfg généré se termine par ensure [esx_addons], qui démarre toutes les ressources de la catégorie, esx_hud compris. Vérifiez dans l'onglet Resources de txAdmin que esx_hud, esx_status et esx_basicneeds sont à l'état started. Sur un serveur monté à la main, téléchargez l'archive du dépôt ESX-Legacy-Addons (bouton Code, Download ZIP, ou curl en SSH), puis copiez les trois dossiers dans resources. Le README d'esx_hud parle d'un dossier [addons] : le nom de la catégorie n'a pas d'importance, FXServer parcourt les dossiers entre crochets ; ce qui compte, c'est que le dossier de la ressource s'appelle exactement esx_hud, car les autres scripts et les exports y font référence par ce nom.

# en SSH, sur un serveur Linux, depuis le compte qui lance FXServer
cd ~/FXServer/server-data/resources
curl -L -o /tmp/addons.zip https://github.com/esx-framework/ESX-Legacy-Addons/archive/refs/heads/main.zip
unzip -q /tmp/addons.zip -d /tmp/addons
mkdir -p '[esx_addons]'
cp -r '/tmp/addons/ESX-Legacy-Addons-main/[esx_addons]/esx_status'     '[esx_addons]/'
cp -r '/tmp/addons/ESX-Legacy-Addons-main/[esx_addons]/esx_basicneeds' '[esx_addons]/'
cp -r '/tmp/addons/ESX-Legacy-Addons-main/[esx_addons]/esx_hud'        '[esx_addons]/'
ls '[esx_addons]/esx_hud/web/dist'      # index.html et assets : l'interface est déjà compilée

Le README mentionne npm install puis npm run build dans le dossier web. Cette étape ne sert que si vous modifiez les sources de l'interface dans web/src : le dépôt livre web/dist déjà construit, et le manifeste pointe dessus (ui_page "web/dist/index.html"). Aucun Node.js n'est donc nécessaire sur le serveur. Côté server.cfg, l'ordre de démarrage suit les dépendances du manifeste : oxmysql, esx_lib, es_extended, puis esx_status, esx_basicneeds et esx_hud. La langue de l'interface vient de la convar esx:locale, lue par Config.Locale dans la config partagée du HUD comme dans celle du cœur ; la recette la laisse en commentaire, à vous de la décommenter.

# server.cfg : convar de langue (répliquée au client, d'où setr)
setr esx:locale "fr"

# ordre de démarrage
ensure oxmysql
ensure esx_lib
ensure es_extended
ensure esx_status
ensure esx_basicneeds
ensure esx_hud           # ou ensure [esx_addons] si vous démarrez toute la catégorie

Deux réglages se font dans esx_status, pas dans le HUD. Le premier, Config.Display dans [esx_addons]/esx_status/config.lua, vaut false par défaut avec le commentaire « disable if you are using another HUD » : il contrôle les barres minimalistes propres à esx_status. Laissez-le à false avec esx_hud, sinon les joueurs verront deux jeux de barres. Le second est la vitesse à laquelle la faim et la soif baissent : les deux statuts sont déclarés dans Config.AuthoritativeStatuses, calculés côté serveur, avec une valeur de départ de 1 000 000 (le maximum, Config.StatusMax) et une décroissance de 100 pour la faim et 75 pour la soif à chaque tick de Config.TickTime, soit 1 000 ms. Au rythme par défaut, un joueur passe donc de 100 % à 0 % de faim en 10 000 secondes, un peu moins de trois heures de jeu, et en 13 333 secondes pour la soif. Un pain d'esx_basicneeds rend 200 000 points (20 %), une bouteille d'eau 100 000 (10 %). Les statuts sont écrits en base toutes les 30 secondes (Config.UpdateInterval), par lots de 30 joueurs (Config.SyncSlices), pour lisser la charge serveur.

-- [esx_addons]/esx_status/config.lua (extrait, valeurs par défaut)
Config.StatusMax = 1000000
Config.TickTime = 1000
Config.UpdateInterval = 30000
Config.SyncSlices = 30
Config.Display = false     -- Enable the esx_status bars (disable if you are using another HUD)

Config.AuthoritativeStatuses = {
    hunger = { default = 1000000, decay = 100 },
    thirst = { default = 1000000, decay = 75 },
}

Une fois le serveur relancé, connectez-vous et testez les commandes du HUD : /hud ou /togglehud masque et réaffiche l'interface, /hudsettings ouvre le panneau de réglages avec le sélecteur de couleurs. Dans un véhicule, les flèches gauche et droite actionnent les clignotants, la flèche haut les feux de détresse et la touche N coupe ou démarre le moteur, à condition que Config.Disable.VehicleHandlers et Config.Disable.Vehicle soient restés à false. Un script tiers peut masquer le HUD pendant une cinématique ou un menu plein écran par l'export HudToggle ou l'événement esx_hud:HudToggle. Pour la suite de l'administration de la console, voyez notre guide configurer txAdmin.

Installer qb-hud sur QBCore

Même logique côté QBCore : la recette txAdmin officielle dépose qb-hud dans resources/[qb]/qb-hud, avec interact-sound et pma-voice, et le server.cfg généré enchaîne ensure qb-core, ensure [qb], ensure [standalone] et ensure [voice]. Le carburant vient de qb-fuel, dont le manifeste déclare provide 'LegacyFuel' : c'est ce qui permet à qb-hud d'appeler exports['LegacyFuel']:GetFuel(vehicle) sans que LegacyFuel soit installé. Pour une installation manuelle, le dépôt n'a pas de release : téléchargez l'archive de la branche main, et renommez impérativement le dossier extrait, qb-hud-main, en qb-hud. Le manifeste charge @qb-core/shared/locale.lua : le dossier du cœur doit lui aussi s'appeler exactement qb-core, faute de quoi la console affiche attempt to index a nil value (global 'Lang'), l'erreur la plus citée du README, que l'équipe QBCore conseille de corriger en réinstallant depuis la recette.

# en SSH, sur un serveur Linux
cd ~/FXServer/server-data/resources
curl -L -o /tmp/qb-hud.zip https://github.com/qbcore-framework/qb-hud/archive/refs/heads/main.zip
unzip -q /tmp/qb-hud.zip -d /tmp
mv /tmp/qb-hud-main '[qb]/qb-hud'
ls '[qb]/qb-hud'                 # client.lua config.lua fxmanifest.lua html locales server.lua stream

# server.cfg : langue de qb-core et du HUD, puis ordre de démarrage
setr qb_locale "fr"

ensure qb-core
ensure interact-sound     # sons d'ouverture et de fermeture du menu
ensure qb-fuel            # fournit l'export LegacyFuel GetFuel
ensure pma-voice          # état de la radio dans le HUD
ensure qb-hud

La configuration vit dans config.lua, chargé comme script partagé. Config.OpenMenu = 'I' fixe la touche du menu (modifiable ensuite par chaque joueur dans les paramètres de touches de FiveM, puisqu'elle passe par RegisterKeyMapping). Config.UseMPH bascule le compteur en miles par heure, avec une note dans le fichier : le texte de l'unité dans la feuille de style doit être changé à la main. Le système de stress se règle finement : Config.DisableStress = false l'active pour tout le monde, Config.StressChance = 0.1 donne 10 % de chances de gagner du stress à chaque tir, Config.MinimumStress = 50 est le niveau à partir duquel l'écran tremble, Config.MinimumSpeedUnbuckled = 50 et Config.MinimumSpeed = 100 sont les vitesses au-delà desquelles le stress monte, sans puis avec ceinture. Les listes blanches exemptent des armes (Config.WhitelistedWeaponStress, armes de mêlée et objets lancés par défaut), des véhicules, des classes de véhicules (Config.VehClassStress : les compactes jusqu'aux fourgons stressent, les vélos, bateaux, hélicoptères, avions, véhicules d'urgence et militaires non) et des métiers : Config.WhitelistedJobs = { 'leo', 'ambulance' } par défaut, police et ambulanciers ne stressent pas. Config.Intensity et Config.EffectInterval dosent le flou et la fréquence des effets par paliers de 50 à 100.

-- config.lua de qb-hud : exemple de serveur RP qui garde le stress mais le rend plus doux
Config.OpenMenu = 'I'
Config.UseMPH = false
Config.DisableStress = false
Config.StressChance = 0.05          -- 5 % par tir au lieu de 10 %
Config.MinimumStress = 60           -- effets visuels à partir de 60 au lieu de 50
Config.MinimumSpeedUnbuckled = 60
Config.MinimumSpeed = 120
Config.WhitelistedJobs = { 'leo', 'ambulance', 'mechanic' }

Les valeurs de faim et de soif, elles, se règlent dans qb-core/config.lua. Un joueur commence à 100 de faim, 100 de soif et 0 de stress (QBCore.Config.Player.PlayerDefaults.metadata). Toutes les QBCore.Config.UpdateInterval minutes, 5 par défaut, le client envoie QBCore:UpdatePlayer ; le serveur retire alors HungerRate (4.2) et ThirstRate (3.8), refuse les appels reçus moins de dix secondes après le précédent, borne les valeurs à 0, sauvegarde le joueur et déclenche hud:client:UpdateNeeds vers qb-hud. Au rythme par défaut, la faim tombe de 100 à 0 en une vingtaine de mises à jour, soit environ deux heures. Sous zéro, une boucle client de qb-core retire 5 à 10 points de vie toutes les QBCore.Config.StatusInterval millisecondes (5 000). Le stress ne baisse pas tout seul : ce sont d'autres scripts (consommables, activités) qui appellent hud:server:RelieveStress, et depuis le commit d'août 2026 le serveur valide que la valeur demandée est un entier entre 1 et 100.

En jeu, le joueur ouvre le menu avec I ou /menu : forme de la carte (carrée par défaut, ou ronde), boussole et nom de rue, affichage de chaque barre, alertes de carburant, sons, mode cinématique, et un réglage de performance qui espace la boucle principale. Ces choix sont enregistrés dans le client du joueur : le README précise qu'ils survivent même à la suppression de la ressource, et que seul le bouton Reset Settings du menu les efface. /resethud relance le HUD sans redémarrer la ressource ; /cash et /bank affichent les soldes ; /dev, réservé à la permission admin, active le mode développeur. Si les bordures de la minimap sont décalées, le README donne la cause habituelle : la zone de sécurité (safezone) de GTA n'est pas à sa valeur par défaut, à rétablir dans Paramètres, Affichage, Restaurer les valeurs par défaut.

Configurer les barres affichées et masquer le HUD natif

Sur esx_hud, tout passe par shared/config.lua. La table Config.Disable coupe un bloc entier : Status (toutes les barres de statut), Vehicle (le compteur), Weapon (arme et munitions), Position (rue et zone), Voice, Money, Info (logo, nom du serveur, joueurs en ligne). IndicatorSound est à true par défaut, donc le son des clignotants est coupé ; MinimapOnFoot à true masque la minimap hors véhicule ; StatusPercent affiche la valeur en pourcentage sur chaque barre ; CenterStatuses, à true, place les barres au-dessus de la minimap, à false en colonne à gauche. Config.Default fixe l'habillage du serveur : ServerLogo (URL d'une image, sinon le logo ESX), ServerName, ServerTagline, AccentColor, Kmh = true, et PassengerSpeedo = false pour que seuls les conducteurs voient le compteur. Config.Colors donne la couleur par défaut de chaque barre (healthBar, armorBar, foodBar, drinkBar, staminaBar, oxygenBar) et de chaque élément du compteur ; le joueur peut les changer pour lui-même via /hudsettings.

-- [esx_addons]/esx_hud/shared/config.lua : serveur sans arme affichée ni minimap à pied
Config.Disable = {
    Status = false,
    Vehicle = false,
    Weapon = true,              -- pas d'icône d'arme ni de compteur de munitions
    Position = false,
    Voice = false,
    Money = false,
    Info = false,
    IndicatorSound = false,     -- son des clignotants activé
    IndicatorSeatbeltSound = false,
    VehicleHandlers = false,
    MinimapOnFoot = true,       -- minimap uniquement en véhicule
    Needle = false,
    StatusPercent = true,
    CenterStatuses = true,
}

Config.Default = {
    ServerLogo = "https://votre-domaine.fr/img/logo.png",
    ServerName = "Mon serveur RP",
    ServerTagline = "Los Santos, en français",
    AccentColor = "#2f80ed",
    Kmh = true,
    PassengerSpeedo = false,
}

Sur qb-hud, les valeurs par défaut de chaque option du menu sont dans Config.Menu : boussole, barres dynamiques (santé, armure, faim, soif, stress, oxygène, moteur, nitro), alerte de carburant, sons, et, désactivés par défaut, le masquage de la carte, le mode cinématique et ses notifications. Ce sont des valeurs de départ : chaque joueur les modifie ensuite dans son menu, et ses choix priment. Si vous voulez imposer une barre ou en interdire une, la seule solution propre est d'éditer html/index.html et html/app.js, où l'interface est écrite en HTML et JavaScript.

Reste le HUD natif de GTA V, que votre HUD ne remplace pas automatiquement. Deux natives suffisent, à appeler depuis n'importe quel script client, dans un thread dédié. DisplayRadar(false) masque la minimap, et c'est ce qu'esx_hud et qb-hud font eux-mêmes selon leurs options. HideHudComponentThisFrame(id) cache un composant pour la frame en cours seulement : il doit donc être appelé à chaque frame, dans une boucle avec Wait(0), c'est l'un des rares cas où un Wait(0) est légitime. La documentation des natives liste 22 identifiants, dont les plus utiles pour un serveur RP : 1 étoiles de recherche, 2 icône d'arme, 3 argent, 4 argent en ligne, 6 nom du véhicule, 7 nom de la zone, 9 nom de la rue, 13 variation d'argent, 14 réticule, 16 stations de radio, 19 roue des armes et 20 ses statistiques. Un HUD qui affiche déjà l'argent, la rue et l'arme rend ces composants natifs redondants.

-- client.lua d'un petit script « hud_natif » : masque les composants redondants
local composants = { 1, 2, 3, 4, 6, 7, 9, 13, 16, 19, 20 }

CreateThread(function()
    while true do
        for i = 1, #composants do
            HideHudComponentThisFrame(composants[i])
        end
        Wait(0)   -- obligatoire : la native n'agit que pour la frame courante
    end
end)

-- en option, minimap agrandie ou désactivée selon le contexte
-- SetBigmapActive(true, false)   -- grande minimap, sans la carte complète
-- DisplayRadar(false)            -- plus de minimap du tout

Si vous débutez en scripting FiveM, notre tutoriel pour créer son premier script FiveM en Lua explique le manifeste et la structure d'un thread client comme celui-ci.

Performance : garder les FPS des joueurs

Un HUD ne coûte presque rien au serveur : esx_status synchronise les statuts toutes les 30 secondes par lots, qb-core reçoit une mise à jour par joueur toutes les cinq minutes. Le coût est côté client, et il a deux sources. La première, ce sont les boucles Lua. La documentation de Citizen.Wait est claire : Wait(0) met le thread en pause jusqu'au tick de jeu suivant, donc une boucle en Wait(0) s'exécute à chaque frame, 60 fois par seconde à 60 FPS, 144 fois à 144 FPS ; et tout ce qui doit tourner à chaque frame doit utiliser Wait(0), car Wait(5) ou Wait(10) font manquer des frames aux hautes fréquences d'image. La conclusion pour un HUD : seules les natives « ThisFrame » et le dessin des bandes noires justifient Wait(0) ; la santé n'a pas besoin d'être relue plus de quelques fois par seconde. La seconde source, ce sont les messages NUI : chaque SendNUIMessage sérialise une table en JSON, la passe au navigateur intégré, qui la lit en JavaScript et met à jour le DOM. Envoyer le bloc complet du HUD à chaque frame est bien plus coûteux que la lecture des natives qui l'alimente. Les deux HUD officiels ont fait des choix différents sur ces deux points.

Pour mesurer plutôt que supposer, FiveM fournit trois outils, tous documentés sur docs.fivem.net. Le moniteur de ressources, resmon true dans la console F8 du client, affiche pour chaque ressource démarrée son temps CPU par frame en millisecondes et sa mémoire : c'est là que vous verrez si le HUD pèse plus que l'inventaire ou le téléphone. C'est une commande développeur : sur FiveM Legacy, le client doit être lancé avec l'argument +set moo 31337 ou sur un canal de mise à jour non stable (Beta, Latest) ; sur FiveM pour GTA V Enhanced, ce drapeau a disparu et c'est le serveur qui autorise le mode développeur avec sv_devMode true dans server.cfg. cl_drawperf true superpose FPS, ping, perte de paquets, charge CPU et GPU dans un coin de l'écran, cl_drawfps true le seul compteur d'images, et Enhanced ajoute cl_drawResTimeGraphs et cl_drawResTimeWarnings, des graphes de temps par ressource. Enfin le profileur enregistre frame par frame ce que chaque script a fait : profiler record 500 capture 500 frames, profiler status suit l'avancement, profiler saveJSON hud.json écrit le fichier et profiler view l'ouvre ; dans Chrome, l'onglet Performance des outils de développement charge ce JSON et montre, zoom après zoom, le temps passé dans chaque fichier et chaque ligne. Le même profileur existe côté serveur, dans la console txAdmin, pour chasser les à-coups serveur.

# console F8 du client (mode développeur requis)
resmon true            # temps CPU et mémoire par ressource, à comparer entre scripts
cl_drawperf true       # FPS, ping, CPU, GPU en surimpression
profiler record 500    # puis profiler status, profiler saveJSON hud.json, profiler view

# server.cfg, FiveM Enhanced uniquement : autorise les commandes développeur côté client
set sv_devMode true

Quelques règles tirées de ce qui précède. Ne faites jamais tourner deux HUD : sur ESX, Config.Display d'esx_status reste à false, et un HUD tiers ne s'installe qu'après avoir retiré esx_hud ou qb-hud de server.cfg. Désactivez les blocs inutiles : chaque Config.Disable à true sur esx_hud, c'est une boucle de moins, et Config.DisableStress = true sur qb-hud retire le thread de tir en Wait(0), les effets de flou et la boucle de vitesse. Sur qb-hud, l'option FPS du menu fait passer la boucle principale de 50 à 500 ms et la boussole de chaque frame à 50 ms ; dites-le à vos joueurs sur petite configuration. Évitez d'empiler des scripts qui dessinent du texte à chaque frame avec des natives (aide « Appuyez sur E », marqueurs, zones) : un prompt via ox_lib ou un menu NUI est affiché une fois, pas redessiné. Mesurez avant et après chaque changement avec resmon, HUD seul puis HUD avec les autres scripts, pour attribuer le coût à la bonne ressource. Pour aller plus loin côté client, notre guide pour augmenter ses FPS sur FiveM traite des réglages graphiques, et côté serveur, optimiser les performances d'un serveur FiveM couvre OneSync, les ressources lourdes et le dimensionnement.

Dépannage : les pannes de HUD les plus fréquentes

Pour tout ce qui touche au démarrage du serveur lui-même plutôt qu'au HUD, notre page solutions aux erreurs courantes sur FiveM complète ce tableau.

Lexique : HUD, NUI, native, statut, export

Conclusion

Installer un HUD sur un serveur FiveM tient en peu de gestes : choisir celui de son framework, esx_hud pour ESX Legacy et qb-hud pour QBCore, tous deux livrés par les recettes txAdmin officielles ; respecter l'ordre de démarrage dans server.cfg, framework, statuts, carburant, puis HUD ; régler la langue par convar, les blocs affichés dans le config.lua du HUD, et la vitesse de la faim et de la soif dans esx_status ou qb-core, pas dans le HUD. Le prétendu ox_hud n'existe pas chez Overextended : ce que vous trouverez sous ce nom est un script tiers, à juger sur son manifeste et ses boucles. Et parce qu'un HUD tourne sur chaque client en permanence, mesurez son coût avec resmon avant d'accuser le serveur, réservez Wait(0) aux natives qui l'exigent, et désactivez ce que votre serveur n'utilise pas. Le serveur, lui, doit suivre sur tout le reste : nos offres serveur FiveM vont de 4 à 64 Go de RAM DDR4, avec txAdmin et protection anti-DDoS inclus, hébergées en France, et si vous préférez gérer FXServer vous-même, notre guide FiveM sous Docker sur un VPS Linux couvre l'installation complète.