Long messages sent through PlayerBase.MessageImportant() remain on a single very wide chat row and continue past the right edge of the screen. Their endings are not readable, even at a captured window size of 3440 × 1440.

This occurs with a 999-character ASCII message, below the logged system chunk length of 1000. Messages above that threshold are split into additional rows, but those rows can also extend beyond the screen.

Additional information

The public Chat.Add implementation splits messages according to string length and the channel's chunk limit. This is different from wrapping text according to its rendered width.

Tests recorded ChatMaxSystemLength=1000 and outgoing payload lengths of 999, 1000, 1001, 2001, 4001 and 20000. The 20000-character test reached the final numbered block and left the last 12 chat elements visible. These observations do not establish an unlimited total message size.

Related archived report: T169480 — messages.xml messages are barely readable. Its comments also describe long messages extending beyond the screen.

1. Start a local server and connect a player with Game Messages enabled.

2. After the client has loaded, construct and send a 999-character message with ordinary spaces between words:

string text = "[WIDTH TEST] ";
while (text.Length() < 999)
   text += "WWWWWWWWWW ";
text = text.Substring(0, 994) + "[END]";
player.MessageImportant(text);

3. Observe that the message continues past the right screen edge, while the [END] marker is not visible.

4. Optionally send a longer message to observe that splitting into 1000-character chunks does not make the individual rows fit the available width.

The attached init.c sends the 999-character payload once, five seconds after connection.

Actual result

The text extends beyond the screen instead of wrapping at the visible chat boundary. Spaces between words do not trigger width-aware wrapping.

The complete message should remain readable within the available chat area and wrap at word boundaries. Its horizontal bounds should respect nearby microphone/voice-level HUD elements, with a small margin.

A limit based on rendered width should adapt to the font, resolution, UI scale and HUD position. The 81–85-character lines in the separate compact example only fit that particular UI configuration; they are not a universal safe character limit.