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

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

  1. Inform Fusion parameter. 1 to trigger the "Message > Sent/Blasted > On XXX message to peer" Fusion conditions when a peer 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 peer 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.


The sending client is selected by default during the Fusion events, but you can select the receiving client using the On interactive condition > Select receiver (for "on message to peer") action.

You can also re-select the sending client if necessary using the On interactive condition > Select sender (for "on message to peer") action.


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 -> peer message request when processing the request message, and doesn't queue any "Message > Sent/Blasted > On XXX message to peer" 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 -> peer message request when processing the request message, and doesn't queue any "Message > Sent/Blasted > On XXX message to peer" 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 -> peer message request when processing the request message, and queues two message events (one Message > Sent/Blasted > On XXX message to peer event, and one Message > Sent/Blasted > On any message to peer event).

The triggered events are an after-the-fact notification, and due to the message already being approved and sent on to the peer, 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 -> peer message request when processing the request message, and queues two message events (one Message > Sent/Blasted > On XXX message to peer event, and one Message > Sent/Blasted > On any message to peer 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 -> peer 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 peer once the last event finishes.