Manually teleport player back to original portal instead of resetting the portal cooldown when dealing with portal traps

[TomLewis]

Fundamental issue of GriefPrenvetion, its possible for players to get stuck in a portal. Have a check that if a player is being infinity stuck in a portal, something happens, like the portal(s) deactivate, it only requires a flint and steel to restart a portal, so no loss to the player who owns the portal.

[Jikoo]

GP does stop portal traps, can you provide steps to reproduce?

[TomLewis]

@Jikoo A member of staff on my server made a video to show how this is done, its always been an issue with GriefPrevention.
https://www.youtube.com/watch?v=VI8pqlrebto

[bigpresh]

Does it only happen with iron fencing, as shown in the video? If so, I suspect it's down to GP's decision as to which materials are "occluding" - i.e., seethrough but impede movement - or, perhaps, the fact that a fence doesn't occupy the whole block, so the player may appear to be in the same block as the fence, rather than being next to it?

Otherwise, I've been looking at 35a67de with interest.

[TomLewis]

No it happens with any block

[Jikoo]

Aah, interesting. It's a new flaw with the new system. The problem is how inexact portals are, players do need to be returned to the point they entered the portal from.

What GP used to do was arbitrarily TP any player inside a nether portal x ticks after entering a portal to their location prior to portalling, which was frustrating for players who would travel some time and enter a portal to a new location, only to find themselves all the way back where they started.

What it does now is check if they've left the portal since portalling, and if they have not, it resets the value, allowing the portal to teleport them again. Unfortunately, since the two trapped portals are more exact matches than that additional desert portal, you get pulled into a loop there. Seems like GP needs to teleport back rather than allow the portal to take over.

[RoboMWM]

Ok - so save location on portal, reset portal timer, and then check to see if the player is attempting to teleport the tick (or tick after) we decide to reset the portal timer? We could still run into the issue we had when you reported #13 though.

As much as the grief potential for "deactivating" portals is low - if it does happen, those that do not have access to build (public-access-only areas) might find that rather inconvenient until the owner discovers the unlit portal.

(I may just do something instead like teleporting players near the portal when they exit instead - not sure why Mojang thought it was a great idea to disable use of the chat window while in a portal...)

A workaround you can implement right now @FrozenBeard is setting portal-search-radius (in paper.yml) to 1.

[Jikoo]

Ok - so save location on portal, reset portal timer, and then check to see if the player is attempting to teleport the tick (or tick after) we decide to reset the portal timer? We could still run into the issue we had when you reported #13 though.

Nah, we can use the portal time to determine if they're still in a portal. It won't be quite the same as #13, the new eligibility system plus the old rescue. Basically, instead of resetting portal time, teleport back.