Issue Description

When trying to connect to any server, the user receives the error "Illegal char <:> at index 34: encyclopedia-servers\xxx.xxx.xxx.xxx:xxxxx\etsave.dat" where the x's are the IP and Port of whatever server the player is attempting to connect to. The modpack in use is Roguelike Adventures and Dungeons by Dreams as found here: https://www.curseforge.com/minecraft/modpacks/roguelike-adventures-and-dungeons
The modpack version in use is version 1.34a This issue seems to be isolated to the user in question, and happens regardless of the server they connect to or the computer they connect from. On the server there is no error given, however on the client the initial error starts as listed above, and then enters a cascading error loop to which the client is unable to escape and ends up with a log file that beings to grow in size as the crash loop cycles over and over. Attached is the complete latest.log file. In it the player initially connects to a single player world, says "Hello Gunner" once the world loads, and then closes that world. The player then attempts connection to a server, and almost instantly the crash/issue presents, and the client enters into a loop crash state. The crash event starts on line 2214 when the player attempts connection, and the line indicating that Tropicraft was the cause is in line 2222.

It should be noted that this happens regardless of the server the player connects to, or the OS that the server is running on, the same error is always generated. Additionally, this error happens regardless of which launcher is used (Twitch, MultiMC, Mojang) and was experienced by also attempting to connect from an entirely different computer. Based on this data, it would appear that the issue is somehow related to the players username in some way that is causing an issue within Tropicraft as only that user is having this issue, no other users have reported having this issue. Also of note, this player is having this issue even when attempting connection to servers they have never touched before, such as the one in the log file attached.

Steps to Reproduce

Because this error seems to be isolated to the username in question, reproduction is most likely not possible unless you are able to fake the player's name and UUID in a dev environment.

1. Download and install the above linked modpack and version.
2. Download and setup the related server for said modpack and version
3. If possible, attempt to connect to the server using the username/UUID of the affected player.

Again, it may not be possible as it appears that the issue is related directly to the player's username, based on various tests conducted.

Tropicraft Version: tropicraft-MC1.12.2-7.1.9.115
Forge Version: 1.12.2 2838

Crash log

Links for files provided due to files being in excess of maximum file size allowed by github.

This is the latest.log file from the client in question:
[snip]

Here is the link for the debug.log file for the client:
[snip]

This has nothing to do with a specific user, but their choice of server name. The tropical book save data gets put in a folder with the same name as the server which the client is currently connected to. It should be sanitized on our end, but the workaround is to simply rename the server.

Also, if you are trying to hide the IP of your server, you should remove it from the logs as well. I'll go ahead and delete those.

The thing is though, this happens with EVERY server this user connects to on this modpack. So this seems to be more than just the server name. And by server name, are you referring to the modpack name or which specific field in the server.properties file? And the reason for the xxx.xxx.xxx.xxx:xxxxx was not to hide the server information, but instead to emphasize the fact this happens to all servers this player connects to while using this modpack.

We have over 200 users playing this modpack in general, and my server (the one the user was connecting to in this log file) has around 60 active users including myself and my wife) who are able to connect with no issue. Is this because of what the user is using for the name field on their client?

Is this because of what the user is using for the name field on their client?

Yes.