Any comment on whether this is viable?

This has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

No, this is not stale... Or, well, it should not be 😢

What about mods like journeymap? It would go crazy on client side trying to figure out how to store files, wouldn't it? If all those dimensions would be 0 :P

I have "World UUIDs" forever in my Forge PR to-do list... That would solve this issue for modded clients, but not sure about vanilla..

What about mods like journeymap? It would go crazy on client side trying to figure out how to store files, wouldn't it? If all those dimensions would be 0 :P

I am sure they have solved this, somehow, since there are already Bukkit-Style plugins that do this on a lot of servers.

Last time I used minimap on such server the minimap was overwriting itself a lot. But that was a few major MC version back (definitely before 1.7).

I looked this over but I'm not really sure what I can conclude about it. There are a lot of things that might go wrong but I don't really know enough about it to call it safe.
Do you have anything you suspected and accounted for, or prior works or... anything like that to get me started?

Unfortunately it seems that the Multiverse plugin is not yet ported over to Sponge. Looking at their bukkit code it seems they are not doing anything fancy for choosing which "environment" (overworld, nether, end) to use for the world (https://github.com/Multiverse/Multiverse-3/blob/master/bukkit/src/main/java/com/mvplugin/core/BukkitWorldManagerUtil.java#L96-L100). It all happens inside Bukkit, which as far as I know has no visible source anywhere anymore (or does it?).
So I am not sure if there are any more steps needed to do this "properly", in my tests it certainly worked with both vanilla and forge clients.

@diesieben07 The source for (Craft)Bukkit and Spigot can be found at https://hub.spigotmc.org/stash/projects/SPIGOT

Dug into it on the spigot side. What they do is minute and basically equivalent to what I am doing here.

Is there anything else I can do?

I think it would be nice to have the actual dimension ID sent to client if the mod that created it is installed clientside (or even if just forge is installed and let forge deal with "unknown" ID clientside, but that could be a breaking change. I haven't looked much into the code so I'm not sure how it could be done but it should be possible).

This would solve the previously mentioned potential issues with mods like journeymap. So forge server would pretend it's vanilla dimension only if it's vanilla client.

And sponge seems to do basically what this PR currently does: https://github.com/SpongePowered/SpongeCommon/blob/7678e517fb3c79535a3d0727cc061e461f09c674/src/main/java/org/spongepowered/common/mixin/core/server/MixinPlayerList.java#L322-L330

I think it would be nice to have the actual dimension ID sent to client if the mod that created it is installed clientside (or even if just forge is installed and let forge deal with "unknown" ID clientside, but that could be a breaking change. I haven't looked much into the code so I'm not sure how it could be done but it should be possible).

This could be done by prefixing the actual packet with a custom payload packet, which would be ignored by vanilla clients. I can look into whether that's viable, but is there demand for it?

Without something like this, there will be no way for clientside mods to differentiate these different dimensions. So if this is going to be part of forge, I think there should be a way for clientside mods to know that these dimensions are not the same even if they have the same ID clientside. But it can be definitely answered only by authors of the mods that may need it.

If we do so, I think we need to do it with a different API than just the dimension ID. I don't think it's a good idea to send different IDs to the client based on whether they are vanilla or Forge.

This has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

It seems nobody but me cares, so... meh.

I definitely do care about this, as it would allow server-side-only custom dimension mods on Forge. And as such, my mod Just Enough Dimensions would benefit from this.

For my purposes, I would like the system to work like was already mentioned by @Barteks2x, so that the client side would use the actual dimension ID if that dimension has been registered on the client, but if it's not, then it would fall back to the "fall-back client-side-ID" that would be registered on the server side with this PR. That way clients that have the mod that registers the custom dimensions installed, could use custom WorldProviders and visuals etc. that go with them, but clients without the mod (or just vanilla clients), could still join the server (or more precisely enter those custom dimensions) without crashing/freaking out.

And how do we know which dimensions the client knows about? There is no packet for that yet.

Well a packet for that could be created (keeping in mind protocol compatibility with previous forge versions).

Note that with the approach I described just knowing which dimension IDs are registered client and serverside is not enough because they may be dimensions from different mods. While generally unmatched client and server dimension IDs are going to be an issue, in this case I think it should be handled because adding a mod clientside shouldn't break connecting to server without that mod.

It may require something like a string ID (resource location?) at least for the server-only dimensions to be able to check whether they exist or not on the client.

At least in JED I sync the registered dimensions (by JED) from the server to the client and then register them on the client side. I assume pretty much any mod that adds dimensions must be doing the same, otherwise things simply wouldn't work. So that means that with the dimension mod present on the client, the dimensions will be registered for the actual IDs.

So what this means, is that IMO it should be enough if the server (Forge) sends a packet that holds the actual dimension ID first, and then following that in the respawn packet it sends the fall-back-client-ID. Then assuming Forge is installed on the client, it would hold on to that actual dimension ID from the first packet, and then in the respawn packet handler it would first try to get a WorldProvider for the previously stored (if any) actual ID, and if that hasn't been registered, then it would fall back to the fall-back ID in the respawn packet. And a vanilla client would only know about the fall-back ID that is in the respawn packet and simply use that directly. At least this is my current thinking of this.

There might still be some issues with the client-side registered dimension being mismatched if switching servers on the same game launch or something similar... but that dimension registration stuff is a bit messy in any case currently because of the DimensionType being an enum that can only be hacked to add stuff to, not remove entries from... So this same issue sort of does currently happen anyway, even if the dimension mods are present on the client.

This would be absolutely helpful in cases of plot worlds, towny, etc.

Well, in theory we do not need a pre-flight packet, since the server knows which mods are installed on the client.

So then the server would have to keep track of which mod registered which dimension, and then use either the real or the fall-back ID in the packet based on whether or not the client has the mod?

There might still be the issue that if the client has the mod, but the mod doesn't sync the dimensions but instead uses a config file on both sides, and the client has a different config than the server, then it might not have the dimension registered. Not sure if that is Forge's concern here?

If dimensions have mismatched IDs on server and client that already breaks today and it's a potential separate issue that I don't think we should address in this PR.

As i explained mismatched do mention odd for the same mid won't work. But e is always the issue of the client adding a mod that has the same ID as the server only dimension. This would make the client seem to know that dimension without it actually being there. And is this really mismatched config? The client just adds a mod that isn't on the server. If the server/client also sends modid for the dimensions then the connection could be rejected in case of such conflict.

There is no record of which dimension is added by which mod though.

In my opinion, the client having a set of mods or configs which causes it to have a mismatched set of registered dimensions (DimensionTypes) is more the user's fault, and trying to protect against that shouldn't be a real concern in this PR.

Even if they have a mismatched dimension on the client, it may still work for the most part, they may just get wrong visuals etc. Which in my opinion is just fine, if the goal here is to simply make it possible to even play on a server without the mod on the client that registered the dimension. Because in that case it's possible that you would lose part of the functionality (like visuals) of that dimension anyway.

And currently, even if the client has the exact correct mods and configs matching the server, it might still get mismatched DimensionTypes, if the client ever joins two servers that have differing dimension configs within the same game launch. The issue being that DimensionType is an enum, so when you register new types when joining to the second server, then when you get an entry by the ID, you will/might get the entry that was registered on the first server instead of the second entry...

This pull request has been automatically marked as stale because it has not had recent activity, and will be closed if no further activity occurs. If this pull request was overlooked, forgotten, or should remain open for any other reason, please reply here to call attention to it and remove the stale status. Thank you for your contributions.

I currently do not have time to work on this further, unfortunately. If someone wants to take it on, please go ahead.

Really a shame this never got implemented, because I'd really like to see a Multiverse plugin for Forge. I'm running multiple smaller worlds, each with their own configuration, and this is the only thing that prevents me switching to Forge.

This is entirely unneeded in the versions Forge supports, as datapacks can now add new dimensions which automatically sync to the client.