-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Event for Handling Server Connection Failures #3638
base: master
Are you sure you want to change the base?
Conversation
3c888dd
to
c125627
Compare
If you are using ProxiedPlayer#connect, you can already decide what to do with failed connection attempts (callback parameter). |
|
||
/** | ||
* This event is called when a connection to a server fails. | ||
* This can occur when the server is offline, the player cannot login due to version mismatch, or the server is full. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version mismatch and server is full is actually the same: server kicked player
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, this description was incorrect.
This event only fires when the connection itself fails, such as when the server is offline.
It does not fire when version mismatch or server is full, so I have fixed documentation.
Sure, I added documentation on the behavior when using the ProxiedPlayer#connect callback and that the callback is not canceled when this event is canceled /**
* This event is called when a connection to a server fails (e.g. the server is down).
* Only called when the server cannot be connected to, and is not called when kicked from a server (e.g. the server is full).
* Cancelling this event will cancel the transfer to the fallback lobby and prevent the default error message from being shown.
* <p>
* If you are using {@link ProxiedPlayer#connect}, this event will be called after the callback is called.
* So, you can't cancel the callback by cancelling this event.
*/ |
if ( request.isRetry() && def != null && ( getServer() == null || def != getServer().getInfo() ) ) | ||
ServerConnection server = getServer(); | ||
ServerConnectFailEvent event = new ServerConnectFailEvent( UserConnection.this, server, request ); | ||
if ( !bungee.getPluginManager().callEvent( event ).isCancelled() ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you cancel this doesn't the player just get stuck in limbo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, when your plugin cancels the event without disconnect or sendMessage,
- If a player tries to log in, "Joining World..." will be displayed and stuck until timeout.
- If the player tries to move with
/server
, etc., the server move will be canceled and nothing will happen.
I think this is the correct behavior, since the point of canceling this event is to handle it on the plugin side.
Your plugin can for example do the following
- Start the server asynchronously while the player is connected and stuck, then connect the player after the server starts. You can kick if it fails to start server.
Do you have any ideas for a more appropriate behavior for cancellations?
I will be glad to implement it if you request it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me think about it. I think this is a hard one because already have callback and connect events
This pull request adds an event for server connection failures in Bungeecord.
When a player encounters the message "Could not connect to a default or fallback server, please try again later," this behavior can now be handled by plugins.
This enhancement is particularly useful for plugins that need to take action when server startup fails.
Motivation:
ServerConnectEvent
to ping the server and perform actions if the ping fails. However, this approach leaves the default message displayed, which we cannot remove (unless we perform synchronous ping operations, which would block threads and impact performance).