GameStrings.xml

Text the client puts on screen itself. The whole table is sent to every client at login, so any server config can show new text by referencing an id here instead of editing the client's Text.bmd and reshipping the client.

File Location#

Data/GameStrings.xml

Loaded at GameServer startup, alongside Message.xml. /reload common (or reload.common in the Server Manager) reloads it on the server, but the copy sent to clients at login is not rebuilt by it - run /reload plugins after it, then players relog to see the new text.

Not the same as Message.xml#

The two files look similar and are not interchangeable.

If the client has to have the string in hand before it can draw a frame, it belongs here. If the server decides when to say something and sends it, it belongs in Message.xml.

Schema#

<GameStrings>
    <String Id="10500" Text="Manticore Armor Part" />
</GameStrings>

Id Ranges#

The client's Text.bmd can never hold an id above 9999, so 10000 is where this table starts and the two ranges cannot collide.

Anywhere a config takes a text id, either range works. Existing configs that point at Text.bmd ids keep working untouched - nothing needs migrating.

A suggested layout inside the 10000+ range (convention only, nothing enforces it):

Consumers#

Some ids are read by the client directly, by fixed number. Editing their text changes what players see; deleting them leaves an empty label.

Shipped ranges:

Keep these ids when you edit the file. Add your own text in free ranges (for example 10100-10499 or 12000+).

Important Behavior#

Entries are copied verbatim. A % in the text renders literally as % on screen - the client does no formatting. The GameServer logs a warning at startup for any entry containing %. Use Message.xml for anything that needs values substituted in.

A missing id is an authoring bug, not a crash. If a config references an id that isn't in this file, the GameServer logs references missing string Id <n> at startup naming the config that did it, and the client draws an empty string in its place. Check the startup log after editing.

Ids below 10000 are rejected on load, with a log line, so a typo like 1500 instead of 10500 cannot silently shadow a Text.bmd entry. Ids above 65535 are rejected the same way - that is the highest id the client wire format can carry.

Duplicate ids are rejected, keeping the first entry, with a log line.

Common Issues#