On connect request
This is for Blue Server. Relay Server always runs connect request events.
This sets the handling mode for connection requests. It takes three parameters:
- Inform Fusion parameter. 1 to triggers the Fusion condition Connection > On connect request when a connect request occurs, or 0 to disable (quiet mode).
The connect request is step 3 of the Lacewing connection handshake. - Immediately respond with parameter; one of 0 (approve immediately), 1 (deny immediately), or 2 (wait for Fusion).
- 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.
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 connect request when processing the request message, and doesn't queue a Connection > On connect 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 connect request when processing the request message, and doesn't queue a Connection > On connect request event.
The third parameter of this action is used for the deny reason.
This mode will not trigger an Connection > On disconnect event.
Mode 3. Auto-approve and tell Fusion
You can enable this mode by passing parameters 1, 0, "".
This mode 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 instantly approves the connect request when processing the request message, and queues a Connection > On connect request event.
The triggered event runs after the auto-approval, so you cannot deny during the event. However, you can disconnect the client using the Client > Disconnect action if you want.
Mode 4. Auto-deny and tell Fusion
You can enable this mode by passing parameters 1, 1, and the deny reason.
This mode is a slower option performance-wise, and is useful for logging.
This instantly denies the connection when processing the request message, and queues a Connection > On connect 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 already deny during the event.
The third parameter of this action is used for the deny reason.
This mode will not trigger an Connection > On disconnect event when they are disconnected; so you will get an On connect, but no disconnect. This is because you can consider the client already disconnected by this event, so there is no need to set up data for their connection, so there should be no need to remove the data, either.
Mode 5. Wait for Fusion events to approve/deny
You can enable this mode by passing parameters 1, 2, "".
This mode is the slowest option performance-wise, and is useful when Fusion events must dictate whether to approve or deny, and after-the-fact disconnects aren't sufficient.
This does not respond to the message when processing, but queues a Connection > On connect request event.
When the event is triggered, you can choose to deny via the On interactive condition > Deny (for on […] request) action. You should use that instead of Client > Disconnect action.
If you do not use either action, the connect request will be approved once the event finishes.
If you choose to deny in that event, it will not trigger an Connection > On disconnect event when they are disconnected; so you will get an On connect, but no disconnect. This is because you can consider the client already disconnected by this event, so there is no need to set up data for their connection, so there should be no need to remove the data, either.