Invalid lang in options.txt leads to connection error

Cannot reproduce in 1.11 when joining a vanilla server.

You also have to select the language in the language settings.

Sorry, the first video didn't work. I uploaded it on Youtube now: https://youtu.be/BaedhcBOAq4

1. Please attach the resource pack you used.

2. The first video works fine - you just have to download it on your computer.

3. Servers with plugins are not supported, so using them may invalidate your ticket. Were you able to reproduce it with a vanilla server?

1.Resourcepack attached
2.Ok, thanks 🙂
3.The server seen in the first video (with the title "Sniper Battle by NOPEname") is a vanilla server (1.10.2)
Also I couldn't join the local host

It happens when the language has another name than an already existing one.
In this example "en_Sniper".
If I rename it to "en_US" it replaces the default English(US) language and everything is fine, even though the language file is different. Only the name causes the problem.

Seems like the network protocol involves transmitting the client's language setting to the server for whatever reason, and the server refuses the connection if it doesn't know what the reported language ID is. Fixing this requires either updating the protocol to not transfer the client's language setting (which there doesn't seem to be any use for) or putting in a workaround for servers to silently accept unknown languages without disconnecting.

Removing transmission of the language is probably a bad idea, as it's used for plugins. It's one of those options which the vanilla server doesn't care about but still should probably remain.

That said: Looking at it, the server is not validating that it is a language that it knows. It's instead doing a much more common validation - the language string is rejected if it's longer than 7 characters long (all strings have a max length on the network - for instance chat is 255 chars and usernames are 16).

The main problem is that the network imposes a max length that the client doesn't know about, with a secondary problem of that max length not being cleanly reported to the client when it's disconnected. There is a disconnect message in the server log:

pokechu22 lost connection: TranslatableComponent{key='disconnect.genericReason', args=[Internal Exception: io.netty.handler.codec.DecoderException: The received string length is longer than maximum allowed (9 > 7)], siblings=[], style=Style{hasParent=false, color=null, bold=null, italic=null, underlined=null, obfuscated=null, clickEvent=null, hoverEvent=null, insertion=null}}

but that's still not too helpful.

My recommendation is to add validation of the max length to the languages section in the pack MCMeta, and maybe also increase the max length (though, it's supposed to be a real language code, which shouldn't be too long).

Changing the key for your language from en_Sniper to en_Snip causes the disconnect to stop.

Side note: That length restriction was present in 1.10, 1.9, and 1.8 - I think MC-75043 was never actually fixed.

I just had this happen to me today in Minecraft 1.11.2, and I believe it might have been the cause of MC-82705 on my previous computer. This is a serious issue for mapmakers who take advantage of language files.

I hate this bug SO MUCH!!! It caused me issues for SO LONG until I figured out that it was THIS