[SPIGOT-3975] SendMessage() Inconsistency when using Narrator Created: 26/Jun/18  Updated: 27/Aug/19  Resolved: 23/Apr/19

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Simon Chuu Assignee: md_5
Resolution: Fixed Votes: 0
Labels: chat, message
Environment:

BungeeCord, Bukkit, and Spigot in general


 Description   

There are four options for Narrator: None, All, Chat, and System.  It's great that the ChatMessageType enum is implemented, so thank you for that!

However, the Narrator's functionality is awkward on Bukkit servers because player chat messages and Player.sendMessage(String) are sent as "System" messages.  When using the Spigot().sendMessage(BaseComponent) method on a Player or CommandSender, the default ChatMessageType is ChatMessageType.Chat, thus creating some inconsistency. This is also true on the BungeeCord, where the inconsistency becomes further noticeable when BungeeCord plugin makers just use the CommandSender.sendMessage(BaseComponent) (ChatMessageType.Chat) like they do on Bukkit servers as CommandSender.sendMessage(String) (ChatMessageType.System).

This issue doesn't affect anyone who doesn't use Minecraft's Narrator functionality, but for people who use it, the inconsistencies found in "System" and "Chat" mode is puzzling.

My suggestion is to make the messages consistent, where the default ::sendMessage stays or becomes System and the player chat messages becomes Chat. This implementation should make using Narrator more acceptable on Bukkit/Spigot servers.

 Comments   
Comment by YourCoal [ 27/Aug/19 ]

Narrator is still not working, regardless of plugins or not, with latest 1.14.4 build.

Comment by md_5 [ 23/Apr/19 ]

Resolved in 1.14

Comment by Simon Chuu [ 27/Feb/19 ]

I've almost long-forgotten about this issue until a link was made in SpigotMC/BungeeCord#2607.

I have yet to look into Spigot side of the messaging because I made a workaround by making the messages go through an event in a Spigot plugin and broadcast it to everyone from the event listener, which looks like this:

@EventHandler(priority = EventPriority.HIGHEST)
public void chatEvent(AsyncPlayerChatEvent e) {
    if (e.isCancelled())
        return;

    BaseComponent send;

    // ... some code checking for modified chat format (for prefix/suffix)...

    // If format is not modified, then
    // Note: I added methods to enable URLs in `e.getMessage()` and hover information on `e.getPlayer()`
    send = new TranslatableComponent("chat.type.text", e.getPlayer().getDisplayName(), e.getMessage());

    for (Player p : e.getRecipients())
        p.spigot().sendMessage(ChatMessageType.CHAT, send);

    plugin.getPluginMessenger().chat(e.getPlayer(), e.getMessage(), tag);

    e.getRecipients().clear(); // Destroy default event.
}

I decided to use the TranslatableComponent over TextComponent for unchanged formatting for narrator's feature that reads back in "chat.type.text.narrate".

I think it's on the players to know that they have chat disabled. However, IIRC from previous experiences, disabling chat in the client option hasn't shown to prevent BungeeCord plugin messages from going through into the client messages.

Since the client message display configuration option gets sent to the server, maybe Spigot can remind players on their login that they have their chat disabled, which the message itself should have an option to be disabled as well.

Comment by Black Hole [ 27/Jun/18 ]

This inconsistency has historical reasons. Before those chat message types where introduced, all messages where "system". So it's more that chat message plugin should change to using "chat". Apart from that "system" is the right choice for all plugin messages.

The component chat system is taken directly from BungeeCord, you should create an issue in the BungeeCord issue tracker. I don't know why the default chat type is different on BungeeCord.

So a config option for the default chat type in Spigot might also work for your use case. But changing the default to "chat" would bring up a lot of issues where players are not getting messages because they disabled "chat" in their client options.

Generated at Fri Mar 14 09:35:35 UTC 2025 using Jira 10.3.3#10030003-sha1:d220e3fefc8dfc6d47f522d3b9a20c1455e12b7b.