UI YML: Bossbars, Thresholds, and Driver HUD

ui.yml controls the live vehicle HUD.

This is the file that decides what a driver sees while mounted, how often that information updates, and how loud or quiet the driving interface feels.

If the driving loop works mechanically but feels noisy, unclear, or unfinished, this file deserves attention.

What the current file already contains

The current resource file is compact and focused:

ui:
  updateEveryTicks: 2
  bossbars:
    hp:
      enabled: true
      style: SEGMENTED_10
      title: '&c&lHP &7- &f{hp}/{hp_max} &7({percent}%)'
      thresholds:
        yellowBelow: 0.6
        redBelow: 0.3
    fuel:
      enabled: true
      style: SEGMENTED_10
      title: '&e&lFuel &7- &f{fuel}/{fuel_max} &7({percent}%)'
    speed:
      enabled: false
      style: SEGMENTED_20
      title: '&fSpeed &7{speed}/{speed_max}'

This already tells you the main public design choices:

• how often the HUD updates
• which bossbars exist
• which bossbars are enabled
• how warning colors should kick in

updateEveryTicks

This controls how often the HUD refreshes.

Lower values feel more immediate. Higher values lighten the visual noise and reduce how chatty the HUD feels.

Good rule:

• keep it low enough to feel responsive
• do not update faster than you actually need

For most public setups, the default fast-but-readable update cadence is a strong starting point.

bossbars.hp

This is the health bar for the full vehicle.

Important fields:

• enabled
• style
• title
• thresholds
• colors

This is usually the first bar to keep enabled because it answers the most basic driver question:

"How close is this vehicle to failing?"

bossbars.fuel

This is the second most useful bar on most live servers.

Important fields:

• enabled
• style
• title
• thresholds
• colors

Keep this enabled when:

• fuel is a real part of the server loop
• players actually need to plan around service stations
• vehicles should feel like persistent resources rather than disposable props

bossbars.speed

The speed bar is optional for a reason.

Some servers benefit from it. Others feel cleaner without it.

Enable it when:

• speed is gameplay-critical
• racing or precision piloting matters
• the server wants a more instrumented driving feel

Leave it off when:

• the HUD already feels busy
• players can judge speed by feel
• health and fuel are more important than raw speed numbers

title

The title line is where the HUD gets its voice.

The current examples use:

• &c&lHP
• &e&lFuel
• token values like {hp}, {hp_max}, and {percent}

That is a good public pattern because it is:

• short
• readable at speed
• easy for players to interpret

Avoid overstuffing the title with too many tokens or lore-like wording.

thresholds

Thresholds are gameplay tone, not just color.

Example:

thresholds:
  yellowBelow: 0.6
  redBelow: 0.3

Higher warning thresholds make the HUD feel more tense and cautious.

Lower warning thresholds make the HUD feel calmer and more forgiving.

colors

These colors shape how readable each state feels under pressure.

Use them to support fast recognition:

• healthy
• caution
• critical

The important part is consistency. If every vehicle class uses the same warning logic, drivers learn the HUD much faster.

Suggested order

1. Keep HP enabled first.
2. Keep Fuel enabled if the server uses real fuel.
3. Enable Speed only if drivers truly need it.
4. Make the titles short and readable.
5. Test the HUD in motion, not only while parked.

Related pages

• messages YML: Player Language, Errors, and Support Feedback
• catalog YML: Browse Layout and Variant Entry Flow
• messages, Bossbars, and Driver Feedback
• catalog, UI, Surfaces, and Driver Feedback