This is for Blue Server. Relay Server has a client -> channel condition with less parameters/functionality, here.

This sets the handling mode for client -> channel messages. It takes two parameters:

  1. Inform Fusion parameter. 1 to trigger the "Message > Sent/Blasted > On XXX message to channel" Fusion conditions when a channel message happens, or 0 to disable (quiet mode).
  2. Immediately respond with; one of 0 (approve immediately), 1 (drop immediately), or 2 (wait for fusion).


There are five valid handling modes.

Trying to use the invalid mode (parameters 0, 2) will result in an error and the handling mode not being changed.

Using something outside of 0 or 1 for first parameter, or outside of 0 through 2 for second parameter, will result in an error and the handling mode not being changed.


These conditions are triggered for both Sent and Blasted channel messages, and since Blasted messages are meant to be passed on as fast as possible, it's highly recommended you don't use Mode 5 – Wait for Fusion.


Text messages will be checked against for Unicode validation and normalization, and the "received by client" Unicode allowlist that you may have set using the (Advanced) Set Unicode allowlist action. Failed messages will be discarded, with an server-side error event created, but no "On XXX message" events.

These checks all happen regardless of handling mode.

Mode 1. Auto-approve and don't tell Fusion

You can enable this mode by passing parameters 0, 0.

This is one of the two fastest options performance-wise.


This mode instantly approves the client -> channel message request when processing the request message, and doesn't queue any "Message > Sent/Blasted > On XXX message to channel" events.


This is the default mode that both Blue Server and Relay Server use.

Mode 2. Auto-deny and don't tell Fusion

You can enable this mode by passing parameters 0, 1.

This is one of the two fastest options performance-wise.


This mode instantly discards the client -> channel message request when processing the request message, and doesn't queue any "Message > Sent/Blasted > On XXX message to channel" events.

Mode 3. Auto-approve and tell Fusion

You can enable this mode by passing parameters 1, 0.

This is a slower option performance-wise, and is useful for logging.


This mode instantly approves the client -> channel message request when processing the request message, and queues two message events (one Message > Sent/Blasted > On XXX message to channel event, and one Message > Sent/Blasted > On any message to channel event).

The triggered events are an after-the-fact notification, and due to the message already being approved and sent to the channel, you cannot drop the message during the events.

Mode 4. Auto-deny and tell Fusion

You can enable this mode by passing parameters 1, 1.

This is a slower option performance-wise, and is useful for logging.


This mode instantly denies the client -> channel message request when processing the request message, and queues two message events (one Message > Sent/Blasted > On XXX message to channel event, and one Message > Sent/Blasted > On any message to channel event).

The triggered events are an after-the-fact notification, and due to the message already being dropped, you cannot drop or allow the message during the events.

Mode 5. Wait for Fusion events to approve/deny

You can enable this mode by passing parameters 1, 2.

This is the slowest option performance-wise, and is useful when Fusion events must dictate whether to approve or drop the message.


This mode does not respond to the client -> channel message when processing it, but queues the two events (one On Message Type event, and one Any event).

When the events are triggered, you can choose to drop via the On interactive condition > Drop message (for on message to channel/peer) action.

If you do not run the drop action during either event, the message will be approved and sent/blasted onto the channel once the last event finishes.