Skip to main content
This documentation is written for NameplateBuilder >= v4.260326.7 with API >= v2.2.0.
Most segments should use resolvers. This page covers the alternative: pushing text to entities yourself using setText() and clearText().

When Do You Need This?

You need manual text when your segment’s value doesn’t come from an ECS component on the entity. Some examples:
  • An admin runs /setbounty goblin 500 - the bounty is stored in your mod’s config, not as a component on the entity
  • A player earns a title from an achievement system - the title lives in a database, not on the entity
  • A buff is applied through a chat command - there’s no BuffComponent to read from
  • You need to seed initial nameplate data on NPCs when they first spawn
If the data does live on the entity as a component (health, stats, faction, etc.), use a resolver instead - it’s simpler and you don’t need to write any tick systems.

The Two Methods

setText() - Set or Update

This sets the text for your segment on a specific entity. If the entity doesn’t have a NameplateData component yet, one is created automatically. If the segment already has text on this entity, it’s overwritten. You can call this from anywhere you have access to the Store and a Ref - event handlers, command handlers, systems, etc.

clearText() - Remove

This removes your segment’s text from the entity. If the entity has no other segments left, the entire NameplateData component is removed automatically.

Example: Admin Command Sets a Bounty

Here’s a concrete scenario. Your mod has a /setbounty command. When an admin uses it, you want to show the bounty above the targeted entity:
You still need to call define() in setup() so the segment appears in the player UI:

The Tick System Restriction

There’s one important restriction: setText() cannot be called inside an EntityTickingSystem if the entity doesn’t already have a NameplateData component. This is because setText() needs to add the component to the entity, and Hytale locks the store for structural changes during tick processing. If you try, you’ll get:
This only matters when you need to initialize nameplate data on entities that don’t have it yet (like newly spawned NPCs). Once an entity has the component, updating it from a tick system is fine.

Tick System Pattern: NPC Spawn Initialization

If you need to give NPCs nameplate data when they first appear in the world, you need a tick system that uses CommandBuffer instead of setText():
Why CommandBuffer? Inside a tick system, the entity store is locked. You can’t add or remove components directly. CommandBuffer queues the change and applies it safely after the system finishes processing. Why putComponent() instead of addComponent()? addComponent() throws an error if the component already exists. putComponent() adds it if missing or replaces it if it exists - safer when multiple systems or mods might initialize the same entity. Register the system in your plugin’s setup():

Updating Text Every Tick

Once an entity already has a NameplateData component (from initialization or any other source), you can safely update it from a tick system. No CommandBuffer needed - you’re modifying existing data, not adding a new component:

Working with NameplateData Directly

If you need lower-level access to the nameplate component, you can read and write it directly:

Manual Text + Resolver Priority

If an entity has both manual text and a resolver for the same segment, the manual text wins. This is useful when you want a resolver to handle the normal case but override specific entities:

Next Steps

  • Format Variants - Let players pick between display formats
  • Advanced - Hidden metadata keys, cleanup, and edge cases