FiveM HUD für Roleplay-Server: was es anzeigen sollte, Performance, Anpassung und sauberer Wechsel

Ein gutes FiveM HUD zeigt auf einem Roleplay-Server nur das, was ein Charakter in der Situation wirklich wissen muss: eigenen Zustand, Fahrzeugdaten beim Fahren, Sprech- und Funkstatus und bei Bedarf Geld und Job. Es bleibt lesbar, belastet den Client im Leerlauf kaum messbar und lässt sich vom Spieler anpassen. Alles, was Informationen über andere Spieler preisgibt oder dauerhaft den Bildschirm füllt, gehört nicht hinein.

Dieser Beitrag geht die Anzeigen einzeln durch, zeigt, wie du ein HUD mit resmon bewertest, worauf es bei ESX, QBCore und Qbox ankommt und welche Fehler beim Wechsel des HUDs regelmäßig passieren.

Was ein FiveM HUD auf einem Roleplay-Server anzeigen sollte

Die Leitfrage für jedes Element lautet: Würde der Charakter diese Information im echten Leben spüren oder sehen? Daraus ergeben sich fünf Gruppen, die fast jeder RP-Server braucht.

Status: Gesundheit, Rüstung, Hunger, Durst

Gesundheit und Rüstung sind Pflicht, weil Spieler sonst nicht einschätzen können, ob sie einen Konflikt weiterführen. Hunger und Durst sind nur sinnvoll, wenn euer Server sie auch nutzt, etwa über esx_status oder die Needs von QBCore. Ein bewährtes Muster: Statusbalken werden ausgeblendet, solange sie voll sind, und erscheinen erst, wenn ein Wert sinkt. Das reduziert visuelles Rauschen, ohne dass wichtige Informationen fehlen.

Fahrzeug: Tacho, Tank, Gurt

Fahrzeuganzeigen gehören nur ins Bild, wenn der Spieler in einem Fahrzeug sitzt. Geschwindigkeit, Tankfüllung und Gurtstatus reichen meist aus. Motorschaden oder Drehzahl sind optional und eher etwas für Server mit Mechaniker-Roleplay. Viele Server blenden außerdem die Minimap zu Fuß aus und zeigen sie nur im Fahrzeug, das stärkt die Orientierung im RP ohne Navi-Gefühl beim Laufen.

Geld und Job

Bargeld im HUD ist vertretbar, weil ein Charakter grob weiß, was er im Portemonnaie hat. Den Kontostand dauerhaft einzublenden ist dagegen Geschmackssache: Er verleitet dazu, Banktermine und Überweisungen zu überspringen. Ein Kompromiss ist eine Anzeige, die nur bei Änderung kurz eingeblendet wird. Den Job samt Rang zu zeigen hilft vor allem Fraktionsmitgliedern, die zwischen Dienst und Freizeit wechseln. Wer eigene Jobs entwickelt, sollte Job- und Ranglabels sauber pflegen, wie im Beitrag zum eigenen Job-Script mit serverseitiger Validierung beschrieben, denn das HUD zeigt genau diese Labels an.

Stimme und Funk

Die Sprechlautstärke (Flüstern, Normal, Rufen), ein Indikator, ob man gerade spricht, und die aktive Funkfrequenz sind im RP oft wichtiger als jede andere Anzeige. Fehlt das, beschweren sich Spieler, dass sie nicht gehört werden, obwohl sie nur im falschen Modus sind.

Was nicht ins HUD gehört

Die meisten Probleme entstehen durch zu viel Information. Folgende Elemente führen erfahrungsgemäß zu Metagaming oder Unruhe:

• Namen, IDs oder Jobs anderer Spieler über Köpfen oder in Listen, die ständig sichtbar sind
• Live-Anzahl der Polizisten oder Medics im Dienst, die Überfälle planbar macht
• Kill-Feeds und Trefferanzeigen aus dem PvP-Bereich
• Koordinaten, Straßennamen mit Postleitzahl und ähnliche Debug-Daten
• Dauerhaft eingeblendete Werbung, Discord-Links oder Server-Logos in großer Größe

Die eigene Server-ID ist ein Grenzfall: Für Meldungen an den Support ist sie nützlich, sie muss aber nicht permanent sichtbar sein. Ein Befehl oder eine Anzeige im Pausemenü reicht.

Ein Roleplay-HUD ist dann gut, wenn es im Normalfall fast verschwindet und nur dann auffällt, wenn eine Information wirklich gebraucht wird.

Lesbarkeit: woran ein HUD im Alltag scheitert

Ein HUD, das auf dem Bildschirm des Entwicklers gut aussieht, ist auf anderen Monitoren oft unbrauchbar. Prüfe vor dem Livegang mindestens diese Punkte:

• Auflösungen und Seitenverhältnisse: Teste 1920x1080, 2560x1440 und ein Ultrawide-Format. Elemente sollten relativ zur Safe Zone positioniert sein, nicht mit festen Pixelwerten.
• Kontrast: Helle Schrift ohne Schatten verschwindet bei Tag in der Wüste oder im Schnee-Event. Ein dezenter Hintergrund oder Textschatten löst das.
• Überlappungen: Minimap, Chat, Notify, Funk-Overlay und Inventar dürfen sich nicht gegenseitig verdecken.
• Farbcodierung: Rot und Grün allein reichen nicht, weil ein Teil der Spieler sie schlecht unterscheidet. Ergänze Symbole oder Füllstände.

Performance: ein HUD mit resmon richtig bewerten

Ein HUD läuft bei jedem Spieler dauerhaft, deshalb fällt hier jede unnötige Schleife stärker ins Gewicht als bei einem Script, das nur gelegentlich genutzt wird. Gemessen wird clientseitig: Öffne im Spiel die F8-Konsole und gib Folgendes ein:

resmon 1

Beobachte den Wert des HUDs in drei Situationen: zu Fuß im Leerlauf, im fahrenden Fahrzeug und beim Sprechen über Funk. Im Leerlauf sollte ein sauber gebautes HUD im Bereich weniger Hundertstel Millisekunden liegen. Springt der Wert im Fahrzeug deutlich nach oben, aktualisiert der Tacho vermutlich jeden Frame.

Die typische Ursache ist eine Schleife mit Wait(0), die in jedem Frame Daten an die NUI schickt. Besser ist ein festes Intervall und ein Vergleich mit dem letzten Stand:

local last = {}

CreateThread(function()
    while true do
        local ped = PlayerPedId()
        local data = {
            health = GetEntityHealth(ped) - 100,
            armor = GetPedArmour(ped),
            talking = NetworkIsPlayerTalking(PlayerId())
        }
        if data.health ~= last.health or data.armor ~= last.armor or data.talking ~= last.talking then
            SendNUIMessage({ action = 'status', data = data })
            last = data
        end
        Wait(250)
    end
end)

Für den Tacho kann das Intervall kürzer sein, für Hunger und Durst genügt es, auf die Events des Frameworks zu reagieren, statt sie zu pollen. Achte auch auf die NUI-Seite: CSS-Animationen, große Hintergrundbilder und Schriftarten, die bei jedem Update neu geladen werden, kosten Leistung, die resmon nur teilweise anzeigt. Ein Blick in die Bildrate mit und ohne HUD ist deshalb ein sinnvoller Zusatztest.

Anpassbarkeit durch Spieler

Spieler haben unterschiedliche Monitore, Gewohnheiten und Streaming-Layouts. Ein HUD sollte deshalb mindestens erlauben, Elemente ein- und auszublenden, die Größe zu ändern und einen Kinomodus für Screenshots oder Szenen zu aktivieren. Verschiebbare Elemente sind ein Plus, aber kein Muss.

Wichtig ist, wo die Einstellungen gespeichert werden. Für reine Darstellungsoptionen braucht es keine Datenbank. Der Resource-KVP-Speicher liegt beim Client und hält die Einstellungen auch nach einem Neustart:

RegisterNUICallback('saveSettings', function(data, cb)
    SetResourceKvp('hud_settings', json.encode(data))
    cb('ok')
end)

CreateThread(function()
    local saved = GetResourceKvpString('hud_settings')
    if saved then
        SendNUIMessage({ action = 'loadSettings', data = json.decode(saved) })
    end
end)

Beachte: KVP-Werte hängen am Ressourcennamen. Benennst du das HUD um, starten alle Spieler wieder mit den Standardwerten.

Kompatibilität mit ESX, QBCore und Qbox

Ein HUD selbst zeichnet nur Werte. Entscheidend ist, woher es Geld, Job und Status bezieht, denn diese Daten liefert das Framework. Behaupte daher nie pauschal, ein HUD laufe überall, sondern prüfe die Datenquellen. Ein einfacher Bridge-Ansatz trennt Framework-Logik von der Anzeige:

if GetResourceState('es_extended') == 'started' then
    RegisterNetEvent('esx:setAccountMoney', function(account)
        SendNUIMessage({ action = 'money', name = account.name, amount = account.money })
    end)
    RegisterNetEvent('esx:setJob', function(job)
        SendNUIMessage({ action = 'job', label = job.label, grade = job.grade_label })
    end)
elseif GetResourceState('qb-core') == 'started' then
    RegisterNetEvent('QBCore:Player:SetPlayerData', function(pd)
        SendNUIMessage({ action = 'money', cash = pd.money.cash, bank = pd.money.bank })
        SendNUIMessage({ action = 'job', label = pd.job.label, grade = pd.job.grade.name })
    end)
    RegisterNetEvent('hud:client:UpdateNeeds', function(hunger, thirst)
        SendNUIMessage({ action = 'needs', hunger = hunger, thirst = thirst })
    end)
end

Bei ESX kommen Hunger und Durst meist über esx_status:onTick. Qbox stellt über seine Kompatibilitätsschicht viele QBCore-Events bereit, trotzdem lohnt sich ein Test, ob jedes Event, auf das dein HUD hört, wirklich ausgelöst wird. Für den Sprechmodus liefert pma-voice das Event pma-voice:setTalkingMode. Nutzt dein Server ein anderes Voice-System, musst du genau diese Stelle anpassen.

Typische Fehler beim Wechsel des HUDs

Der Austausch eines HUDs wirkt harmlos, berührt aber viele andere Ressourcen. Diese Fehler tauchen besonders häufig auf:

• Das alte HUD wird nicht vollständig entfernt. Zwei HUDs gleichzeitig führen zu doppelten Anzeigen und zu sich überschreibenden Minimap-Einstellungen.
• Andere Scripts rufen Exports des alten HUDs auf, etwa für Notify oder Fortschrittsbalken. Fehlt die Ressource, erscheinen Fehler in der Konsole und Benachrichtigungen bleiben aus.
• Die Standardanzeigen von GTA (Waffenrad-Infos, Geldanzeige, Fahrzeugname) werden nicht mehr ausgeblendet, weil das alte HUD das übernommen hatte.
• Statuswerte stimmen nicht, weil das neue HUD andere Events erwartet als das bisherige Status-Script.
• Spieler verlieren ihre gespeicherten Layouts ohne Vorwarnung und fluten den Support.

Checkliste für den Wechsel

1. Auf einem Testserver mit derselben Ressourcenliste installieren, nicht direkt live.
2. Im gesamten Ressourcenordner nach dem Namen des alten HUDs suchen, um Exports und Events zu finden, die angepasst werden müssen.
3. Altes HUD aus der server.cfg entfernen und das neue an passender Stelle nach Framework und Voice-System starten.
4. Geld, Job, Hunger, Durst, Sprechmodus, Funk und Fahrzeuganzeigen einzeln auslösen und prüfen.
5. resmon zu Fuß, im Fahrzeug und beim Funken messen und mit dem alten HUD vergleichen.
6. Notify, Ankündigungen und Fortschrittsbalken anderer Scripts testen.
7. Den Wechsel im Discord ankündigen und erklären, wie Spieler ihr Layout neu einstellen.

Fertiges HUD oder eigene Lösung

Ein eigenes HUD lohnt sich, wenn du ein Entwicklerteam hast und das Design eng an euer Serverkonzept binden willst. Ansonsten ist ein fertiges Script meist schneller produktiv, sofern du es mit der Checkliste oben prüfst. Web-Services führt im Katalog das ws_hud, das unter anderem Geld, Voicerange, Servername und Logo, Spieleranzahl, Uhrzeit, Notify, Ankündigungen und Action-Messages anzeigt und Spielereinstellungen ohne Datenbank speichert. Bei einem Neustart kann es sinnvoll sein, das HUD zusammen mit Garage, Shops und Identität über eines der FiveM Script Pakete abzudecken, deren Inhalt auf der jeweiligen Paketseite steht. Wer gezielt ein aktuelles HUD sucht, kann ein FiveM HUD Script kaufen und die Angaben zu Framework und Funktionen auf der Produktseite mit den eigenen Anforderungen abgleichen.

FAQ

Wie viel ms darf ein FiveM HUD verbrauchen?

Im Leerlauf sollte ein HUD bei resmon nur wenige Hundertstel Millisekunden zeigen. Wichtiger als ein einzelner Wert ist der Vergleich der Situationen: Steigt die Last im Fahrzeug oder beim Sprechen stark an, aktualisiert das HUD zu oft und sollte auf Intervalle oder Events umgestellt werden.

Kann ich ein ESX-HUD auf QBCore nutzen?

Nur, wenn es die Daten von QBCore lesen kann oder eine Bridge mitbringt. Die Anzeige selbst ist framework-unabhängig, Geld, Job und Needs kommen aber über unterschiedliche Events. Ohne Anpassung zeigt ein reines ESX-HUD auf QBCore meist leere oder falsche Werte.

Sollte die Minimap immer sichtbar sein?

Auf den meisten RP-Servern nicht. Üblich ist, die Minimap zu Fuß mit DisplayRadar(false) auszublenden und nur im Fahrzeug zu zeigen. Das fördert Orientierung über Straßen und Gespräche statt über die Karte.

Wo speichert ein HUD die Einstellungen der Spieler?

Für Positionen, Größen und Sichtbarkeit reicht der clientseitige KVP-Speicher von FiveM. Eine Datenbank ist nur nötig, wenn Einstellungen geräteübergreifend gelten sollen. Da KVP-Werte am Ressourcennamen hängen, gehen sie beim Umbenennen oder Austausch des HUDs verloren.