Don't depend on both a server-side world ID and a client-side server name to determine where waypoints are stored

[dgealow]

The current situation

Currently, waypoints on a server are stored client-side in:

.minecraft/journeymap/data/mp/<server name>_<world_id>/

where <server_name> is the name that the user has typed in to identify the server in their server list (with spaces replaced by ~s); and <world_id> is the world ID on the server side* (with dashes replaced with ~s)

This has the consequence that if either there is a server update that doesn't carefully preserve the journeymap config; or the client changes the human-readable name in the server list; none of the user's old waypoints will show up anymore. This clearly seems like the worst of both worlds (pun unintended) to me. If waypoints are intended to be associated with a given server-side world id, changes to display names on the client side shouldn't make the waypoints go somewhere totally different. The human-readable part of the filename is helpful in fixing the situation, but it would be just as good to have a "client-side-server-name.txt" inside the folder.

Proposal

Categorize server waypoints based on either the world ID alone, or maybe the server address. Maybe save the client-side human-readable name in a text file.

Footnote (maybe this should be another ticket)

* Confusingly, JM seems to create two files in <server root>/config/JourneyMapServer/:

World.cfg, starting with

{
  "WorldID": "<the actual world_id>",

and <world_id>.cfg, starting with

{
  "WorldID": "<some other random hex string (?!)>",

I have no idea which of these is actually used, and I'm too scared of messing up everyone's waypoints to mess around and find out.

[mysticdrew]

So, journeymap has always saved the user data based on what the user enters into the multiplayer menu when adding a server.
WorldId does not exist on servers without JourneyMap. JourneyMap does not require a server side component to work.
in 1.7.10 aka legacy, this was our first iteration of using worldId for multiworld setups.

legacy is open source, if you want to make modifications and do a PR I am willing to discuss merging it.
However, it must not break existing map data if users update.

[dgealow]

Ohhh I see. So in this version, journeymap server basically just sends off that id to the client? Yeah I see the challenge here.

Sorry that I came in kinda guns-blazing here. Just got a bit frustrated after banging my head against various config files trying to figure out "where the heck are my waypoint going?!" for an hour 😅 Thanks for maintaining this legacy fork in general!

[mysticdrew]

I don't recall why there are two files, that is a bit strange.

Saving the multiplayer map data has always been a bit frustrating, not going to lie you.

There is no perfect solution.
By ip-address: ideal for large serves, but not ideal for home servers where hosts IP may change or switch to a different server.
By client entered server name: users change the names of the servers and lose map data.
By worldid: this requires the server component.
By Seed: not possible since the server does not send the seed to the client (though in starting 1.15, they send a 256SHA long hash of the seed, but many custom servers strip this out)

I have been trying to come up with a good solution for years and have not come up with anything that works flawlessly.

Mojang does not save anything on the client regarding the servers, the server.dat file only contains the name and ip. I may utilize this in the future and update the save location if the users changes the name of a server here.

[dvdmandt]

I would probably save by worldid if the server sends one, otherwise the client entered server name. With that said, is the server component built from the same sources as the client? If so, would you mind a PR to move the world id to outside of the config dir (possibly into the world dir? It's logically bound to the world rather than the server after all) in a backwards compatible way? The main reasoning is to make updating servers less easy to screw up as you'd typically remove the mods and config dirs to replace them with the new versions, but keep most other dirs, and especially the world dir.

[mysticdrew]

I would probably save by worldid if the server sends one, otherwise the client entered server name. With that said, is the server component built from the same sources as the client? If so, would you mind a PR to move the world id to outside of the config dir (possibly into the world dir? It's logically bound to the world rather than the server after all) in a backwards compatible way? The main reasoning is to make updating servers less easy to screw up as you'd typically remove the mods and config dirs to replace them with the new versions, but keep most other dirs, and especially the world dir.

Sure, I would accept a PR for that. It's already that way in newer versions. Only condition, you must migrate the old uuid if it exists to the new file.