Arclight 1.21.1: Proxy Chat problem

[xDodi]

Are you using MySQL?

Yes

Are you using a proxy?

Yes - Velocity

Question

I'm having trouble with shared chat on my servers.
The servers have ChatControl connected to MySQL, and the proxy.yml is also configured on both servers. The channel I'm writing to has Proxy: true.

  List:
    standard:
      Format: chat
      Format_Spy: '@noprefix chat'
      Proxy: true

The configuration on both servers is the same, 1:1, except for the proxy.yml file.

The proxy is VelocityControl, and in the Velocity config, bungee-plugin-message-channel is set to false.

Could the problem be that the servers are Arclight (Fabric + Plugins)?

[xDodi]

@kangarko

[devpedrobarbosa]

Hey @xDodi

I'm extremely sorry for the delayed response.

I'm not 100% sure if the problem could be your server software.

Would you mind sending us your debug file?

Thanks for reaching out.

[xDodi]

@devpedrobarbosa

debug-2.zip

settings.yml

debug-1.zip

[devpedrobarbosa]

@xDodi

Thank you so much. I'll be investigating ASAP.

[devpedrobarbosa]

@xDodi

I was not able to identify any inconsistencies with your config. Neither was I able to reproduce this issue with almost the same exact setup, except for Arclight and your third-party plugins.

At first, I would recommend testing out v11.6.7, which brings updates in the forwarding system.

If it still doesn't work (and you're able to), please test in a clean Paper server and with/without third-party plugins.

[xDodi]

Are there any plans to add cross-server chat using Redis instead of a proxy plugin?

[devpedrobarbosa]

Hey @xDodi

Sorry for the delay.

Did it work at all after you updated to 11.6.7?

If not, have you tested with Paper?

I'll be releasing an update real soon that improves forwarding handling a bit more and fixes some edge cases. I'll keep you posted here so you can test once it's out.

[kangarko]

@kangobot ultrathink this one

[kangobot]

Here's the deep analysis of this Arclight proxy chat issue:

Root cause is almost certainly Arclight's plugin messaging implementation. Here's why:

How proxy chat works

1. When a player sends a message in a Proxy: true channel, the Bukkit server calls player.sendPluginMessage(plugin, "BungeeCord", data) with a logical subchannel header (plugin:chcred) embedded in the payload
2. Velocity receives this on the "BungeeCord" physical channel (requires bungee-plugin-message-channel: false in velocity.toml — which the user has set correctly)
3. VelocityControl's forwardData() relays to all other servers in the same cluster via server.sendData("BungeeCord", data)
4. The receiving server's Foundation listener demultiplexes the logical subchannel and routes to ChatControlProxyListenerBukkit, which calls channel.processProxyMessage()

Where Arclight breaks this

Arclight is a Forge+Bukkit hybrid. In modern Minecraft (1.13+), plugin message channels are namespaced — Velocity internally uses bungeecord:main as the modern identifier for the legacy "BungeeCord" channel. Standard Spigot/Paper handles this translation transparently, but Arclight's networking stack sits on top of Forge, which has its own channel registration system. Three likely failure points:

1. Outgoing messages never reach Velocity — Arclight's player.sendPluginMessage() goes through Forge's network layer, which may not correctly translate the legacy "BungeeCord" channel name to the namespaced bungeecord:main that Velocity expects
2. Incoming messages never reach ChatControl — even if Server A sends correctly, Server B's Arclight may not deliver incoming "BungeeCord" plugin messages to Bukkit's PluginMessageListener
3. Empty server detection — forwardData() skips servers where iteratedServer.isEmpty() returns true. If Velocity's player tracking doesn't correctly see Arclight players, the proxy would skip forwarding entirely

What the debug file would show

Since @devpedrobarbosa couldn't find config issues, the problem is at the transport layer. With Debug: [proxy] enabled in settings.yml on both servers:

• If the sending server logs nothing → the message never reaches ProxyUtil.sendPluginMessage(), or the send silently fails (no online player found, or channel not registered)
• If the sending server logs but VelocityControl shows no incoming packets → Arclight's plugin messaging isn't reaching Velocity
• If VelocityControl logs incoming but the receiving server doesn't → forwarding is failing (likely empty server detection or cluster mismatch)

Recommendation

This is an Arclight platform limitation, not a ChatControl bug. The user should:

1. Test on Paper to confirm — if it works on Paper, Arclight's plugin messaging is the cause
2. Enable Debug: [proxy] in settings.yml on both servers to pinpoint exactly where the chain breaks
3. Check Arclight's GitHub for known issues with Velocity plugin messaging — this is a known category of problems with hybrid servers

On the Redis question

Redis transport between proxy instances is already supported (for multi-proxy setups), but it still goes through Velocity — it doesn't bypass the proxy. A direct Bukkit-to-Bukkit Redis PubSub channel that skips the proxy entirely would be a significant feature addition and is not currently implemented. It would solve the Arclight problem since it wouldn't depend on Bukkit's plugin messaging API, but it's a non-trivial amount of work.

TL;DR

Arclight's Forge-based networking stack likely breaks Bukkit's player.sendPluginMessage() path to Velocity. Ask the user to test on Paper to confirm, and enable Debug: [proxy] to get concrete evidence. This is not something we can fix on our side — it's an Arclight platform compatibility gap.

[kangarko]

@xDodi can you test on Paper first please?

[xDodi]

It works on Paper. The problem is that Arclight has issues with plugin communication. That’s why I asked about Redis.

[devpedrobarbosa]

@xDodi

We do support Redis, but it’s not exactly a “proxy bypass.” You would still need a fully functional communication layer between the proxy and the backend servers for everything to work properly.

While implementing a workaround is technically possible, it would require a significant amount of development time just to compensate for an issue outside of our plugin. Because of that, this isn’t something we can prioritize right now — it may be considered for a future update, but we can’t make any guarantees.

Thank you for your understanding.