Undefined Message for FML:HS

[geNAZt]

We updated to the latest BungeeCord today and users keep reporting this issue:

internal exception io.netty.handler.codec.decoderexception:java.lang.NullPointerException: undefined message for discrminator -2 in Channel FML:HS

[md-5]

@dualspiral please look into this and the other Forge issue(s)

[dualspiral]

Your users need to update to the latest Forge version from http://files.minecraftforge.net - NOT the recommended version. The "reset" packet we use was only introduced recently - this error message is due to old versions not recognising it.

[jeffreykog]

In forge, the bungeecord support is only in the 'new' branch, so you need to update to that

[dualspiral]

@jk-5 It's been merged into master now.

[md-5]

@dualspiral we need some sort of Forge version check, kick them with "Please Update Forge", is it possible?

[johnfriedrich]

You cannot force everyone to use Forge in their clients, because this problem also appears if you are only playing on spigot servers and not on cauldron servers in your BungeeCord network. Hope you get what I tried to say^^ Not all BungeeCord users run Forge/cauldrin only server networks, some are mixed.

[md-5]

@i9hdkill I have no idea what you are trying to say. This message only appears if people already have Forge installed, but their Forge is outdated.

[dualspiral]

@md-5 We already have something in the code that checks for the Forge version, but the problem is we can only get at the forge version the first time we connect to a forge server. This reset packet gets called before we start any handshake - so we can't get the information out if the user goes from a vanilla lobby server to a Forge server.

If the lobby is a Forge server, then you'll find the user does get kicked with a friendly message as the user needs build 1209 (or something like that).

It's a pain. I'll try to come up with something - but it's possible we'll just have to warn users.

@geNAZt - I bet that your lobby server is vanilla, isn't it?

[johnfriedrich]

Oke, I try to make it clear. Currently the thing is, that this errormessage (disconnect) also occurs when switching between spigot servers when Forge is installed (even when when the new version 1217 is installed). So even when you are just using a Forge client whithout playing on Forge/cauldron servers, you get that disconnect.

[md-5]

@dualspiral I mean check the Forge client version. ie: Don't allow old forge clients to even use Bungee.

@i9hdkill yes we know that. However a Forge client has never been supported, even when on Vanilla / Spigot.

[dualspiral]

@md-5 Yes, we can't get the information unless we send it a handshake from the server first. When connecting to a vanilla client, FML sends nothing to the server, and sets itself into the DONE state - we get no version information from it - and we then can't start the handshake to get the information without trying to reset the client first.

Everyone who has this problem will be running a Vanilla lobby.

We could try creating a false handshake - which was my first idea - but that can get complicated and requires the vanilla block list to be stored in Bungee. I might see if I can make it a plugin for Bungee.

I'll have a play about when I get home tonight - see if I have any bright ideas.

On 30 Sep 2014, at 13:29, md-5 notifications@github.com wrote:

@dualspiral I mean check the Forge client version. ie: Don't allow old forge clients to even use Bungee.

@i9hdkill yes we know that. However a Forge client has never been supported, even when on Vanilla / Spigot.

— Reply to this email directly or view it on GitHub.

[geNAZt]

All our Servers are vanilla Servers. I only want to use the newest BungeeCord so i would be able to read Forge Mods from BungeeCord. But i don't get it why an additional Features blocks people of. Maybe this should be done as a Module instead of a must have in BungeeCord ?

[johnfriedrich]

@geNAZt Yep, that was that what I am trying to say. Forge users shouldnt be forced to have the newest Forge installed when playing on a network with vannilla servers only. Why isn't that possible to fix these disconnect errors for users with old forge clients? Ususually the problem would solve itself after some time because everybody is updating their Minecraft to newer version but due to the fact that 1.7.10 (Forge)will exist for a looooong time it's a bit annoying.

Anyways I very apreciate this Implemention!:)

[dualspiral]

@geNAZt

All our Servers are vanilla Servers. I only want to use the newest BungeeCord so i would be able to read Forge Mods from BungeeCord.

The problem is as I said, the full handshake doesn't occur if you connect to a Vanilla server - so we know nothing about the client until we attempt to perform said handshake. Unfortunately, we need to run the reset packet anyway, as Forge clients that have fallen back to vanilla won't accept a handshake either - and therein lies the problem.

We built Forge support in Bungee to be passive, so it mostly just passes packets back and forth - we don't induce a handshake ourselves - this is so we could achieve zero config.

If you really want that - I can give it a go - but then that will either be a module or a config switch.

Maybe this should be done as a Module instead of a must have in BungeeCord ?

I would have prefered that - but we couldn't do it.

By the way - your PR #1235 won't work. If we can detect an outdated Forge, we kick them immediately - but we can only do so if the lobby server is a Forge server. That method is a convenience method.

From issue https://github.com/SpigotMC/BungeeCord/issues/899#issuecomment-53962985:

If your players log onto your server with an old version of Forge, and your lobby server is a Forge server, they will get kicked with a nice message telling them to update Forge. If your players log onto your server using an old version of Forge and the lobby server is a vanilla server, on attempting to switch to forge, they will be kicked with a crash. There is nothing we can do about that at the moment :(

@i9hdkill

Yep, that was that what I am trying to say. Forge users shouldnt be forced to have the newest Forge installed when playing on a network with vannilla servers only. Why isn't that possible to fix these disconnect errors for users with old forge clients?

I'll look into it (I have an idea), but surely the workaround is to get users to update the Forge client or to use vanilla? I know it's annoying, but we can't account for every situation.

[geNAZt]

Then i suggest to not implement Forge into BungeeCord since this is not the main task of BungeeCord. As i mentioned before i think, if not possible in any other way, i would do it in a Module which needs to be installed into BungeeCord (like forge coremods). To force all Clients, which are Forged modded, to force to update to play on a Server which does not need Forge is not acceptable. Since you send the Reset to everyone who has "completed" the Forge Handshake (this can also be a vanilla client in your case).

        if ( user.getForgeClientHandler().getClientModList() == null && !user.getForgeClientHandler().isHandshakeComplete() ) // Vanilla
        {
            user.getForgeClientHandler().setHandshakeComplete();
        }

This would also catch all Forge Clients which have never send its Modlists (vanilla Lobby). So the Handshake for Forge has never really completed and you don't know in which condition the Handshake is (since you set it to done when the login arrives and the first server did not request the modlist). So you are forced to sent a Reset everytime the Client connects to a new Server. This is ok for a Vanilla Client since it ignores the Pluginmessage completly. Forge will get the reset (even if the handshake never has been completed) and so old Versions will crash.

To get to the point why my fix will work is easy. FML itself will be sent over once the Modlist is requested. As long as the Modlist has never been requested the forgeOutdated stays false until you know its really outdated. So i know that you are getting the Modlist at some point (even forge ones without reset send them once). So you can check if the Forge client has fully registered to the Server. If not just don't send the reset packet. If you know the Forge Client has been validated send it.

The PR i sent is incomplete but i can change it to do what i currently wrote. Give me 10-15 minutes to update it.

[geNAZt]

Updated the PR and verified its working. If you need some more testing data hit me on IRC.

[dualspiral]

Please read my comment again - in particular, the following points:

The problem is as I said, the full handshake doesn't occur if you connect to a Vanilla server - so we know nothing about the client until we attempt to perform said handshake. Unfortunately, we need to run the reset packet anyway, as Forge clients that have fallen back to vanilla won't accept a handshake either - and therein lies the problem.

I'd also like to point out I also said, when responding to your point about modules before:

I would have prefered that - but we couldn't do it.

Whilst I agree with that point - we couldn't technically do it. Believe me, I tried.

---

This issue has actually flagged up two problems:

1) We need to see if we can find a better way to get the FML build number. This might be very difficult to do without faking a handshake and leaving the client in a very inconsistent state, or by including 1.7 specific data in Bungee (something I am very keen to avoid) 2) All vanilla setups should accept any Forge clients. I have some idea on how to try and sidestep this.

There is also the question of if we can get the mod list reliably - but that should be taken in tandem in 1).

I'm keen on taking problem 2 on first - this seems to be the bigger issue. This should be a fairly simple change where we track the type of server we are on, and only send the reset packet when we go to a new modded server, or from modded to vanilla.

[dualspiral]

Apologies - I hit the delete button accidently instead of cancel, so I have to write out what I just said again.

https://github.com/dualspiral/BungeeCord/commit/c97cdac97117799e00d117a1dd2e57d9266e27d3 should hopefully fix point 2) above. It works be delaying sending a reset packet to clients when the client is currently on a vanilla server. The packet should now only be sent if either:

• The client is already on a modded server.
• The client is on a vanilla server, and then tries to connect to a modded server.

There is no PR yet - as I haven't tested it. If someone could test it and let me know how it goes, along with the version tested, that'd be great. I'll PR once I've either tested it myself, or I'm convinced this is working and/or the right thing to do.

[dualspiral]

I've updated the diff to include fixes to formatting and an extra comment in a comment to clarify something - https://github.com/dualspiral/BungeeCord/commit/7936515dd40d33e7a88fc9f2b25a9cb74301cab8

[dualspiral]

Tested it using old and new builds, and this should fix point 2 above. PR submitted.

[md-5]

Resolved