Add Rusty Connector support

[ajh123]

Description

Rusty Connector is proxy management which allow servers to be dynamically added / removed to / from the proxy. Additionally Rusty Connector makes you group your servers into "families" (e.g you may have a hub family and a bed wars family). Note: Rusty Connector (proxy) supports Vecloity only, however Velocity supports traditional bungee plugin messaging

This means if the Bed Wars plugin wanted to send the player to the main hub Bed Wars would have to send the player to hub family instead of a hub server.

If the Rusty Connector transfer failed then the plugin will fallback to the configured bungee server.

Tested minecraft versions: (Paper-196 (MC: 1.20.1))

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change) Not sure if existing server configs break, however I've kept my changes very minimal.

Checklist:

• My code follows the code style of this project. I think it does
• My change requires a change to the documentation.
• I have updated the documentation accordingly. Not sure where the documentation lives, but will update it once found
• I have added tests to cover my changes. It would be hard to test this feature since it requires a proxy with Rusty Connector configured
• All new and existing tests passed. I have played a round of Bed Wars myself and everything appears to work as expected - also it looks like there aren't any tests

I would like to know how you would properly make Rusty Connector an optional dependency without having class loading errors.

[ajh123]

Also, Rusty Connector have their own party / friends module which I haven't implemented yet.

[Misat11]

Hello and thank you for your contribution.

We are unsure whether we want this to be part of the base plugin or not. From what I heard, Rusty Connector is seeing API breakages in the future, so it would make sense to wait for those changes before merging.

I am still considering it. There are not many users of Rusty Connector for us to even care, but it sounds like a cool project.

[Misat11]

To answer your question about ClassLoadingErrors: the most simple way to fix that is to isolate the stuff related to this plugin in a specific class and only use it when you are sure the plugin is enabled.

You can also declare fields of non-existing classes (like you did in BedWarsPlugin.java), that's not a problem for JVM. Invocation of unknown method fails only when the JVM attempts to actually invoke it, so simple if-statement is enough. But you have to be careful when using inner classes, for some reason they are handled differently.

[ajh123]

To answer your question about ClassLoadingErrors: the most simple way to fix that is to isolate the stuff related to this plugin in a specific class and only use it when you are sure the plugin is enabled.

You can also declare fields of non-existing classes (like you did in BedWarsPlugin.java), that's not a problem for JVM. Invocation of unknown method fails only when the JVM attempts to actually invoke it, so simple if-statement is enough. But you have to be careful when using inner classes, for some reason they are handled differently.

I tried my PR without rustyconnector and you are right. I thought that the import statements would cause an exception to be thrown but they don't.

[ajh123]

Hello and thank you for your contribution.

We are unsure whether we want this to be part of the base plugin or not. From what I heard, Rusty Connector is seeing API breakages in the future, so it would make sense to wait for those changes before merging.

I am still considering it. There are not many users of Rusty Connector for us to even care, but it sounds like a cool project.

Maybe the reason why not many people use Rusty Connector is that not many plugins support it, so Rusty Connector is not widely known?

Also, the breaking API changes may not break this PR because all what I'm doing is sending a Rusty Connector packet (a message) to the proxy asking it to forward the player. So, it would be very simple to fix it, if this process does become broken.

[Misat11]

Since feat/remote has been merged, I feel like Rusty-Connector can be also implemented for forwarding messages from/to lobbies/game servers as an alternative to the insecure simple socket system.

[ajh123]

Since feat/remote has been merged, I feel like Rusty-Connector can be also implemented for forwarding messages from/to lobbies/game servers as an alternative to the insecure simple socket system.

That's definitely a good idea, could you link to the PR / commit that introduced feat/remote?

[Misat11]

Didn't expect such fast answer 😃

Since the merge was fast-forward, there's no merge commit, but here's the link to the diff between latest commit and commit before adding remote games: 678a2bb...bec9f34

Basically it would require adding a new implementation for Messenger and updating the logic in ProtocolManagerImpl to support new messenger type.

[ajh123]

It seems like Rusty Connector does not have a method to broadcast a packet to all servers (McLaoders) - which Messenger requires an implementation of.

Also, there doesn't seem to be a method that allows us to retrieve names of all McLaoders on a Rusty Connector network.

However, on the Velocity proxy, Rusty Connector does have a method that can get a list of all McLaoders.

So broadcasting must work like:

1. McLaoder server creates packet
2. McLaoder sends packet to proxy
3. Proxy sends packet to all other McLaoders

This must mean a Velocity plugin must be created.

[Misat11]

This is kind of unfortunate that Rusty Connector does not allow us to obtain the list of MCLoaders or broadcast to individual families from other MCLoaders. I'd generally avoid having a proxy plugin, but if there's no other choice, a simple Velocity plugin can be made.