[Suggestion] Sign Configuration for Nether Portals

By default when you go through a nether portal, the game will try to find the closest destination portal within a 128 block radius cylinder (ignoring height) of the corresponding coordinates in the other dimension. But because coordinates in the Nether are compressed 8x compared to the Overworld, this means that two Overworld portals which are 2048 blocks apart could still link to the same destination Nether portal.

In practice (and certainly in my experience) this means it is almost impossible to avoid accidentally griefing other players' portals, because any Overworld portal built anywhere even remotely convenient (i.e. within 1000 blocks of an outpost spawn) will end up interfering with half a dozen other portals in the area. I've lost count of the number of portal pairs I've carefully constructed to be at exactly matching coordinates so that no other portal could interfere with them, only to come back after a short time away to find my portals destroyed because somebody else wanted to set up their own (less carefully positioned) portal and mine was in their way.

I think this situation may even get worse with easier access to player-controlled Frontier outposts, because such an outpost will require a convenient means of access, which will encourage even heavier use of Nether tunnels.

So my suggestion is simply to add support for creating "strongly linked" pairs of Overworld and Nether portals using signs, similar to how signs are already used for block permissions. By placing a sign on two portals (and possibly paying a fee, like a lock sign), those two portals would become a linked pair which can only ever teleport to each other, and which no other portal can teleport to. This would allow people to set up their own private portal connections that will not interfere with anyone else's portals, and which cannot be interfered with by anyone else's portals. These signs could also serve some additional uses, such as behaving like a chest lock sign (preventing the portal itself from being destroyed or deactivated by griefers) and even controlling who is allowed to use the portal (much like sign-based permissions on buttons or doors).

The specific implementation could take many forms, such as a matching keyword on each sign (which would be combined with the owner's name, so two different users with the same keyword don't interfere with each other), or the signs could even specify their exact target coordinates in the other dimension (which would still have to be within the normal range of the source portal). Or it could even be as simple as just naming the owner, with the limitation that you could only have one owned portal within some range (128 or 1024 blocks maybe) so that when entering an owned portal there would be no ambiguity about which owned portal it should be linked to.

I found some sample code that may provide a baseline for this feature:

https://bukkit.org/threads/locating-the-nearest-nether-portal.338649/

I'm not familiar with Bukkit/Spigot plugin development, but it looks like it's designed to be called from the PlayerPortalEvent to do a customized destination portal search and then override the player's destination in the event handler, rather than replacing the entire TravelAgent.

The missing piece is some way to identify the lock owner of a given portal, but presumably that routine can be adapted from EMC's existing code for things like doors, since they would invole a similar search: go up from the door block, then out in each direction looking for a lock sign. In the case of portals it would be slightly more complicated since you'd have to traverse the entire obsidian frame looking for attached signs, but the concept is similar.

Once a portal's lock owner can be identified, then I think all that is required is for the PlayerPortalEvent to first perform a destination search in which it ignores any destination portal not owned by the player, so that it will prefer the closest owned/locked portal near the target location. If that fails to find a destination, rather than creating a new destination portal, it would then repeat the search except it would only ignore destinations which are owned by a different player, so that it will only accept an unlocked/unowned destination.

This should achieve the intended effect of allowing a player to lock/own a portal, and then nobody else's portal can link to that one; but it would also still work when there is no suitable locked destination portal, so that currently existing portals (which are not yet locked/owned) continue to function as they do now. It should also work for setting up brand new portals, since it would still create and use a new destination portal if no suitable destination exists, allowing the player to build a portal, lock it, go through, and then lock the newly created destination (or alternatively, destroy it and rebuild at the desired location in the other dimension, and then lock that one).

Interesting, could help me
so +1

I like this idea. Hopefully it can be worked in the server.

How would it work on a 3 portal system?

I have never had this issue. I personally have created portals within 10-15 blocks of each other (nether side) that Linked up just fine with no issues of interfering with neighboring portals.

That being said, I love the idea of being able to "lock" portals or at least create a system where they can't be linked to other portals (for anti grief purposes)!

It should work primarily for the majority use case. From what I read, this wouldn't replace the current system, only add to it. So it shouldn't break anything, but it also shouldn't be denied because it doesn't cover all bases.

If this is doable it's one of the best suggestions I've seen in a while, good thinking taleden.

if it can be done, +1 mil

+9001

This is a planned feature. EMCD-7
~Socks

LOL access denied.

It's probably a secretly planned feature

But on a side-note also important here...

I have to disagree with that. How do you accidentally grief such a portal in the first place? I mean, if you teleport to the nether then normally your first idea isn't to immediately destroy the very same portal you came through. How else are you going to get back to the Overworld?

Also: even if you did end up in another area than you anticipated then that is still no excuse what so ever to "simply" remove the nether portal just because it got in your way.

I do hope you got staff involved with that. Because griefing isn't allowed and in this case I think it's even more bad because I can't help be convinced that their drive was pure laziness. Maybe that's not true, but its sure my impression of the whole thing.

I mean... They could also have tried to check who the owner of the portal was and work with that. Yet the easier way out is to simply remove said interfering portal and be done with it. But that's griefing, and definitely not allowed nor appreciated.

The problem is this: suppose you're the first person to build a portal in a given area, and let's say you build your overworld portal at X=800 (ignoring Y and Z for simplicity). This corresponds to netherworld X=100, but that location is solid netherrack, so the game spawns your nether portal in the closest open area it can find at netherworld X=85. So far so good.

Now somebody else comes along and wants to build a portal at overworld X=576. This is over 200 blocks away from your portal which seems like it should be no problem, and this person probably doesn't even know your portals exist. But their chosen spot corresponds to netherworld X=72, which means the game doesn't spawn a new nether portal this time, it links to your existing nether portal at X=85. The new guy has no way of knowing this has happened, as far as he knows he's got his very own brand new nether-world portal all to himself.

Now here's the problem: when returning through that nether portal at X=85, the game tries to find an overworld portal at X=680; your original portal at X=800 is 120 blocks away, but the new guy's overworld portal at X=576 is only 104 blocks away, so that becomes the destination of the nether portal.

So this person has accidentally griefed your portals without even realizing it, because when you come along and try to use your portal, you can go through into the nether just fine but when you come back, you end up in the other guy's overworld portal instead of your own. He didn't *destroy* your portal, but that doesn't matter, you still can't get back to your own overworld portal any more.

My proposal is to allow you to lock your two portals so that they become private just to you, and then when the other guy builds his portal, the game won't link him to your existing netherworld portal because that's locked, so instead it will spawn a new destination portal for him. That way your portals would continue to link to each other no matter who else builds their own portals nearby, because the game would always try first to send you to your own locked portal instead of sending you to someone else's portal.

The intention is not there but rendering your Portal useless has the same effect as griefing. The biggest problem is around Spawn but I have had the same problem around Outposts with a nearby neighbor or while trying to place a new one near one of my existing ones.

One of the Portals near Spawn I use to get to an Outpost railway is constantly changing, since it is so close to Spawn. We pretty regularly go through and land on some rickety nethrack platform or in the open and have to figure out where we are relative to our railway tunnel. Initially we kept trying to link ours back, but it was a lost cause. When the location changes now we use the new Portal rather than creating our own, make it secure, and run a new tunnel to our old one. It has worked a lot better because we are cooperating rather than competing even though we do not know the other player(s). A change like this Suggestion would resolve this sort of problem.

What happens when a second portal from the overworld still connects to your locked linked nether portal. Since a second portal wasn't made in the nether the individual still would have to travel back to the overworld. Ultimately taking your locked linked partnered portal to it's overworld counterpart. Thus if the portal is encased in a secret buildmode room. It would leave the player stranded. If buildmode wasn't enables that still would leave your encased room open to unintentional griefing. Do to the need of the player to return to spawn.

If this can be done, I certainly hope it isn't reserved for only supporters; the ability to set up nether portals without interfering with other players seems to me like an important feature for a multiplayer server, just like residences and the anti-grief system are available to all players so that they can play together nicely and not be constantly causing problems for each other.

The idea of locked portals is that a second overworld portal *cannot* link to your locked portal. If you lock a portal, then nobody else's portal can link to yours, the game will act like it isn't even there.

But you have a good point about enclosed buildmode rooms, which is another reason we need to be able to control how portals link up. Now that we have the anti-grief system, it seems like it would be a good idea to enclose your linked portals in a buildmode room so nobody can get in to mess them up. But if you do this, you've accidentally created a trap: if anyone else were to build a portal anywhere nearby, they'd get sent to one of your existing portals and they'd be locked inside your buildmode room with no way out, since the portal in there would only go to your other portal which is also inside a buildmode room. Anyone unlucky enough to wind up in this spot would have to get a moderator to teleport them out, I think. But if we could set up private linked portals, then this wouldn't be a problem, because it would be impossible for someone else to build a portal that would link to either of your enclosed portals.