This is for Blue Server. Relay Server always runs leave channel request events.

This sets the handling mode for channel leave requests. It takes three parameters:

  1. Inform Fusion parameter. 1 to triggers the Fusion condition Channel > On leave request when a channel leave request happens, or 0 to disable (quiet mode).
  2. Immediately respond with; one of 0 (approve immediately), 1 (deny immediately), or 2 (wait for fusion).
  3. The deny reason, if denying immediately.


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.

If the deny reason is non-blank when the immediate response is not set to deny, the reason will be ignored without error.


Note the Channel > On channel close event will always trigger, regardless of leave request 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 channel leave request when processing the request message, and doesn't queue a Channel > On leave request event.

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

You can enable this mode by passing parameters 0, 1, and the deny reason.

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


This mode instantly denies the channel leave request when processing the request message, and doesn't queue a Channel > On leave request event.

The third parameter of this action is used for the deny reason.

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 is the default mode Blue Server uses, to match Relay Server's defaults.


This mode instantly approves the channel leave request when processing the request message, and queues a Channel > On leave request event.

The triggered event is an after-the-fact notification, and due to the request already being approved, you cannot deny the leave during the event.


However, you can make the client rejoin the channel, using the Join actions under the Channel menu… but this is not good practice as the client will get an approved leave then a rejoin for the same leave attempt, and all peers will get a peer disconnect then a peer connect message.

Worse, if the original peer is the channel master and the channel is set to auto-close, you will have to make a list of all the peers before the channel leave, and rejoin all of them after.

Mode 4. Auto-deny and tell Fusion

You can enable this mode by passing parameters 1, 1, and the deny reason.

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


This mode instantly denies the channel leave request when processing the request message, and queues a Channel > On leave request event, with the deny reason already set during the event.

The triggered event is an after-the-fact notification, and due to the request already being denied, you cannot deny the leave during the event. However, you can make the client leave by kicking using the Kick actions under the Channel menu… but this is not good practice as the client will get a deny then an approval for the same leave attempt.

The third parameter of this action is used for the deny reason.

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 deny the leave, since after-the-fact kicking/rejoining is bad practice.


This mode does not respond to the channel leave request message when processing it, but queues a Channel > On leave request event.

When the event is triggered, you can choose to deny via the On interactive condition > Deny (for on […] request) action.

If you do not deny, the leave will be approved once the event finishes.