How to configure DayZ Expansion Name Tags and view distance

By Niko Catarino

Updated 5 October 2026

Load Expansion Name Tags and its frameworks for your DayZ Steam PC server and clients. Edit the active profiles file NameTagsSettings.json, choose a viewing distance and set the player-tag location policy. Check where both viewer and target stand when restricting tags to safe zones or territories.

A Name Tags label identifies the character or held item under your view. Configure party membership in Groups and map/3D location sharing in Navigation; those features work differently from identifying the character you’re looking at.

Install the original module

Prepare the stopped backup, framework migration, keys and matched clients with Expansion installation. The original Name Tags item 2576460232 lists CF 1559212036, Core 2291785308 and Dabs Framework 2545327648 as requirements.

Use the following argument when the manual folders have these names:

"-mod=@CF;@Dabs Framework;@DayZ-Expansion-Core;@DayZ-Expansion-Name-Tags"

Keep the remaining required packages and their documented order. Select Workshop IDs in VXPanel and compare Installed mods with the client/server scope. Configure Name Tags within Bundle if using that suite, without adding its duplicate individual module.

Select the integrations you need: AI for factions/AI behavior, Hardline for held-item rarity and BaseBuilding for territories. Follow each feature’s dependency instructions. A territory switch in Name Tags neither installs BaseBuilding nor creates a territory.

Locate settings and recognize the older field names

Generate the isolated instance’s settings, stop it and save the active file before editing:

<active profiles>/ExpansionMod/Settings/NameTagsSettings.json

The September release declaration defines version 5 and a float PlayerTagViewRange. Compare your installed file with those declarations and preserve its generated m_Version when applying examples.

The author wiki uses the older names ShowPlayerTagsInSafeZones and ShowPlayerTagsInTerritories. The inspected loader reads them for version-zero conversion. Current policy uses OnlyInSafeZones and OnlyInTerritories; inserting obsolete fields into a modern file does not configure those controls.

Configure distance and a visible baseline

Merge this patch into the generated file for a twenty-metre player-tag baseline without a zone restriction. Keep NPC and held-item display off during that check and retain the file’s other fields:

{
  "EnablePlayerTags": 1,
  "PlayerTagViewRange": 20.0,
  "OnlyInSafeZones": 0,
  "OnlyInTerritories": 0,
  "ShowPlayerItemInHands": 0,
  "ShowNPCTags": 0
}

The reviewed HUD checks a view-direction raycast, distance and on-screen position. The twenty-metre setting supplies a limit, not a player radar through walls. Measure an unobstructed target, then compare an obstruction and a direction that does not point at the target.

Five metres is the author default; twenty metres is the example’s test choice. Decide how much identification your server permits before extending the range. Record client HUD settings too when comparing a label visible to one player but absent for another.

Choose the player-tag zone policy

Apply the active generated controls according to the intended policy:

Desired player-tag policy	OnlyInSafeZones	OnlyInTerritories
Unrestricted location	0	0
In a safe zone	1	0
In a territory with BaseBuilding loaded	0	1
Safe zone or territory	1	1

Scroll to see all columns →

The inspected predicate allows a safe zone OR territory when both switches are enabled. It tests the viewer and player target independently. There is no same-zone, same-territory, ownership or party requirement in that predicate. Include a mixed case with the viewer in a safe zone and target in a territory.

Without BaseBuilding loaded, the inspected territory-only policy has no active qualifying territory branch. Check integration and territory state before adjusting the distance. Enabling both flags is not a restriction to one territory shared by the two players.

Set integer colors and retain the icon resource

Use signed integer ARGB values for PlayerTagsColor and PlayerNameColor. Expansion Chat instead uses RRGGBBAA strings. This patch assigns an opaque blue icon and opaque white name:

{
  "PlayerTagsColor": -13584897,
  "PlayerNameColor": -1
}

The icon example is A=255, R=48, G=181, B=255. In the reviewed HUD, player/NPC names use PlayerNameColor when neither AI nor Groups is loaded. With either integration loaded, relationship colors take precedence; held-item rarity can override item text color too. Keep the generated PlayerTagsIcon while establishing the baseline. That field holds a string resource/name; a custom resource needs to exist on the joining client.

During conversion from a pre-version-5 file, the version-5 loader replaces -1 color values with defaults. Complete generation/conversion before editing the chosen colors, with the service stopped. Leave m_Version unchanged; the loader uses its existing value to decide whether conversion is needed. Inspect the saved values before diagnosing contrast as the cause of changed white text.

Add NPC, faction or held-item labels after the baseline

Add options after the baseline: ShowNPCTags selects the inspected NPC path and ShowPlayerFaction uses the AI integration. ShowPlayerItemInHands enables held-item display; Hardline supplies UseRarityColorForItemInHands when its integration is present.

With Name Tags and Hardline installed, merge this held-item test patch:

{
  "ShowPlayerItemInHands": 1,
  "UseRarityColorForItemInHands": 1
}

Compare a recorded-rarity item with an unlisted item using Hardline’s rarity policy. Check Market transaction requirements separately; a rarity color doesn’t tell you whether a purchase is restricted.

Test NPCs and static objects separately from player targets. Check where their labels appear instead of assuming they follow the player-zone rule. The April 30 author notes record range, held-item and static-object fixes for Name Tags in update 1.9.66. Compare your package and observations with those requirements when an older release had a known defect.

Run the viewer-and-target acceptance checks

Keep the distance and test location fixed while two ordinary clients run these checks:

Check	Required observation
Unrestricted distance	Target labels appear within the limit and disappear beyond it
Obstructed/off-screen target	Labels reveal no unintended target through the viewing test
Safe-zone-only policy	Verify both qualifying locations, then move each client outside
Territory-only policy	Installed BaseBuilding and the two locations meet the intended rule
Both switches enabled	Compare safe/safe, territory/territory and mixed positions against the OR policy
Icon and text colors	Both clients load the resource and can read the chosen colors
NPC/held-item features	Each target class has the intended display and installed range
Rejoin after stop/start	Retained settings match the observed policy after reload

Scroll to see all columns →

For a missing label, trace the matched modules, active profiles, settings, viewer location, target eligibility, distance and raycast before touching persistence. Keep the session logs and repeat with fewer mods to isolate an integration conflict.

Stop a mistaken test rollout and restore the saved NameTagsSettings.json. Reverting a package also requires compatible dependencies and the recovery set. Keep saved Groups and territory data when repairing a HUD setting.

Source and verification scope

This guide used AI-assisted research and drafting. The 3 October 2026 review covered original Workshop requirements, April notes, September version-five declarations, zone/range paths, colors and JSON patches. No current Workshop binary or generated profile was inspected, and no game process was started. Player/NPC labels, held-item behavior, integration and recovery remain untested here.