Mod Rejection not falling back

I’m having an issue with dealing with the Mod Rejection from a Forge server. If I shut down the forge server, clients successfully fallback to the lobby server. However if they attempt to connect to the Forge server and are kicked because of Mod Rejection, they don’t fallback to the Lobby and instead are just disconnected. The strange thing is this functionality use to be working, and I’m not sure what caused it to break.

Plugins I have installed:

  • GlobalTab-1.0-all.jar
  • LuckPerms-Velocity-4.4.26.jar
  • MaintenanceVelocity.jar
  • Neutron-3.0.0-SNAPSHOT.jar
  • VelocityLobbyPlugin-1.0.jar
  • bungeequack-1.0-SNAPSHOT.jar
  • gChat-Velocity.jar
  • joinkick-1.0.jar

I’ve talked to the developer who wrote the support for Forge in Velocity and BungeeCord (@dualspiral). It is not safe to fallback to another server if the Forge handshake fails, which includes mod rejections. The only safe thing to do is to disconnect the client.

We’d like to handle this case more gracefully, but we might not be able to do that until Forge has a stable 1.14 release.

What about if a user was in the hub world and attempted to go to the server and failed with Mod Rejection, would it be ok to just leave them in that world? As I mentioned earlier I was experiencing this functionality working but it has since stopped for some reason.

Again, the FML handshake failed, and there is no safe way to reset things to as they were before we reset the handshake.

If you’re interested, have a look at the (quick) exchange that was had on this pull request which explains why a little more.

The handshake stops half way through and we can’t ask the handshake to reset itself unless the handshake completes. This means that trying to transfer to a different server will fail because the handshake won’t execute on the client side - making the scenario of staying on the hub in this broken state pointless anyway. It would require a PR to Forge 1.12 to fix this and allow Velocity to work with it properly and restore the previous state (using a reset packet or some other packet).

1 Like

Thank you for the information. How difficult would it be to add this functionality to forge? In my particular use case I am using the skcraft launcher which means I have the capability to distribute a modified version of forge for my modpacks.

It would require either a deep understanding of Forge/FML and Velocity. You’d likely need to make sure the following is in play:

  • The client would have to remember its previous state and reset itself to that if prompted (so, reset sent after mods were rejected) - this won’t be trivial
  • Velocity would need to know to send a reset after mods are rejected
  • You’d need to make sure Velocity doesn’t disconnect the client
  • Respawn the player using the dimension change packet to ensure everything is synced up and let mods reset themselves (you could alternatively disconnect and reconnect the player to the server)

Alternatively, you could just add the ability for the reset packet to be sent during the mod phase, but then resend a previously cached handshake.

It’s not trivial, would probably take a lot of effort and still might not work. Forge is not really designed for proxies. It would require a lot of in depth knowledge about the internals of Forge to make sure it all works right - I’d think disconnecting the client is still safer.